Hi Nikos, Stephen, It seems to me that both your views (high resistance to traceability and low resource investment on server side) can be accommodated in a single scheme.
Going back to the hash chain proposal that Stephen did a few emails ago on this same thread. If: 1. the length of the hash chain is the shortest between the lengths each peer proposes, and 2. the client is left in complete control of the rollover policy for the session identifier (i.e. deciding when to switch to a new Id), then we would have a lot of flexibility (ranging from one session identifier which lives forever to one session identifier per packet -- that's entirely decided by the client), while at the same time giving the server a voice in determining an upper bound to the resources it needs to reserve per each session. Cheers, t On 07/07/2016 12:57, "TLS on behalf of Stephen Farrell" <tls-boun...@ietf.org on behalf of stephen.farr...@cs.tcd.ie> wrote: >On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote: >> On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: >>> Hiya, >>> >>> Just on this one thing... >>> >>> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: >>>> >>>> does not make the situation any worse >>>> than we have today. >>> I don't accept that is the correct goal. That form of >>> argument is what lead to us standardising the HTTP >>> Forwarded header field, which IMO was a disimprovement. >>> (An argument I lost in the end in that case [1], but >>> 'twas close, and back in 2012 so might go the other >>> way today;-) >>> I would argue that the correct goal is to make things >>> better whenever possible, with that being especially >>> important for protocols like (D)TLS on which many >>> other things depend. >>> I do agree that any scheme developed would need to >>> meet the state management requirements of servers. >>> I'm not convinced those requirements call for a new >>> super-cookie though:-) >> >> I understand your point, I'm not fully convinced by that argumentation. >> I may be wrong of course, but I'll try to explain my point. Indeed >> putting privacy first should be a goal of TLS/DTLS, but to the extent >> it covers the protocol goals. What you propose is to make a stream >> anonymous, untrackable. > >Totally wrong, sorry. What I propose is not adding new ways to >allow a network observer to track a tls client using the same >tls session over multiple transport layer connections, unless >that is really unavoidable. > >Exaggerating my argument is not useful. Not is it at all convincing. > >S. > >> However, that (anonymity or untrackability of >> the stream) was never a stated goal of TLS/DTLS. In fact TLS is by >> definition trackable over TCP and one can see in the clear the IPs of >> the two peers communicating. That doesn't change by switching to DTLS, >> except for unfortunate situations of routers losing state and client >> roaming, which current servers cannot easily cope with, and that's the >> problem I attempt to address. >> >> I think the principle of doing one simple thing and doing it well, >> applies to protocols as well. TLS and DTLS provide a layer of >> confidentiality and authenticity. Anonymity, untrackability can be >> provided by other protocols focused on that such as TOR. >> >> regards, >> Nikos >> >> > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
