On Thu, Oct 12, 2017 at 5:07 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> 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. > Maybe I'm missing something, but I don't think that that's correct. as long as you're willing to (a) restrict the jump to the same size as the transmitted part of the sequence number and (b) do a little trial decryption. We could, of course, also adopt the sequence number hopping scheme that we use for QUIC, which works without trial decryption. >> 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
