Re: [TLS] DTLS 1.3

Mike Copley <> Thu, 07 July 2016 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD2AC12D66C for <>; Thu, 7 Jul 2016 03:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.094
X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2mWyWs9zFE1P for <>; Thu, 7 Jul 2016 03:10:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31B4012D5F7 for <>; Thu, 7 Jul 2016 03:10:43 -0700 (PDT)
Received: by with SMTP id r190so1934394wmr.0 for <>; Thu, 07 Jul 2016 03:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W4olV9z92W9v7x0DJZHhXK6taxa9jjbx5Zyf+8Taofo=; b=MUev47Ou5YWCu1qAoKY5s3DpgtuZFxOtXUeoy0kf6HqX7u0HMTwGR4FxPRh7eZCUFe 9BpCMxLMc1xkc8Navku1p2VTEVV+UxmJ6kyxfvyQ4Ne96GSTvnw37lYPIhO101aZ21KK 2b5/3tmoN0LDk05aenrtfhsNs+sOlJUoX9Ix3F0zqAi02oLIJfI1Easgn/IgPQk+S3Lo gft46g5q+cKu6hkh00Y7rrZeB8+8OsqSDzzfHWbtNZ1ZnAagRsFF2UjESN2v2ThpD8uW fGZhI9ntnVocxzxSrT/6w0m3OWMTYGlOe5iRce4Ug2cL6Symf+wMUoqW9UOTUSCCHPi2 T/Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W4olV9z92W9v7x0DJZHhXK6taxa9jjbx5Zyf+8Taofo=; b=fU3IeVVxwVF2RQXcM0pyOcY/q1/JF8ET5ur78jZyYKZmiyta8jFf7j2n8MIvXgJpwU 1MqoKWkMfjPfyVHkSH2yQbrDIhM2bXGHhVP+fWqj4KuPT3Ga1rnLcECJ1GLtrHDdxFzG X63ijNU3mq2LhBSLkPBYIOtc5OFC2DW42ZhecKQrBNmSO5dwN4odxGjSdYqUTJR1LtEQ Oq2N1z/LcCLuzKgFNte37m9oMpuEmp11HIC6d4k6JmlqZ9VrKv9ZhYPY5IF3ngoD6ewn 3Ns6T0prJOVbpe7PIA2sdkuXmh8aAAPWujKRjIMRV3vt/GTvTDiCrnxZp89zzBWi0iDT s2ug==
X-Gm-Message-State: ALyK8tJ+G5T58GKDo6Ft9LcCPtndJXsDBPmU9/MB/1wlg75mribMI5xHP5ZGBewCiq7qgA==
X-Received: by with SMTP id 187mr2113273wmk.48.1467886241661; Thu, 07 Jul 2016 03:10:41 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k6sm1901503wjz.28.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 03:10:40 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Mike Copley <>
In-Reply-To: <>
Date: Thu, 07 Jul 2016 11:10:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1878.6)
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: Thu, 07 Jul 2016 10:10:45 -0000

On 7/07/2016, at 10:37 am, Stephen Farrell <> wrote:
> 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:-)

What about making it an optional value, with clients that don’t need such behaviour specifying an all-zero value? I have a use case where I control both clients and servers and would like to automatically and simply deal with changing IPs/ports on both sides, and would much rather have this functionality built into DTLS than having to somehow preface the DTLS packet with this ID added.

If we were to go down this route, I would ask that there is a mechanism for an endpoint (server or client) to verify the legitimacy of the IP/port change before handing the data to an upper layer. E.g. Recipient (server or client) receives the ID from a new source (Initiator), sends an encrypted challenge to the new source/initiator, and the initiator replies with an encrypted challenge response at which point the recipient can validate and adjust its return path.