Re: [TLS] DTLS 1.3

"Fossati, Thomas (Nokia - GB)" <> Fri, 08 July 2016 08:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B4F612B043 for <>; Fri, 8 Jul 2016 01:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.396
X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rAuZ6U9i3F_j for <>; Fri, 8 Jul 2016 01:34:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE58B1288B8 for <>; Fri, 8 Jul 2016 01:34:51 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 0F77DCBB9F4E6; Fri, 8 Jul 2016 08:34:48 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u688Ymb9023497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 08:34:49 GMT
Received: from ( []) by (GMO) with ESMTP id u688YmSi004934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 10:34:48 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 10:34:48 +0200
From: "Fossati, Thomas (Nokia - GB)" <>
To: Stephen Farrell <>, Nikos Mavrogiannopoulos <>
Thread-Topic: [TLS] DTLS 1.3
Date: Fri, 08 Jul 2016 08:34:47 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: tls <>
Subject: Re: [TLS] DTLS 1.3
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 08:34:54 -0000

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

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"
< on behalf of> 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.
>> 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