On Tue, Nov 17, 2020 at 10:09:34AM +0100, Achim Kraus 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"?
Apparently I did not remember correctly.
Sorry about that.
-Ben
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
