Re: [TLS] Connection ID Draft

On Fri, Oct 13, 2017 at 6:37 AM, Stephen Farrell <stephen.farrell@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
> >
>
>