Re: [TLS] Choice of Additional Data Computation

[Eric Rescorla <[e-mail]>]

On Fri, Apr 24, 2020 at 12:56 PM Thomas Fossati <[e-mail]>
wrote:

> On 24/04/2020, 19:53, "chris -" <[e-mail]> wrote:
> > [...] the details of how to decode the data on the wire begin to
> > really matter for the proof (and potentially for an attacker).
>
> I have zero experience with formal security proofs, so I need to trust
> your assessment here, which looks like the crux of the argument against
> authenticating the pseudo-header alone.
>
> > I don't think it would hurt to authenticate more than this, e..g.,
> > other fields that the sender and receiver need to agree on.
>
> IIUC the other seemingly critical thing for the security proof of TLS,
> which I think it's critically important we try hard not to diverge from,
> was
> authenticating the length of the record:
>
> > [...] all we cared about is that the header correctly encodes the
> > length of the next ciphertext to decrypt.
>
> The thing is with UDP it is trivial for an attacker to truncate a
> datagram and therefore change the *implicit* length of the carried
> record and go undetected if that is not included in the authenticated
> data.  So it seems that - at a minimum - we should always authenticate
> the length even when it is not put on the wire.
>
> And if we need to do that, keeping the implicit CID looks like a
> no-brainer to me.
>

I do want to be clear that AEAD functions implicitly authenticate the
length of the input. But I'd like to hear Chris weigh in on whether he
thinks we should have them explicitly in the AD (and whether that should be
true in QUIC too).

-Ekr


>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>