Re: [TLS] [xLS 1.3: cookie] - DTLS queries
Mark Dunn <mark.dunn@objectiveintegration.uk> Wed, 19 April 2017 17:07 UTC
Return-Path: <mark.dunn@objectiveintegration.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FE7129B44 for <tls@ietfa.amsl.com>; Wed, 19 Apr 2017 10:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFkYf4j34kUh for <tls@ietfa.amsl.com>; Wed, 19 Apr 2017 10:07:44 -0700 (PDT)
Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE4F128ACA for <tls@ietf.org>; Wed, 19 Apr 2017 10:07:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 3C1A31A02E48; Wed, 19 Apr 2017 17:07:43 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk
Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWShtguycXon; Wed, 19 Apr 2017 17:07:18 +0000 (UTC)
Received: from [192.168.110.3] (host86-136-73-40.range86-136.btcentralplus.com [86.136.73.40]) (Authenticated sender: mark.dunn@objectiveintegration.uk) by mail.objectiveintegration.uk (Postfix) with ESMTPSA id 7E83B1A01A96; Wed, 19 Apr 2017 17:07:18 +0000 (UTC)
To: Eric Rescorla <ekr@rtfm.com>
References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> <CABcZeBMcz8A=Q7E2d6iu2p-uajPoPFDDECBaFfXuQyZgSsEa4A@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
From: Mark Dunn <mark.dunn@objectiveintegration.uk>
Message-ID: <d8b589c7-2765-11e4-7514-14f5b16e7162@objectiveintegration.uk>
Date: Wed, 19 Apr 2017 18:07:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBMcz8A=Q7E2d6iu2p-uajPoPFDDECBaFfXuQyZgSsEa4A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3_spVYe9FQINu5HeGa7cZpDjIb4>
Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 17:07:47 -0000
On 29/03/17 15:29, Eric Rescorla wrote: > Hi Mark, > > Thanks for your note. Some comments below... > > > On Wed, Mar 29, 2017 at 8:10 AM, Mark Dunn > <mark.dunn@objectiveintegration.uk > <mailto:mark.dunn@objectiveintegration.uk>> wrote: > > I am trying to implement cookie and finding it a little > underspecified. > > I am using the TLS 1.3 specified in github and > draft-rescorla-tls-dtls13-01 > > > 1a) Should a client expect to respond to a cookie during > session resumption? > > > Yes, it has to be ready to. As you say, it kills 0-RTT, but that's how > HRR always behaves. > I understand an HRR cookie should cause an extra round trip, but in this case because of "DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed" And "Early data is not permitted after HelloRetryRequest." This results in 2-RTT as the default case, is this what you intended? > > 1b) If (1a) is false then do you agree that the "cookie" > extension MUST be accompanied by the "key_share" extension? > > > If I understand you correctly, then I think this is wrong. You only > send key_share to correct > the client's key_share, so if the client sent a key_share but you send > cookie to force > a round-trip, then you don't send key_share, just cookie. > OK, does this mean a change to DTLS 1.3 figure 4? from Client Server ClientHello +----------+ + key_share* | Flight 1 | + pre_shared_key* --------> +----------+ +----------+ <-------- HelloRetryRequest | Flight 2 | + cookie +----------+ to Client Server ClientHello +----------+ + key_share* | Flight 1 | + pre_shared_key* --------> +----------+ +----------+ <-------- HelloRetryRequest | Flight 2 | + cookie +----------+ * + key_share* * > > > > > 2) I understand this is too late for TLS(only DTLS SHOULD use > cookies) but is there a better solution than a cookie? > > > This seems like it would be a big restructure of the handshake, and > given the > relatively modest use of client auth in many contexts, I don't think > it would probably > be worth it. > > Best, > -Ekr > Many infrastructure devices: smart router, smart switch, virtual switch and most of the IoT require a publish / subscribe / notify pattern or an exception pattern. Do these not qualify? The following use case is a publish / subscribe / notify excerpt from my notes, from which I have further questions. This use case shows that while DTLS 1.3 is provably secure, it has been optimised to be very asymmetric in the way it delivers this security. * *(Sorry it is not the exact format you have used in the spec.) I have used "Accelerometer" and "Brake" in place of "Alice" and "Bob" :) Unlike people, *things* generally do not browse the web. It is likely that they will be commissioned, configured and left mostly to perform their primary function. Example: The *controller* configures communication between two *things*; an *accelerometer* and a *brake* to control wheel spin. The *controller* initiates a three way handshake with the *accelerometer* ClientHello ----- > +key_share… < ----- ServerHello +key_share…, { reference to the *accelerometer’s* certificate CertificateVerify, Finished } ClientResponse ----- > { reference to the*controller's *certificate, CertificateVerify, Finished } , [data:command] < ----- [data:ack] This establishes an ephemeral Diffie Hellman *shared key* which is used to encrypt the communication. The controller already knows the accelerometer and has cached its certificate, so does not require the *certificate chain* , but does require the CertificateVerify *signature* to authenticate the *accelerometer*. The *controller* then commands the *accelerometer* to *authorise* access for the *brake* to monitor it. Similarly, the*controller *communicates with the *brake* to command it to monitor the *accelerometer*. This process may provide both *things* with each other’s *certificates*. The *brake *initiates a three way handshake with the *accelerometer *to request a subscription to a value* * ClientHello ----- > +key_share… < ----- ServerHello +key_share…, { reference to the *accelerometer's *certificate, CertificateVerify, Finished } ClientResponse ----- > { reference to the *brake's* certificate, CertificateVerify, Finished }, [data:request:subscribe] < ----- [ Ack, NewSessionTicket, data:response:ack ] The *brake* makes a request, encrypted with the *shared key,* to monitor the *accelerometer* for sudden acceleration. They agree a *pre-shared key* to use on the next session. A session in this case is ended when either thing loses its ephemeral memory. When the *accelerometer* needs to inform the *brake* of high acceleration (wheel spin) The accelerometer uses the *shared key* to encrypt the Notification < ----- [data:notify:value] * *** *Subsequent Communications **(0-RTT or Zero Round Trip Time)* If either of the *things* loses their ephemeral memory, then they need to use the *pre-shared key *they agreed on earlier. This time the client is the *accelerometer.* ClientHello ----- > +pre_shared_key, +key_share, +early_data… (data:notify:value) < ----- ServerHello +pre_shared_key, +key_share…, {finished…} [data:ack] ClientResponse ----- > (endOfEarlyData) {finished} < ----- [Ack, NewSessionTicket] *Renegotiation* If the car is switched off then the next time it is switched on then full authentication is required once again (without the need for a certificate chain) *Further Questions *3) Is it true that the certificate or certificate chain are not required to be passed in the handshake, it is the client's ability to check the CertificateVerify signature against the certificate. This certificate may have been obtained by other means. If this is the case, could we have an explicit method to ask for either the certificate or the certificate chain rather than providing an expensive certificate chain by default. (I looked at raw certificates, but they do not seem to provide a path to root of trust) 4) Does the DDOS threat disappear if only certificate references or certificates are provided, removing the amplification threat and thus the need for a cookie? 5) I understand for pre_shared_key that we require a If we provide a CertificateVerify, why do we need a Finished as well? 6) In "Subsequent Communications" It was the old server, but now the new client that uses the pre_shared_key, what are your thoughts? 7) In TLS 1.3, i think it is implicit that a session corresponds to a TCP connection or similar, what are your recommendations for what constitutes a session in DTLS 1.3? I am still slogging through how to create a cookie, which is an exceptional version of Transcript-hash (TLS section 4.4.1), which I still haven't figured out....
- Re: [TLS] [xLS 1.3: cookie] - DTLS queries Mark Dunn
- Re: [TLS] [xLS 1.3: cookie] - DTLS queries Hannes Tschofenig
- Re: [TLS] [xLS 1.3: cookie] - DTLS queries Benjamin Kaduk
- Re: [TLS] [xLS 1.3: cookie] - DTLS queries Hannes Tschofenig
- Re: [TLS] xLS 1.3: cookie Eric Rescorla
- [TLS] xLS 1.3: cookie Mark Dunn