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. 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
