The topic of encrypting the content type came up again, and a core WG charter
goal is to encrypt as much as possible. To this end, I suggest we consider
going all the way in this area: headerless records. Each protected record would
contain nothing but an aead-ciphered struct with the bare minimum it needs,
namely ContentType & content, plus maybe padding. Nothing else is really
needed. The only thing that needs to know anything here is the peer with the
key.
struct {
aead-ciphered struct {
ContentType type;
uint16 length = TLSPlaintext.length;
opaque content[TLSPlaintext.length];
opaque padding[padding_length];
};
} TLSCiphertext;
Arbitrary padding can be added after the content, up to the total record
maximum size. If we even wanted to ditch the length field, we could do:
struct {
aead-ciphered struct {
if (padding_allowed) {
opaque padding<0..(2^14+256-TLSPlaintext.length)>;
}
ContentType type;
opaque content[TLSPlaintext.length];
};
} TLSCiphertext;
In which case content is just the remainder of the record after the type.
(without the explicit length field, padding needs to come first so it can have
its length in its vector first)
Cleartext records would of course be unchanged, as they need to stay as-is for
backwards compatibility.
With an encrypted record format like one of the above, everything after the
handshake is opaque and potentially padded.
The additional data fed to the AEAD cipher is just the sequence number at this
point. The version can easily be mixed into the keying material by adding it to
the HKDF label, and then we don't need to re-verify it after the fact if they
key depends on it.
Dave
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
