Re: [TLS] extending the un-authenticated DTLS header

"Fossati, Thomas (Nokia - GB)" <> Tue, 15 November 2016 08:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B889D12964D for <>; Tue, 15 Nov 2016 00:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.402
X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gNop5rYg7fEJ for <>; Tue, 15 Nov 2016 00:34:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 875F21296CE for <>; Tue, 15 Nov 2016 00:34:55 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 2CF1BEEF47D0B; Tue, 15 Nov 2016 08:34:52 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id uAF8YpkC006220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 08:34:53 GMT
Received: from ( []) by (GMO) with ESMTP id uAF8YoiU028053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 09:34:51 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Tue, 15 Nov 2016 09:34:50 +0100
From: "Fossati, Thomas (Nokia - GB)" <>
To: Martin Thomson <>, Nikos Mavrogiannopoulos <>
Thread-Topic: [TLS] extending the un-authenticated DTLS header
Thread-Index: AQHSPxshT8IA2htqqEmXxQo4G0FPBg==
Date: Tue, 15 Nov 2016 08:34:50 +0000
Message-ID: <>
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: Hannes Tschofenig <>, "" <>
Subject: Re: [TLS] extending the un-authenticated DTLS header
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: Tue, 15 Nov 2016 08:34:58 -0000

On 15/11/2016 07:36, "TLS on behalf of Martin Thomson"
< on behalf of> wrote:
>On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos <>
>> TLDR; the privacy offered by this extension is the same as the privacy
>> of DTLS over UDP.
>I disagree.  All the privacy considerations of the QUIC connection ID
>apply here.  It would probably pay to follow that discussion.
>If the intent of this is simply to deal with the NAT rebinding issue,
>then I think that this is worth doing, but to say that this does not
>have privacy issues would be overstating the case.

I agree.  We had previous discussion on and off list about this and we
took Stephen's point to look at ways to make this identifier privacy

The draft proposes two ways to allocate the identifier (see 3rd para of
1. Server decides unilaterally a value that is fixed for the duration of
the session (SecAssocType.fixed);
2. Server and Client agree on a sequence of values generated using HOTP
[RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client
shifts to the next value when needed (e.g. on transport handover).

At first this might not look particularly elegant, but there are good
reasons for having both methods.