Re: [TLS] DTLS 1.3

Stephen Farrell <> Tue, 05 July 2016 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C442312D5BF for <>; Tue, 5 Jul 2016 07:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vLoC8phqJLdY for <>; Tue, 5 Jul 2016 07:24:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B4C712D596 for <>; Tue, 5 Jul 2016 07:24:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 616A7BE32; Tue, 5 Jul 2016 15:24:04 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bzGQVrlrAQid; Tue, 5 Jul 2016 15:24:03 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 7E8F2BDCC; Tue, 5 Jul 2016 15:24:02 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1467728643; bh=36KrAAlQoYcTqqMeP4DFUsdr+pBmT/2DvuUTSaE4HA8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=R+oUfWC7J144qOGc/Q0ODS5nJ1C/W+6DmqArO5TfbZQuD3W/YVzLGPPZqdWpwU5X2 DJu45oDKIacHNnD6nqwiPqdudP3bNpLwl+Asb5fhYZmAc8KWw9miOi/s7C0vwNAV3Z vmq4NIQVFWrstrH+C7r5hqWTHQoaPzy2ZUD+KkBE=
To: Nikos Mavrogiannopoulos <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Tue, 05 Jul 2016 15:24:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070603020008060603040709"
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: Tue, 05 Jul 2016 14:24:10 -0000

On 05/07/16 14:49, Nikos Mavrogiannopoulos wrote:
> ----- Original Message -----
>> On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote:
>>> where id is sent by the server to the client either via an extension, or
>>> by simply assuming that the client will copy and keep the ID seen at the
>>> server packets (it doesn't really matter that this ID is unprotected as
>>> it doesn't contribute nor affect the security in any way).
>> Does that id need to be static? If so, then it'd act as an
>> additional way to track a user roaming over different IP and
>> ports. That'd be a pity. If such an id is useful, maybe there's
>> a way to allow it to change as well, in a way predictable for
>> the server.
> Could be, but I don't have a use case for such 

Hmm. I'd hope we can all share a use case of bring more
privacy-friendly where possible and of not introducing
changes that are privacy-unfriendly unless absolutely

Adding a new identifier that doesn't change despite changes
in client IP address etc. seems like it fails if one has
the "use case" above in mind. Actually, the above is not
really a use-case, but is nonetheless something on which I
think we ought be able to agree so not all changes need to
correspond to some use or abuse case:-)

> a switch nor can think something
> obvious, what do you have in mind?

I've no specific proposal. If it were the case that a new
cleartext identifier is wanted, then there could be ways in
which that can be modified (e.g. a hash-chain based on
something known to both client and server but not sent in
clear) so that the server can know then next "N" ids to be
expected but an observer can't use these to re-identify a


> regards,
> Nikos