Hey, Thanks for joining in, Martin and Chris.
> But Hanno's proposal is a terrible thing to have to implement. You have to > assume that there is some way to recover which CID to use in decrypting any > record. You might save some datagram-local state, but that's awkward. > Stacks that I've worked on try very hard not to have state transmission > between records for good reasons. So this would be a fairly bad > complication.. Separately, I hope that no one would be contemplating trial > decryption for this, which would be terrible. Yes that's a fair point and also applies to Ekr's proposal https://github.com/tlswg/dtls13-spec/pull/143. Moreover, the same layer-mixing criticism applies to the draft as it stands as well as to the other proposed solution, as mentioned before: When you prepare a record, you need to know where it resides within a datagram in order to choose the best header and AAD: You need to know if it's non-initial within the datagram to decide if you can omit the CID, and you need to know if it's terminal to decide if you can omit the length. In contrast, if you decouple the choice of header format from the AAD, record protection can be done prior to passing the record to the datagram layer. As mentioned initially, this not only increases modularity within the stack, but also allows e.g. to change the header towards more aggressive compression at the entry of a highly constrained network, which I believe is indeed a feature and not a "defect" and increases suitability of DTLS 1.3 for the IoT. The CID maintenance for incoming records can be avoided when forbidding CID elision, as suggested by Ekr. Comparing the state maintenance complications this avoids to the increase in header size it introduces, maybe that's the way to go, as the state maintenance indeed seems to be the bigger pain. However, even if CID elision is removed, I maintain the proposal to always use the logical presentation of the header for AAD, for all the mentioned reasons: (a) No interleaving of record and datagram layer, (b) conceptual clarity and independence of [header] compression methods from cryptographic computations, as e.g. in cTLS, (c) dynamic choice of header depending on network paths. All those issues persist when sticking to the on-the-wire AAD. What are your reservations towards this? Cheers, Hanno ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Eric Rescorla <e...@rtfm.com> Sent: Thursday, April 23, 2020 2:49 AM To: Martin Thomson <m...@lowentropy.net> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] DTLS 1.3 AEAD additional data OK but we would expect the peer to process CID-less records if they are coalesced? -Ekr On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>> wrote: On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote: > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson > <m...@lowentropy.net<mailto:m...@lowentropy.net>> wrote: > > I prefer Ekr's solution, but I would go with that being a recommendation > > (SHOULD) as opposed to a requirement (MUST). > > Can you clarify where you think we should say SHOULD? The security considerations seems right. After the list of improvements over DTLS 1.2 CID. You would say that an endpoint that is asked to provide a CID SHOULD provide one in every record (with the compact header, etc...). If it does not, then it might be possible for an attacker to use that record to confirm guesses about linkability between two paths. Also, omitting the CID might make it hard to route datagrams. With all of this, you might want a section heading for all the CID stuff. 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
