On Fri, Oct 13, 2017 at 6:37 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > > 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've seen a number of designs like these, but in general they have quite poor scaling properties. Can you describe the precise design you have in mind so that we can analyze it. -Ekr > > 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 > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
