On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson <m...@lowentropy.net> wrote:
> On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote: > > OK but we would expect the peer to process CID-less records if they are > > coalesced? > > I guess so. If we allowed them to drop them, then we're close to saying > MUST NOT omit. > Yeah, I would make three points 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? -Ekr > On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > > 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. > > I don't see how. If you are talking about marshaling costs, that's a > constant problem, but we haven't found that to be an issue in practice. > From my perspective, it's the old DTLS records with a pseudo-header that > are hard to construct; the new format is far easier to construct for > sending (assuming that you don't try to shave the sequence number length > down dynamically, but that's a new option our stack doesn't try to use). > > Yours is a sending-side concern, and that seems to be subjective, because > I think that sending is easier without a pseudo-header. My concerns were > about receiving. > > > 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? > > I'm sorry, I don't follow your argument. > > The authenticated logical header being different than what is sent on the > wire is a bug in my opinion. Authenticating all the bytes you send makes > the protocol simpler and less error prone. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
