Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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
>