On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla <e...@rtfm.com> wrote: >> The design for new connection IDs is clearly to handle the linkability >> issue, but the draft doesn't propose a solution for linking based on >> the monotonic increase of sequence numbers, or acknowledge the >> problem. > > Sorry, that's a good point that somehow didn't make it from my head into the > draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you > don't > need contiguous ranges except for anti-replay, so the sender can just jump > forward and then the receiver can keep a per-connid table. I've filed > https://github.com/ekr/dtls-conn-id/issues/2 to address this.
That only true if we don't truncate the sequence number. >> We had comments about the length of the connection ID and the value >> being used as a covert channel. That issue should at least be >> addressed in the security considerations. > > > I filed: > https://github.com/ekr/dtls-conn-id/issues/3 > > That said, I'm not sure that any plausible length CID can avoid this. I agree. Anything too short is going to be useless for the use cases we care about, but anything long enough to be useful is ripe for abuse. We can acknowledge the problem though; and maybe suggest that endpoints that care about this could at least disable the extension. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
