Re: [TLS] DTLS 1.3 AEAD additional data

[Thomas Fossati <[e-mail]>]

On 25/04/2020, 11:43, "Thomas Fossati" <[e-mail]> wrote:
> On 25/04/2020, 11:11, "Thomas Fossati" <[e-mail]> wrote:
> > On 25/04/2020, 01:30, "Christopher Wood" <[e-mail]>
> > wrote:
> > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> > > > 1. Allowing implicit CIDs is very recent (it was introduced in
> > > > -34)
> > > > 2. The CID specification explicitly prohibits it for DTLS 1.2.
> > > > 3. I haven't really heard a very compelling argument for this
> > > >    and I note that QUIC forbids it [and in fact has much worse
> > > >    problems when you mix epochs because the long header is so
> > > >    long]
> > > >
> > > > So, given that the simplest and most consistent thing is to
> > > > simply forbid it: can someone make an argument for why this is
> > > > important to permit?
> > >
> > > Thanks to everyone who participated in this thread so far! Given
> > > the points above, the chairs would like to hear arguments in favor
> > > of implicit CIDs. Absent substantial rationale, we'll assume rough
> > > consensus for explicit CIDs.
> >
> > Hi Chris, I think implicit CID needs to be considered in the wider
> > scope of unified_hdr compression, together with implicit length and
> > shortened epoch.  In particular, from Chris P's emails I understand
> > that being able to authenticate records' length is a core assumption
> > in the security proof of TLS.  Therefore leaving it out from DTLS
> > AAD when it's not in the header looks like a pretty bad idea.  If
> > this is the case (i.e. the fact that the wire image by itself is not
> > sufficient input to the AAD), then authenticating implicit CIDs
> > should just come in the same bundle.
>
> Sorry, scratch that for the moment - I had missed the most recent
> emails on this thread :-(

Back to this after having read and digested the parallel thread.

As it stands I don't think we have enough data to take an optimal
decision with respect to what needs to be input to the AAD.

I suggest we err on the side of caution and use a pseudo-header approach
where the pseudo-header equates the wire-header (except the epoch is in
full) when no compression is involved and otherwise includes all the
elided fields.

I also note that it'd be great if the formal verification community
could carve some time to look into the security of DTLS 1.3.  There is
certainly a lot of overlap with TLS and I guess substantial parts of the
modelling can be reused, but there are interesting differences (in
particular, around the tight knit between reliability and security
layers during handshake) that are unique to DTLS and likely deserve a
more careful look.

cheers!

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.