I wonder if it matters that integrity is more subtle because it can be applied retrospectively?
For example, an SSH connection setup initially has no integrity protection – because how could it, when you haven't yet got a shared secret to base it on? – but after the key exchange completes, signatures are generated which cover a hash that includes the whole of the unprotected connection setup phase. So those messages are not integrity-protected at the time of sending in the same sense that the rest of the protocol session is, but they are integrity-protected eventually, in that later on there will come a point where you are convinced that they hadn't been tampered with.
I feel as if that kind of subtlety might be harder to represent in a simple colour code than confidentiality protection, which is much more like a fixed property of the message as originally sent.
(Though, I suppose, even confidentiality protection could be retrospectively removed, either by sending the decrypted version somewhere or by revealing a key.)
(no subject)
Date: 2016-02-24 03:52 pm (UTC)For example, an SSH connection setup initially has no integrity protection – because how could it, when you haven't yet got a shared secret to base it on? – but after the key exchange completes, signatures are generated which cover a hash that includes the whole of the unprotected connection setup phase. So those messages are not integrity-protected at the time of sending in the same sense that the rest of the protocol session is, but they are integrity-protected eventually, in that later on there will come a point where you are convinced that they hadn't been tampered with.
I feel as if that kind of subtlety might be harder to represent in a simple colour code than confidentiality protection, which is much more like a fixed property of the message as originally sent.
(Though, I suppose, even confidentiality protection could be retrospectively removed, either by sending the decrypted version somewhere or by revealing a key.)