Argh, Good catch. I'll revise the proposal in light of this point. -Ekr
On Tue, Nov 17, 2020 at 1:09 AM Achim Kraus <[email protected]> wrote: > 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
