On 13/10/17 00:13, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > Comments welcome.
As a near-nit, I don't think "dismissed" is a good way to describe the analysis of some of the ideas that came up earlier. In particular, I still think there's merit in some use of a hash chains, to decrease linkability, even if that's not done for every packet. For example, considering a client that might detect an occasional change of 5-tuple, it could use something like id_n=H(foo||id_(n-1)) where foo is something dependent on the TLS session secrets (exporter-like) That way the TLS stacks can pre-calculate the next id (or a bunch of those) and then only lookups are needed (though the tables are bigger of course) just as with a static connection id. I'd argue that such designs not be dismissed. I accept that the design needs to end up being efficient enough to get used but I don't think that we need to go for the simplest possible design, if that exposes 5-tuple linkages in ways that setting up new TLS sessions would not. Cheers, S. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
