Re: [TLS] [xLS 1.3: cookie] - DTLS queries

Benjamin Kaduk <bkaduk@akamai.com> Thu, 20 April 2017 14:34 UTC

Return-Path: <bkaduk@akamai.com>
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 751BF13147D for <tls@ietfa.amsl.com>; Thu, 20 Apr 2017 07:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 U0e5uySTrlDg for <tls@ietfa.amsl.com>; Thu, 20 Apr 2017 07:34:54 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 654F5131484 for <tls@ietf.org>; Thu, 20 Apr 2017 07:34:51 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D163496C0C; Thu, 20 Apr 2017 14:34:50 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7CF22496C03; Thu, 20 Apr 2017 14:34:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1492698890; bh=dLYXOle8Z0QGZg25q+megTFPZXWNCaPmSPuXIoZ4RBw=; l=3233; h=To:References:Cc:From:Date:In-Reply-To:From; b=0GsA4M+XkJbqEya1YdHdUOeMsA27/UUw53MlG3Sm+AsZOXYx1yfc00twpnEDdBWl4 Mnf7UsmhgikUqObyvB3jis29/jB/JC3+rp7v2sIB6agWkCxjn/KOE/wt0jQlHGAY2Q fSrMR8KXLWHYpeqkZU5uSV9aizwzkkuwMvS62tWM=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 1600D1E0C4; Thu, 20 Apr 2017 14:34:49 +0000 (GMT)
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Mark Dunn <mark.dunn@objectiveintegration.uk>
References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> <CABcZeBMcz8A=Q7E2d6iu2p-uajPoPFDDECBaFfXuQyZgSsEa4A@mail.gmail.com> <d8b589c7-2765-11e4-7514-14f5b16e7162@objectiveintegration.uk> <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net>
Cc: "tls@ietf.org" <tls@ietf.org>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <652e33d7-cb5a-2ce1-f7cc-34c57128d660@akamai.com>
Date: Thu, 20 Apr 2017 09:34:49 -0500
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: <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net>
Content-Type: multipart/alternative; boundary="------------12360A95C6006E4DFA5C9BB2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/S_j-Q0Ghx-H9sjtOkBgrlJko5Yo>
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: Thu, 20 Apr 2017 14:34:57 -0000

On 04/20/2017 01:22 AM, Hannes Tschofenig wrote:
>
> On 04/19/2017 07:07 PM, Mark Dunn wrote:
>>
>> 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?
> This is a very good observation. I added an issue to the tracker about
> this question:
> https://github.com/tlswg/tls13-spec/issues/972
>
> It would be good to have a justification for this restriction and it
> would be worthwhile to re-consider it in the DTLS specification since
> the use of HRRs will be common with connection-less transport protocols.

Note that we currently document sending HRR as a way for a server to
reject early data without having to do trial decryption to determine the
end of early data (since the outer content-type is meaningful for the
ClientHello2).  I expect there will be some situations where servers do
not want to implement trial decryption, so removing this functionality
without replacement seems ill-advised.

-Ben