Hi Ben,
Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
Hi Ekr,
As for EtM
Encrypt-then-MAC:
struct {
uint8 marker = tls12_cid;
uint8 cid_len;
uint8 content_type = tls12_cid; \
uint16 DTLSCiphertext.version; | appears on wire
uint64 seq_num; // includes epoch |
opaque cid[cid_len]; /
uint16 iv_length;
opaque IV[iv_length];
uint16 enc_content_length;
opaque enc_content[enc_content_length];
};
I failed to understand the reasons behind this proposal.
1. Why should the "marker" be added, if the "content_type" is already in
the MAC, and this special MAC is only applied for tls12_cid records.
What is the intended benefit of that?
This is another general hygiene item; we are preserving the invariant that
the first byte of the MAC input is the content type -- this is at present
(IIRC) invariant across all TLS versions and MtE/EtM, and not something to
change lightly.
"All TLS versions"?
TLS 1.2, RFC 5246
https://tools.ietf.org/html/rfc5246#section-6.2.3.1
The MAC is generated as:
MAC(MAC_write_key, seq_num +
TLSCompressed.type +
TLSCompressed.version +
TLSCompressed.length +
TLSCompressed.fragment);
https://tools.ietf.org/html/rfc5246#section-6.2.3.3
The additional authenticated data, which we denote as
additional_data, is defined as follows:
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
So, as far as I see, at least the TLS 1.2 variant doesn't do that.
RFC6347 doesn't change that, so DTLS 1.2 also doesn't do that.
Maybe you precise the "all" to a set of versions to make it easier to
check it?
best regards
Achim
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
