From nobody Mon May 1 11:27:27 2017 Return-Path: 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 A88B6129C39 for ; Mon, 1 May 2017 11:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 71bQH67R9fDL for ; Mon, 1 May 2017 11:27:24 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CB712E035 for ; Mon, 1 May 2017 11:24:32 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id o3so43053673pgn.2 for ; Mon, 01 May 2017 11:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VpN5fljzUYyLYOyu0MHyg3vD+W6MogM88SmKyghMeCs=; b=CWg9cPOOpdTlyg1YmI6GbaNFUJKgPmXsp2oU4Mt6Pj5IcW+iFG9sVlUcgjs/Y5LQGj wTAmE3TUeUO6wjV4I0OIFAim4mFPwETmOtSPaJS0MGDskq3QQAuWdTunmf9/ne+jiMV8 TaB4Z0BZyJ1em3l6pPXFn7RegP4mmNzmG+jsCd/91wLX9kktNOnOoDANrcQ1ZJSzdPFs dWBLHLV05AlmfC5GF3yZ+5m2NHGE+dCAFveKtb3CJsvRgL9UBIZWX70UpGDvcNweJb+U SZ9o1LnX63Ow27Fwwlb7ajpc13Z6jjLgb5xbH4/wgX3n5Hqv+A4VpHvOzY8EZk8TNK72 EIxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VpN5fljzUYyLYOyu0MHyg3vD+W6MogM88SmKyghMeCs=; b=iH10UOW7qMCAIPWRHo17nSNwaX9IvZJ3pXvVnxciQ727ha7BkuGieHoHhYhkqhoDZd tuyf4ba5zhseDq55qft8decSi0Wzc4Z0f152Q7nKxgbbhiC6k1YFkd4UrTqjN9pk8Xa2 xANtT/eUeJfGAJ+olqqre4Gts2AnaqgOzuTEU0f049WMWPCFheIjfyQgXFNZWJTbpnkM /ysCu9fD8nc89GEqeteqlKhYC7W4j7BWQcZ/6z98jWYjB6xIS7EOgFxQY/UN//pY4RbB LzPPleUPHDeRRp1rTi74TY7Pin168dyioHfFvzYtWYFdDcZpPBRfdXet1ZOZu7DCkMol 170A== X-Gm-Message-State: AN3rC/5IACT0Pvzj3i/mtzcFHmchzzMjZNH6llA/OuWJ1Br87KF7ewE5 w2MFbGrpZoyIBrHanEgwsWxTmSl2JoeD X-Received: by 10.84.245.1 with SMTP id i1mr30949479pll.51.1493663071453; Mon, 01 May 2017 11:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Mon, 1 May 2017 11:23:51 -0700 (PDT) From: Kathleen Moriarty Date: Mon, 1 May 2017 14:23:51 -0400 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:27:26 -0000 Hello, Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02. In the IANA section, I think it would be a bit more clear to say in the last column rather than second column wince one might interpret this listing as having 3 columns. The cipher suite numbers listed in the second column are numbers used for cipher suite interoperability testing and it's suggested that IANA use these values for assignment. The registry has this reversed with the description as the second column, which is fine. I'm just pointing that out as it doesn't clarify the column for you. Nits: Security Considerations section: Use of Pre-Shared Keys of limited entropy may allow an active attacker attempts to connect to the server and tries different keys. s/tries/try/ Other example includes the use of a PSK chosen by a human and thus may be exposed to dictionary attacks. s/Other/Another/ -- Best regards, Kathleen From nobody Mon May 1 18:48:45 2017 Return-Path: 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 265281294D2 for ; Mon, 1 May 2017 18:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KIZSmLbM-37q for ; Mon, 1 May 2017 18:48:40 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C8F12EA7C for ; Mon, 1 May 2017 18:46:31 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id t144so67733721lff.1 for ; Mon, 01 May 2017 18:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9rrb93dwkXxw7qbz3wG6OeM/u6I9IX7yuyCNAyGjtoA=; b=Sb/on3cSc+VAatlZB89eFPTBXsOIPR5Efbk+VH18vewGduVwXtrGy38ESSYChzkdOJ irhOF1/Nn4lLTDtOUCloQS4dhTvhAmVhNNAxkFqbwmcO5MXeEnFZMXZQz1MEPauvffbs 40rxXuLqVE7VkIKUDYuya0enoLrfjT2A6d7mMYB9VJEtz3A0Qa1lgyo/pmG0ji6igBlA jBungbOLzu7k51lMs6879+kZdx4tHgxCBy3me83GFEL/g2hETEJf/5JR6m9Kfny+9gOo 0PLNg3y6SGe5LzGRK10vZKWZ66kdZiv7a0hKU5vM3qCJSMuJDVeBxu2lOme4ubQy0kF5 PKLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9rrb93dwkXxw7qbz3wG6OeM/u6I9IX7yuyCNAyGjtoA=; b=AicxLPuU2tVo3i/Ts1+T5SVfyc9ju4oZU4gn7svl8htoxabIT4Oq77JLvT8LkkTGAR vtBcdk52YioqSBBAkQmU3wfuVIwFAeJ7rAmQMzg3JVUkQ6Cz6YUge7NEmH8EVrz8wBEn kcoQNLx+Hls6Cve/2NBtz6QIJGhdBSwpWJW+h90feFPrQoeLqU9WOxq+7Sb7AqRhf5i8 ls8HBovaqEuebn4xxOwD4M712Fy1ZN49QpR6hgaOM9V0s9JUC8VglZ0ZJXEIo4ACbs6a yIAsK1fd90Dv/RNWiQYVdLw/t2Ev1hef9zTqhpLB3IEbmjM0kCTrLQ1ke+3XwxLyZltF oygw== X-Gm-Message-State: AN3rC/5gwnd0jANJKc19sH4J39iJ+TOfV9CqN0z40rPBZZwC9f+CEwH2 oK+VSUChWMd2uDpBDhcxyaNMK6io1Q== X-Received: by 10.25.155.145 with SMTP id d139mr8373610lfe.174.1493689590018; Mon, 01 May 2017 18:46:30 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.212 with HTTP; Mon, 1 May 2017 18:46:29 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Mon, 1 May 2017 21:46:29 -0400 X-Google-Sender-Auth: 8_UNXjhQdOWl5nheOm9EVG_Tjfg Message-ID: To: Kathleen Moriarty Cc: "" Content-Type: multipart/alternative; boundary=001a114022986af7bd054e80b59c Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 01:48:42 -0000 --001a114022986af7bd054e80b59c Content-Type: text/plain; charset=UTF-8 Hi Kathleen, Thank you for the review. I have proceeded to the update of my local copy. The text is: """ The cipher suite numbers listed in the last column are numbers used for cipher suite interoperability testing and it's suggested that IANA use these values for assignment. """ Other nits have been addressed as well. If that is fine, I can publish the version 03. Yours, Daniel On Mon, May 1, 2017 at 2:23 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02. > > In the IANA section, I think it would be a bit more clear to say in > the last column rather than second column wince one might interpret > this listing as having 3 columns. > > The cipher suite numbers listed in the second column are numbers used > for cipher suite interoperability testing and it's suggested that > IANA use these values for assignment. > > The registry has this reversed with the description as the second > column, which is fine. I'm just pointing that out as it doesn't > clarify the column for you. > > Nits: > > Security Considerations section: > > Use of Pre-Shared Keys of limited entropy may allow an active > attacker attempts to connect to the server and tries different keys. > s/tries/try/ > > Other > example includes the use of a PSK chosen by a human and thus may be > exposed to dictionary attacks. > s/Other/Another/ > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114022986af7bd054e80b59c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kathleen,

Thank you for the= review. I have proceeded to the update of my local copy. The text is:
<= br>"""
The cipher suite numbers listed in the last column= are numbers used
for cipher suite interoperability testing and it's= suggested that IANA
use these values for assignment.
""&qu= ot;

Other nits have been addressed as well.

If t= hat is fine, I can publish the version 03.

Yours,
D= aniel


On Mon, May 1, 2017 at 2:23 PM, Kathleen= Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:
Hello,

Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02.
In the IANA section, I think it would be a bit more clear to say in
the last column rather than second column wince one might interpret
this listing as having 3 columns.

=C2=A0 =C2=A0The cipher suite numbers listed in the second column are numbe= rs used
=C2=A0 =C2=A0for cipher suite interoperability testing and it's suggest= ed that
=C2=A0 =C2=A0IANA use these values for assignment.

The registry has this reversed with the description as the second
column, which is fine.=C2=A0 I'm just pointing that out as it doesn'= ;t
clarify the column for you.

Nits:

Security Considerations section:

=C2=A0 =C2=A0Use of Pre-Shared Keys of limited entropy may allow an active<= br> =C2=A0 =C2=A0attacker attempts to connect to the server and tries different= keys.
s/tries/try/

=C2=A0 =C2=A0Other
=C2=A0 =C2=A0example includes the use of a PSK chosen by a human and thus m= ay be
=C2=A0 =C2=A0exposed to dictionary attacks.
s/Other/Another/


--

Best regards,
Kathleen

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114022986af7bd054e80b59c-- From nobody Tue May 2 04:48:30 2017 Return-Path: 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 602F3131670 for ; Tue, 2 May 2017 04:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1ttveCm6SDLc for ; Tue, 2 May 2017 04:48:27 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E9C13168E for ; Tue, 2 May 2017 04:45:43 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id q1so39600553qkd.2 for ; Tue, 02 May 2017 04:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QyloKHIm9W7c+kTZDvp5P6rpR0ysIPqNu/KMwuNBubo=; b=u0eLR8uG9xkExzzgldbC1a3IfEJyHq0V4wbU1I6ewplAwH1g7MFb1SQIbg1nF6k7k1 7WA33NLTwQyhgWhCTYFIamZWHX6lJGroO4soptgaT8CZtWRIJkOluc+77pDSy7UnRSsZ d98raWH4j/tY7k3dBeEMxRQUX6OAonsrQ/pfue0GZLcXDczl8L4fH1LsE3RQrdNX2gMZ MgruQkYQQCdVuXcrLEJ0MBX33IJ4do9TadC9umek+tUpFSnu006KEiY44OjNEb5wY3d3 6xgz1NcfpLFZl29mHg9megAvdEngJEnoi6Ck6zJEqZWtUB0neOJ0LGYYRu6Vt3Hgs03r kpSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QyloKHIm9W7c+kTZDvp5P6rpR0ysIPqNu/KMwuNBubo=; b=D8Qe4/2LSpY97EQkAwS/UF5beFo0CmKX8OLu+vYMCGYDja9K9n/NOQfV/1w9wn+pNs 6eEwLi4utC31U5gY9NnHgHMcBWrCZBKSCq+wMzSVxwyhKOiMnc5N+GshKIErz+Dpnt6B ISlBXAO0dObce7DEFPlSUyJJyvWXFRXCGIBFIhESOujviOQ7X5KvtbhwS73XqvX2UecR ouOcVFH/iGVNULg76gTkDg1yVisGotDPFvwKaLrDBur8agzvhbZt799uYNID0XhKExaT bah/wVLOhBSBVMTVhxJEuymViUYDsqkF+VA/yxKIuin1PcXNFuzIgja6GQV6vmlRndMl S91Q== X-Gm-Message-State: AN3rC/6YKznueyLtg+up8lg0+xGqDXa0wnl2eiMqueuaOMxKnWLyAdry agOL+WKjsRF9fA== X-Received: by 10.55.74.215 with SMTP id x206mr24714635qka.57.1493725542574; Tue, 02 May 2017 04:45:42 -0700 (PDT) Received: from [192.168.1.13] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id z63sm12984124qkc.6.2017.05.02.04.45.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 04:45:41 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F4A4366F-914D-4805-B812-5C254F68E276 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 2 May 2017 07:45:40 -0400 Cc: "" Content-Transfer-Encoding: 7bit Message-Id: <05FBCFBA-93BE-4314-830D-65528F6BAED9@gmail.com> References: To: Daniel Migault Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 11:48:29 -0000 --Apple-Mail-F4A4366F-914D-4805-B812-5C254F68E276 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Daniel, Thank you, please publish version 3 and I'll kick off last call. You could u= pdate the TLS version to 20 as well, but that's something that will get fixe= d with the RFC number while in the RFC editor queue. Best regards, Kathleen=20 Sent from my iPhone > On May 1, 2017, at 9:46 PM, Daniel Migault w= rote: >=20 > Hi Kathleen,=20 >=20 > Thank you for the review. I have proceeded to the update of my local copy.= The text is: >=20 > """ > The cipher suite numbers listed in the last column are numbers used > for cipher suite interoperability testing and it's suggested that IANA > use these values for assignment. > """ >=20 > Other nits have been addressed as well.=20 >=20 > If that is fine, I can publish the version 03.=20 >=20 > Yours,=20 > Daniel >=20 >=20 >> On Mon, May 1, 2017 at 2:23 PM, Kathleen Moriarty wrote: >> Hello, >>=20 >> Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02. >>=20 >> In the IANA section, I think it would be a bit more clear to say in >> the last column rather than second column wince one might interpret >> this listing as having 3 columns. >>=20 >> The cipher suite numbers listed in the second column are numbers used >> for cipher suite interoperability testing and it's suggested that >> IANA use these values for assignment. >>=20 >> The registry has this reversed with the description as the second >> column, which is fine. I'm just pointing that out as it doesn't >> clarify the column for you. >>=20 >> Nits: >>=20 >> Security Considerations section: >>=20 >> Use of Pre-Shared Keys of limited entropy may allow an active >> attacker attempts to connect to the server and tries different keys. >> s/tries/try/ >>=20 >> Other >> example includes the use of a PSK chosen by a human and thus may be >> exposed to dictionary attacks. >> s/Other/Another/ >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 --Apple-Mail-F4A4366F-914D-4805-B812-5C254F68E276 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Thank you, please publish v= ersion 3 and I'll kick off last call.  You could update the TLS version= to 20 as well, but that's something that will get fixed with the RFC number= while in the RFC editor queue.

Best regards,
Kathleen 

Sent from my iPhone

On May 1, 201= 7, at 9:46 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi Kathleen,

Th= ank you for the review. I have proceeded to the update of my local copy. The= text is:

"""
The cipher suite numbers listed in the last column a= re numbers used
for cipher suite interoperability testing and it's sugges= ted that IANA
use these values for assignment.
"""

Other n= its have been addressed as well.

If that is fine, I can publis= h the version 03.

Yours,
Daniel

On Mon, May 1, 2017 at 2:23 PM, Kathleen Moriarty = <ka= thleen.moriarty.ietf@gmail.com> wrote:
Hello,

Thanks for your work on the draft draft-ietf-tls-ecdhe-psk-aead-02.
=
In the IANA section, I think it would be a bit more clear to say in
the last column rather than second column wince one might interpret
this listing as having 3 columns.

   The cipher suite numbers listed in the second column are number= s used
   for cipher suite interoperability testing and it's suggested th= at
   IANA use these values for assignment.

The registry has this reversed with the description as the second
column, which is fine.  I'm just pointing that out as it doesn't
clarify the column for you.

Nits:

Security Considerations section:

   Use of Pre-Shared Keys of limited entropy may allow an active    attacker attempts to connect to the server and tries different k= eys.
s/tries/try/

   Other
   example includes the use of a PSK chosen by a human and thus ma= y be
   exposed to dictionary attacks.
s/Other/Another/


--

Best regards,
Kathleen

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail-F4A4366F-914D-4805-B812-5C254F68E276-- From nobody Tue May 2 07:11:31 2017 Return-Path: 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 BFC8A129479 for ; Tue, 2 May 2017 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_FILL_THIS_FORM_SHORT=0.01] 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 EcEDJQG232Y6 for ; Tue, 2 May 2017 07:11:22 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3889C127078 for ; Tue, 2 May 2017 07:07:35 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id v42E7X2p007300 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 2 May 2017 16:07:33 +0200 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id v42E7WMV003704 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 2 May 2017 16:07:33 +0200 Received: from DENBGAT9EROMSX.ww902.siemens.net (139.22.70.195) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 2 May 2017 16:07:22 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.222]) by DENBGAT9EROMSX.ww902.siemens.net ([139.22.70.195]) with mapi id 14.03.0352.000; Tue, 2 May 2017 16:07:21 +0200 From: "Fries, Steffen" To: "tls@ietf.org" Thread-Topic: Definition of cipher suites for TLS 1.2 still possible? Thread-Index: AdLDTWpeLBLLQHFiTSKY+DwL/vtEYA== Date: Tue, 2 May 2017 14:07:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.54] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B33784A092EDENBGAT9EH2MSXww9_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Definition of cipher suites for TLS 1.2 still possible? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:11:26 -0000 --_000_E6C9F0E527F94F4692731382340B33784A092EDENBGAT9EH2MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, it may be a na=EFve question, but is it still possible to define and standa= rdize new cipher suites for TLS 1.2 as an RFC, when TLS 1.3 is almost finis= hed? The reason for asking is the discussion I started two weeks ago regarding i= ntegrity only cipher suites, which are not longer supported in TLS 1.3. Whi= le we most likely can cope with this by utilizing TLS 1.2 further as sugges= ted, one question remains regarding the hash functions in the existing inte= grity only cipher suites. Currently, there is no integrity only cipher suit= e defined that combines ECDSA and SHA 256. There are only combinations with= SHA1. Interestingly, there is one combining RSA and SHA 256. To no longer depend on SHA1, we would like to standardize a combination of = ECDSA and SHA 256 for instance TLS_ECDHE_ECDSA_WITH_NULL_SHA256. Would this= still be possible, given the fact, that TLS 1.3 is likely to be finished i= n near time. I know that this depends on the acceptance of the WG, but I wo= uld like to ask first, if there is any intention to close TLS 1.2 for chang= es and additions, once TLS 1.3 is ready. Best regards Steffen -- Steffen Fries Siemens AG Corporate Technology CT RDA ITS Otto-Hahn-Ring 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 mailto:steffen.fries@siemens.com www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Rus= swurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Comm= ercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE= -Reg.-No. DE 23691322 --_000_E6C9F0E527F94F4692731382340B33784A092EDENBGAT9EH2MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all,

 

it may be a na=EFve question, but is it s= till possible to define and standardize new cipher suites for TLS 1.2 as an= RFC, when TLS 1.3 is almost finished?

 

The reason for asking is the discussion I= started two weeks ago regarding integrity only cipher suites, which are no= t longer supported in TLS 1.3. While we most likely can cope with this by utilizing TLS 1.2 further as suggested, one question rem= ains regarding the hash functions in the existing integrity only cipher sui= tes. Currently, there is no integrity only cipher suite defined that combin= es ECDSA and SHA 256. There are only combinations with SHA1. Interestingly, there is one combining RSA and= SHA 256.

 

To no longer depend on SHA1, we would lik= e to standardize a combination of ECDSA and SHA 256 for instance TLS_ECDHE_= ECDSA_WITH_NULL_SHA256. Would this still be possible, given the fact, that TLS 1.3 is likely to be finished in near time. I know that = this depends on the acceptance of the WG, but I would like to ask first, if= there is any intention to close TLS 1.2 for changes and additions, once TL= S 1.3 is ready.

 

Best regards

Steffen

 

--
Steffen Fries
Siemens AG
Corporate Technology
CT RDA ITS
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 636-633604
Fax: +49 89 636-48000
mai= lto:steffen.fries@siemens.com
www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Bo= ard: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Ch= ief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered off= ices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenb= urg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

 

--_000_E6C9F0E527F94F4692731382340B33784A092EDENBGAT9EH2MSXww9_-- From nobody Tue May 2 07:28:28 2017 Return-Path: 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 C2E241294EF for ; Tue, 2 May 2017 07:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 4KV_63U8Whot for ; Tue, 2 May 2017 07:28:25 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FB313144B for ; Tue, 2 May 2017 07:24:53 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v42ECGwA021919; Tue, 2 May 2017 15:24:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ZwRsnm4XKkAKHfYCcTQiS+KFB+Ug/kgba5+Edo8VGkA=; b=NvA/MFaMonJ9jiCeshFviVsWO4zUs7wl/+d00y9Ov95sm8asvYogjvivpnw/Pf8Z7OVA xBRsWZ6dGT39LxTBIttcAv6j4ZYt2FWaW3JnpknwLkY/r74CSYqUAwdoypKnVQ209JC+ b2ONi9hEoXd6b/F2rxRnAdJMgvDmHCtVr2K/NhStvDRZLPyy/OMutloLKDJzTPccjoJD BA/3M6uh3CYBYxnYrF8xZ/bbmXhCEwGHP/L3jU+NneNfXscKjdE8LAuktJ+zlX3irKAh pkc0NGQxDaf9/zqeRg1GtijiXUvJJ71MRQjvL2sBX6Ex0YUPTLmD3jTajMcmWDdvTu5O Fg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2a6e73vucr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 May 2017 15:24:51 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v42ELHIK008869; Tue, 2 May 2017 10:24:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2a4p5vpneh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 May 2017 10:24:50 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 07:24:49 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Tue, 2 May 2017 09:24:49 -0500 From: "Salz, Rich" To: "Fries, Steffen" , "tls@ietf.org" Thread-Topic: Definition of cipher suites for TLS 1.2 still possible? Thread-Index: AdLDTWpeLBLLQHFiTSKY+DwL/vtEYAAAlWlw Date: Tue, 2 May 2017 14:24:49 +0000 Message-ID: <5f28d7e672be47aeb1dd5fd2a33dcf75@ustx2ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.88] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-02_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705020081 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705020081 Archived-At: Subject: Re: [TLS] Definition of cipher suites for TLS 1.2 still possible? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:28:27 -0000 > it may be a na=EFve question, but is it still possible to define and stan= dardize new cipher suites for TLS 1.2 as an RFC, when TLS 1.3 is almost fin= ished?=20 Yes it is. It might be "informational" not "standards-track" but it's cert= ainly possible/allowed/etc.=20 From nobody Tue May 2 07:49:08 2017 Return-Path: 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 37D181316D5 for ; Tue, 2 May 2017 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 os1yBCYY6e13 for ; Tue, 2 May 2017 07:49:00 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BA01316E7 for ; Tue, 2 May 2017 07:44:36 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id p143so35331016yba.2 for ; Tue, 02 May 2017 07:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=yiQUBpoyUeQwajOLuhjJUYDaR/1CePm+T2g0e/kKjAA=; b=HUPmZpyKwT7hbQTdbTpifZ5SWxEDsPMXblDdy8zlxXcVMn05MtWVSSMd0Ma9cRGPo3 Ri36rsYiLtwoA2J01fU5mjjKJPgfgA7uGw8pwyI5mViBwl/yja5UNtqYeMTfdmDb5nm7 YBGD1nyL7o9/MclQ24yQHZyfjQ5DIVARsLYN/rS6lEDr93jqYcgSVRn+47UpTTa+I5mU DEkeYvDOwM3G/gwtLZtE62C0QBnW8Xtd+UqntzF12Ke4NBDmsFFDfmyR+7qBRnOeq8h/ O5sf/RD+OTHzUJSw57ryJp5A1o/ktgqk1eVGzozf7KBChKVwDCVysY7OHg6OVswMNYkc Cpvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yiQUBpoyUeQwajOLuhjJUYDaR/1CePm+T2g0e/kKjAA=; b=ZGlhaTa6BrxCdG41IhYu2kioGKO894o535ahtJ3Z9kBAVYseW64b1BA8kJ4Kl+nuwK ZCQIb5WGQkyZUFHbHD+LB+v1rfvHRHVmUW4+5J6jFDwZ+AWLSCVP0NlAQHdei3nLOYG0 Lyw1yu3DKL+9q85tTtVZZmcZsmAei/fekWgKFebLF5kTcK9IuakEfVaBdAXqRdlTD31g IrCkMemN8XN+I1p2153kop2M/8du/jDMmGN8nvjQPFxiRfrT4YnXbJNp1fHfxelNNU7B gABfZBxDS6xU4/RSI12c1O+ovOcdemIxoEiD/rmOGoEYWFal7gf1CiOkeA47cGwpxGIr wnWA== X-Gm-Message-State: AN3rC/4aNEqS3lewgZG5+/KF/W7WFRn8fygNTGHTDok5dxbxlGnmNCPT mU0u8lRmNOP/bXBz9dmRIlbxZoqR4zUM X-Received: by 10.37.16.212 with SMTP id 203mr11617456ybq.90.1493736275864; Tue, 02 May 2017 07:44:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 07:44:35 -0700 (PDT) From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 07:44:35 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c0ff041c8acc054e8b9496 Archived-At: Subject: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:49:02 -0000 --001a11c0ff041c8acc054e8b9496 Content-Type: text/plain; charset=UTF-8 On Sunday at the TLS:DIV workshop I presented a summary of findings of a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. Thanks to feedback in the room I've now tightened up the findings from the review and posted them as an issue on the draft GitHub repo: https://github.com/tlswg/tls13-spec/issues/1001 I'll summarize the summary: Naturally the focus was on forward secrecy and replay. On forward secrecy the main finding was that it's not necessary to trade off Forward Secrecy and 0-RTT. A single-use session cache can provide it, and with the modification that ekr has created in https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both pre-auth and post-auth tickets, and it allows clients to build up pools of meaningfully distinct tickets. There's also an observation there that it should really be that clients "MUST" use tickets only once. Any re-use likely discloses the obfuscated ticket age, which is intended to be secret. Right now it's a "SHOULD". On replay, the main finding is that what's in the draft is not workably secure, and the review includes 5 different attacks against 0-RTT data to illustrate that. Attacks 1 and 2 show that the kind of replay permitted by the draft is very different from the kind of replay permitted by dkg's existing downgrade-and-retry attack. I also go over why it very very difficult to many applications to achieve that idempotency, and why one idempotency pattern actually relies on non-replayable messages. Attack 3 shows that idempotency is not sufficient, applications must also be free of measurable side-effects, which is not practical. Attack 4 shows that 0-RTT breaks a common security mechanism: spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability enables an additional form of traffic analysis. The recommendation in the review is that implementations "MUST" prevent replays of 0-RTT section, with some additional discussion about why the existing advice is unlikely to be followed, and why consistent interoperability matters here. Unfortunately, I wasn't aware until Friday that this review would be coming so late in the TLD1.3 draft process, and my apologies for that. I am now planning to attend the future WG in-person meetings and look forward to seeing many of you there. -- Colm --001a11c0ff041c8acc054e8b9496 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday at the TLS:DIV workshop I presented a summary of= findings of a security review we did on TLS1.3 0-RTT, as part of implement= ing 1.3 in s2n. Thanks to feedback in the room I've now tightened up th= e findings from the review and posted them as an issue on the draft GitHub = repo:


I'll summarize the summary: Naturally the focus was on = forward secrecy and replay. On forward secrecy the main finding was that it= 's not necessary to trade off Forward Secrecy and 0-RTT. A single-use s= ession cache can provide it, and with the modification that ekr has created= in=C2=A0https://github.com/tlswg/tls13-spec/pull/998 , such a cac= he works for both pre-auth and post-auth tickets, and it allows clients to = build up pools of meaningfully distinct tickets.

T= here's also an observation there that it should really be that clients = "MUST" use tickets only once. Any re-use likely discloses the obf= uscated ticket age, which is intended to be secret. Right now it's a &q= uot;SHOULD".=C2=A0

On replay, the main findin= g is that what's in the draft is not workably secure, and the review in= cludes 5 different attacks against 0-RTT data to illustrate that. Attacks 1= and 2 show that the kind of replay permitted by the draft is very differen= t from the kind of replay permitted by dkg's existing downgrade-and-ret= ry attack. I also go over why it very very difficult to many applications t= o achieve that idempotency, and why one idempotency pattern actually relies= on non-replayable messages.=C2=A0

Attack 3 shows = that idempotency is not sufficient, applications must also be free of measu= rable side-effects, which is not practical.=C2=A0 Attack 4 shows that 0-RTT= breaks a common security mechanism: spoofing-resistant throttles. Attack 5= shows that 0-RTT replay-ability enables an additional form of traffic anal= ysis.=C2=A0

The recommendation in the review is th= at implementations "MUST" prevent replays of 0-RTT section, with = some additional discussion about why the existing advice is unlikely to be = followed, and why consistent interoperability matters here.=C2=A0

Unfortunately, I wasn't aware until Friday that this re= view would be coming so late in the TLD1.3 draft process, and my apologies = for that. I am now planning to attend the future WG in-person meetings and = look forward to seeing many of you there.=C2=A0

--
Colm
--001a11c0ff041c8acc054e8b9496-- From nobody Tue May 2 08:28:43 2017 Return-Path: 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 02589131462 for ; Tue, 2 May 2017 08:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 iK3nbxrLw3-D for ; Tue, 2 May 2017 08:28:30 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C47D1314D0 for ; Tue, 2 May 2017 08:25:41 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id g60so115160117qtd.3 for ; Tue, 02 May 2017 08:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=36a6iSFSH1H8UlI1RSlmu5++0obVqYQCaKkgoBMnBZM=; b=neepD3YklfSwqdKmYyipclDBSItOik0cGfeba7ZT9R+tp0IRxNOxE1FLv5Kp8EwTl6 voyw0WF49snPoK7jkj8MX+EGbk5SOdIifCY8kgTI+fTS2PD/9ycBPZqAj+2yTM5lwzMn 08Ut167c75LcNOY7O46EATsGDzILOy8/lXiZA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=36a6iSFSH1H8UlI1RSlmu5++0obVqYQCaKkgoBMnBZM=; b=b+IIpfm03glGV1YYdyY/+QUeZ/0Ee2sFwmsHcB+8xp/13KVBm8x1LPlQBXfbUzyh6h zzSvQeBDnPMMqho1/kfdVYEccX6YJyizY37ttwdVydeGbW0DhOWyQq9wOFjzKqLuC0ob DWGJpxdtu+/8wc2whUgNQMWVtRC/5r8gkB4LVg2/oXRuou2lUFICkLUjVPsl7/xflqg+ wKLxN6nN7L/UprA4UZwVXin32P8QU5f/QtaKeNDdsFGxU0Hfdmr3GJQLWlKo2bmfMOkn 80nDDZiXwv8kx4hBvqeBjjCY+qK8jAPl16RnnR6cUj0cAIOv9Su1daTSiOXY9FMNRStZ F3Cg== X-Gm-Message-State: AN3rC/5cwmQK2YxoVLZ8/eRcY5i7ptTOKgkpfRXm33323hAV5Tr9QKxC 4gI99oH2zNCPNdLZJ5uElWRH1wiZLA== X-Received: by 10.237.57.170 with SMTP id m39mr26140583qte.163.1493738740632; Tue, 02 May 2017 08:25:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.65 with HTTP; Tue, 2 May 2017 08:25:40 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <5f28d7e672be47aeb1dd5fd2a33dcf75@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <5f28d7e672be47aeb1dd5fd2a33dcf75@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Kyle Rose Date: Tue, 2 May 2017 11:25:40 -0400 Message-ID: To: "Salz, Rich" Cc: "Fries, Steffen" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11404b9c06072f054e8c2763 Archived-At: Subject: Re: [TLS] Definition of cipher suites for TLS 1.2 still possible? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:28:33 -0000 --001a11404b9c06072f054e8c2763 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2017 at 10:24 AM, Salz, Rich wrote: > > it may be a na=C3=AFve question, but is it still possible to define and > standardize new cipher suites for TLS 1.2 as an RFC, when TLS 1.3 is almo= st > finished? > > Yes it is. It might be "informational" not "standards-track" but it's > certainly possible/allowed/etc. > Whether it's worth doing or not depends on the objective. If the desire is to get support for a new TLS 1.2 cipher suite into browsers or open source TLS stacks, well... good luck with that. If the desire is to get something working for their own internal use, standardization is not really necessary, though I would certainly advise doing whatever is required to get a code point from IANA. If the desire is somewhere in the middle, such as internal use plus interop with other organizations within an industry or consortium, then publication of an informational RFC might make sense. I'm skeptical, however, that they will get a lot of attention from folks on this list as there seems to be little interest in spending time on a legacy protocol; and pursuing something standards track will probably go nowhere. Kyle --001a11404b9c06072f054e8c2763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 2, 2017 at 10:24 AM, Salz, Rich <rsalz@akamai.com> wr= ote:
> it may be a na= =C3=AFve question, but is it still possible to define and standardize new c= ipher suites for TLS 1.2 as an RFC, when TLS 1.3 is almost finished?

Yes it is.=C2=A0 It might be "informational" not "sta= ndards-track" but it's certainly possible/allowed/etc.

Whether it's worth doing or not depends on the= objective.

If the desire is to get support for a new TLS 1.2 cipher= suite into browsers or open source TLS stacks, well... good luck with that= . If the desire is to get something working for their own internal use, sta= ndardization is not really necessary, though I would certainly advise doing= whatever is required to get a code point from IANA.

If the desire i= s somewhere in the middle, such as internal use plus interop with other org= anizations within an industry or consortium, then publication of an informa= tional RFC might make sense. I'm skeptical, however, that they will get= a lot of attention from folks on this list as there seems to be little int= erest in spending time on a legacy protocol; and pursuing something standar= ds track will probably go nowhere.

Kyle
--001a11404b9c06072f054e8c2763-- From nobody Tue May 2 10:37:05 2017 Return-Path: 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 D7D1112EC4E for ; Tue, 2 May 2017 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 KqLmIVNtJZGs for ; Tue, 2 May 2017 10:37:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6772F131495 for ; Tue, 2 May 2017 10:33:39 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2DA4E7A32F1; Tue, 2 May 2017 17:33:38 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 2 May 2017 13:33:37 -0400 Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:37:04 -0000 > On May 2, 2017, at 10:44 AM, Colm MacC=C3=A1rthaigh = wrote: >=20 > https://github.com/tlswg/tls13-spec/issues/1001 >=20 > I'll summarize the summary: Naturally the focus was on forward secrecy = and replay. On forward secrecy the main finding was that it's not = necessary to trade off Forward Secrecy and 0-RTT. A single-use session = cache can provide it, and with the modification that ekr has created in = https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for = both pre-auth and post-auth tickets, and it allows clients to build up = pools of meaningfully distinct tickets. >=20 > There's also an observation there that it should really be that = clients "MUST" use tickets only once. Any re-use likely discloses the = obfuscated ticket age, which is intended to be secret. Right now it's a = "SHOULD". Well, just a few days ago there was a discussion of ticket re-use, and I was re-assured that ticket re-use was likely to going to work just = fine... https://www.ietf.org/mail-archive/web/tls/current/threads.html#23035 TLS is a general-purpose protocol, used broadly beyond just the browser = space. With TLS in SMTP there's no demand or need for 0-RTT and server = resources are often more constrained than you'd find on a CDN server farm. Repeat = connections are spaced further apart, and session lifetimes are longer (Postfix = defaults to an hour). For Postfix, going back to a server-side session *increases* risk of = loss of forward secrecy, because bulky server-side session objections are = written out an on disk database, and e.g. with LMDB (a COW database) may take a long = time to be deleted. By contrast session ticket encryption keys (STEKs) are = small, kept in memory, and are overrwritten and freed after ~2 hours. Going back to server-side sessions would reduce resumption security for = Postfix, and would make servers more susceptible to DoS through cache exhaustion. On the client side, non-reusable tickets would require substantially = more complex cache designs, and probably significant changes in the session APIs and = internals of TLS toolkits rather late in the evolution of the TLS 1.3 support = code. I am far from convinced that the effort would not be better spent = improving STEK key management in TLS server farms, which will need to support TLS 1.2 = in parallel with TLS 1.3 for quite a long time (likely a decade or more). I believe that the proposed change is well intentioned but = counter-productive. --=20 Viktor.= From nobody Tue May 2 10:42:07 2017 Return-Path: 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 BD91412955F for ; Tue, 2 May 2017 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Memn4g8b5mK2 for ; Tue, 2 May 2017 10:42:05 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D04A12EB11 for ; Tue, 2 May 2017 10:39:09 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 137D0C086D1D; Tue, 2 May 2017 10:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; s=cryptonector.com; bh=h /AZfySJgToxmDcTOEZSJ42i16g=; b=nQFj+SfXBu9uXheSw9MeimWhpsl6xWurf 4IfDjqKQKS2Q+KsqFPCioQkRRA2oUnQE0yyx63HZfYyVtkSu8Aeyni4vNgHl1K3r dV168B5TVIKeIdB/tJOIwrx76MihydcThcDEPUX6r/hP5urVFFaqqIVaVpJgRjKk lyC/gAHruk= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id BC1B0C086D0C; Tue, 2 May 2017 10:39:08 -0700 (PDT) Date: Tue, 2 May 2017 12:39:06 -0500 From: Nico Williams To: TLS WG Message-ID: <20170502173905.GC10188@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:42:07 -0000 On Tue, May 02, 2017 at 01:33:37PM -0400, Viktor Dukhovni wrote: > > On May 2, 2017, at 10:44 AM, Colm MacC=E1rthaigh = wrote: > > https://github.com/tlswg/tls13-spec/issues/1001 > >=20 > > I'll summarize the summary: Naturally the focus was on forward > > secrecy and replay. On forward secrecy the main finding was that > > it's not necessary to trade off Forward Secrecy and 0-RTT. A > > single-use session cache can provide it, and with the modification > > that ekr has created in https://github.com/tlswg/tls13-spec/pull/998 > > , such a cache works for both pre-auth and post-auth tickets, and it > > allows clients to build up pools of meaningfully distinct tickets. With existing APIs, dealing with "pools of meaningfully distinct tickets" seems meaningfully non-trivial. > > There's also an observation there that it should really be that > > clients "MUST" use tickets only once. Any re-use likely discloses > > the obfuscated ticket age, which is intended to be secret. Right now > > it's a "SHOULD". Why should ticket age disclosure be a problem? How does ticket one-time use not do the same? > Well, just a few days ago there was a discussion of ticket re-use, and > I was re-assured that ticket re-use was likely to going to work just > fine... I sure hope so!! Nico --=20 From nobody Tue May 2 10:51:11 2017 Return-Path: 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 2695E129C30 for ; Tue, 2 May 2017 10:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 qI9-FvxTv4sG for ; Tue, 2 May 2017 10:51:06 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B552C129C73 for ; Tue, 2 May 2017 10:47:59 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 516A8C086D1E; Tue, 2 May 2017 10:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; s=cryptonector.com; bh=+ o9JjhMmQWRI9BIFDb0+emX3EC0=; b=W8Ir5I95MvGj5qc+IRc5N0Gu1BtCxkMYF A8ijJy8KBUbLIpx8ON4UZ+VgsehdOI/9hitNBZWu8QHJ5iFEIUJEc9KuSB5mJ4M+ LI+iPEDRTN+/+aK0FTF0kApGGMj4//5mDbbQR/nv+n9F1NY65/haDaciEsG901KZ DvoXho6IdI= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 01029C086D1D; Tue, 2 May 2017 10:47:58 -0700 (PDT) Date: Tue, 2 May 2017 12:47:56 -0500 From: Nico Williams To: TLS WG Message-ID: <20170502174755.GD10188@localhost> References: <20170502173905.GC10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20170502173905.GC10188@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:51:09 -0000 On Tue, May 02, 2017 at 12:39:06PM -0500, Nico Williams wrote: > On Tue, May 02, 2017 at 01:33:37PM -0400, Viktor Dukhovni wrote: > > > On May 2, 2017, at 10:44 AM, Colm MacC=E1rthaigh wrote: > > > https://github.com/tlswg/tls13-spec/issues/1001 > > >=20 > > > I'll summarize the summary: Naturally the focus was on forward > > > secrecy and replay. On forward secrecy the main finding was that > > > it's not necessary to trade off Forward Secrecy and 0-RTT. A > > > single-use session cache can provide it, and with the modification > > > that ekr has created in https://github.com/tlswg/tls13-spec/pull/99= 8 > > > , such a cache works for both pre-auth and post-auth tickets, and i= t > > > allows clients to build up pools of meaningfully distinct tickets. >=20 > With existing APIs, dealing with "pools of meaningfully distinct > tickets" seems meaningfully non-trivial. >=20 > > > There's also an observation there that it should really be that > > > clients "MUST" use tickets only once. Any re-use likely discloses > > > the obfuscated ticket age, which is intended to be secret. Right no= w > > > it's a "SHOULD". >=20 > Why should ticket age disclosure be a problem? How does ticket one-tim= e > use not do the same? Also, let's separate ticket re-use and 0-rtt. The former is generally desirable and workable. The two might not be, but if so one should expect a "SHOULD NOT" or "MUST NOT" to be specifically about the combination of tickets and 0-rtt. Also, the "SHOULD NOT" should have guidance as to when/why one might do it anyways. For many applications the leakage in re-using tickets w/ 0-rtt will be a non-issue. Nico --=20 From nobody Tue May 2 10:51:44 2017 Return-Path: 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 304C3126E3A for ; Tue, 2 May 2017 10:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 SZJu2FhfvwUY for ; Tue, 2 May 2017 10:51:42 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86693129A9B for ; Tue, 2 May 2017 10:48:30 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l18so73664445ywh.3 for ; Tue, 02 May 2017 10:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=usDucXaM9QImhrK84ULKJk5jj9hcZ827qGQEFIzEIt4=; b=TJ6sMD0qZXKjatBEAND1TLJGTrxYFOEx1NuDco4xggwfH3mvt6aLardbltzEUBl3CS U0O2kXFQkdB9tP4VahRE/QFhzowoiw44WDfJcTvPf/FjcEzDJz2yI6LgNrBrP78hHRI1 LiFzOg9Ih4HSDy7wd/K+fIUecekVYNN41Ja1JwCGqfs/1H3H84WJGBml82mV2jII8bEO KatYtOgL63fTjAgOx4jtmXNHjJTmXevkv8zurgVLmU8KlG8/MJYh9+uOgPwgkWdoto/O +JW0YKlX7iTA1O00oWbdwQqXsmBycvhdwyUkh6eLGFdHvk87WzDh9sl3s/yOz21H3pcd AvLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=usDucXaM9QImhrK84ULKJk5jj9hcZ827qGQEFIzEIt4=; b=sIa9yzku8VcPbcAzd4PabOQNgTRVuqD3DnHkF2T9cGnY41/r0OdBQc8i7LEORsKlp+ 6fmvYOdc0fvAjuFEVyNtVDondvN7of5igM+gNrOyWUfIhEqTerIaLTQf36GI9kzQMinP sczti+flKnrOuQe24G1ASC33j3tZ949nsQl435ElPqhLizMdVevrJqxvJCXgnQeZlmwp BhETGRpPDqd9QSox6MvMcxWOquE7fzvHOJTBsVwObEnYFoqvYnlb+YBXJs4/x6QUj0uj lYSkZ15vrDAM2jLzD4hvQSXOEEm+WyTwxR5P0WsX9WmuJBHjKA+M7tSMFjnaGD3HCVag /Smw== X-Gm-Message-State: AN3rC/4oaMxLx+aZI1DbuiFN5B3lkpo3YkACae1mhDBQEeWnjw/xpZEC B8VubL4jQiB4lxou0aBq0Hcp6/MGZw== X-Received: by 10.13.238.65 with SMTP id x62mr25164304ywe.122.1493747309849; Tue, 02 May 2017 10:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 10:48:29 -0700 (PDT) In-Reply-To: <20170502173905.GC10188@localhost> References: <20170502173905.GC10188@localhost> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 10:48:29 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary=94eb2c034d8cc9c50b054e8e25c1 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:51:44 -0000 --94eb2c034d8cc9c50b054e8e25c1 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 10:39 AM, Nico Williams wrote: > With existing APIs, dealing with "pools of meaningfully distinct > tickets" seems meaningfully non-trivial. > I would actually prefer if the client could request N tickets, but was advised that this was too large a change to the protocol. > > There's also an observation there that it should really be that > > > clients "MUST" use tickets only once. Any re-use likely discloses > > > the obfuscated ticket age, which is intended to be secret. Right now > > > it's a "SHOULD". > > Why should ticket age disclosure be a problem? How does ticket one-time > use not do the same? > The draft writes that it is to prevent connection correlation attacks. -- Colm --94eb2c034d8cc9c50b054e8e25c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 10:39 AM, Nico Williams <nico@cryptonector.= com> wrote:
With existing A= PIs, dealing with "pools of meaningfully distinct
tickets" seems meaningfully non-trivial.

I would actually prefer if the client could request N tickets, but w= as advised that this was too large a change to the protocol.=C2=A0

> > There's also an observation there that it should really be th= at
> > clients "MUST" use tickets only once. Any re-use likely= discloses
> > the obfuscated ticket age, which is intended to be secret. Right = now
> > it's a "SHOULD".

Why should ticket age disclosure be a problem?=C2=A0 How does ticket= one-time
use not do the same?

The draft writes t= hat it is to prevent connection correlation attacks. =C2=A0

--
Colm
--94eb2c034d8cc9c50b054e8e25c1-- From nobody Tue May 2 10:55:38 2017 Return-Path: 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 693CC129BD7 for ; Tue, 2 May 2017 10:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 SfOEKbVcHai0 for ; Tue, 2 May 2017 10:55:35 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DED129AF2 for ; Tue, 2 May 2017 10:52:31 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id s22so36861597ybe.3 for ; Tue, 02 May 2017 10:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=d5KqJaUJ7BjQxzO8mdsx7tL62abWbkRJtEV7v9S1qfw=; b=mkssmZfV1Zu3HoScR0yZyPeEAlgf9dLkkKwxHxcFtceWg5lCc8WiS9NaemeMmeeFMX bqYI/fT9B0p2yUBES9hoGgDkOztEzIL1FQGC2F9Jo3vhwUsF8dC7fZRwYtA0eHDNGq7I ClmIrd2wKsU8TUtV/K7rMgE7ejvVVV9qOrCM9xggjgjakPSUb7VK9ciqmPsu8VfVkhe0 ppSnPNOTSFMHtwc3qgfslEl3JA4Bte20pf6UaXOWAGCZ63jpqowUSzh7I/MQIC+RLLpq xh0SQBQHm9YLE7sMQakTu4gFzwyb1K3mdJLnqPOld1QxNePiDnnMo3/NeaD09ETFL55K M5uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=d5KqJaUJ7BjQxzO8mdsx7tL62abWbkRJtEV7v9S1qfw=; b=bqE4bY7NkT3m0ER95tYJiBxiTfv/XYkNGoIsAzZQGZm+OJb0Wr8T5+vKciwZ2szb86 OJ2ajAGWeQUrCm9eH8FtUMPa15emhmP8iNBMwScEPf5fKDRdTF46OCRpEZhP7ri4IX74 g92bk2WWcIMdPp4t+Q82jw5GY4TRgUMLVUeZUtnhwZoY5sWjwyOO3EUDjVzkPnsgwAQG 0Jdcd6k2QKaUxhcXdT1zAhVIoH2+RVkeTTf+ao/ljpqqs+gLJH2IF6rF4ZYmbxJbKB8o ObLoTpDcC6yk9acFBws1EkPMUdEd75nKsgZTX7ITq439pf9ejdXhRe76ap/yEOi8dqGv ZPlg== X-Gm-Message-State: AN3rC/4PW5f6SLP0gc0LO4N4SgUZbyjqBeJvaN42qWc9QHpacb/lcGMy tK+a00EDSQQsugMZ6hkAoILVVkR9XF5z X-Received: by 10.37.163.195 with SMTP id e61mr10684182ybi.13.1493747550237; Tue, 02 May 2017 10:52:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 10:52:29 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 10:52:29 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=f403045c05f81ddfdf054e8e34dd Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:55:37 -0000 --f403045c05f81ddfdf054e8e34dd Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 10:33 AM, Viktor Dukhovni wrote: > > I believe that the proposed change is well intentioned but > counter-productive. > Note that the recommendation in the review is: 'TLS1.3 should require that TLS implementions handling 0-RTT "MUST" provide a mechanism to prevent duplicate tickets from being used for 0-RTT data' it is not quite about the general use of tickets - only as they pertain to 0-RTT data. My understanding is that 0-RTT is not particularly interesting for SMTP, so would that be ok? -- Colm --f403045c05f81ddfdf054e8e34dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 10:33 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
I believe that the proposed change is well intentioned but counter-producti= ve.

Note that the recommendation in the= review is:

=C2=A0'TLS1.3 = should require that TLS implementions handling 0-RTT "MUST" provi= de a mechanism to prevent duplicate tickets from being used for 0-RTT data&= #39;

it is not quite about the general use of tickets= - only as they pertain to 0-RTT data.=C2=A0 My=C2=A0understanding is that = 0-RTT is not particularly interesting for SMTP, so would that be ok?=


--
Colm
--f403045c05f81ddfdf054e8e34dd-- From nobody Tue May 2 11:03:51 2017 Return-Path: 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 5B7AA129401 for ; Tue, 2 May 2017 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Rg1Tw13HbKkc for ; Tue, 2 May 2017 11:03:48 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DD212ECA7 for ; Tue, 2 May 2017 11:00:53 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id DADA0C0028A6; Tue, 2 May 2017 11:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=5OwiGNHwsZ0XRMrINlyi0WXVhzU=; b=LygXP/uOX/v QmSh/56gItr5RQA1TG8LpsnCky9RSWysQ1M3HlyXMFlKUuybpKKlVyeNgOpcuX3s dmNhdwY4VvilkFfrgfROfoSjKkT9mCkb5296H3kfraS9YxATIJ6Ykwe6ZZaw5CF3 v05pmz5zEDyxwiyEE3r+ZyBWFXs8hzo8= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 736B9C0028A3; Tue, 2 May 2017 11:00:52 -0700 (PDT) Date: Tue, 2 May 2017 13:00:50 -0500 From: Nico Williams To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Cc: TLS WG Message-ID: <20170502180049.GE10188@localhost> References: <20170502173905.GC10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:03:49 -0000 On Tue, May 02, 2017 at 10:48:29AM -0700, Colm MacC=E1rthaigh wrote: > On Tue, May 2, 2017 at 10:39 AM, Nico Williams > wrote: > > With existing APIs, dealing with "pools of meaningfully distinct > > tickets" seems meaningfully non-trivial. >=20 > I would actually prefer if the client could request N tickets, but was > advised that this was too large a change to the protocol. >=20 > > > There's also an observation there that it should really be that > > > > clients "MUST" use tickets only once. Any re-use likely discloses > > > > the obfuscated ticket age, which is intended to be secret. Right = now > > > > it's a "SHOULD". > > > > Why should ticket age disclosure be a problem? How does ticket one-t= ime > > use not do the same? > > >=20 > The draft writes that it is to prevent connection correlation attacks. I would think that the ticket itself is enough for that when using 0-rtt. I.e., if you don't want connection correlation to be possible, you can't use 0-rtt. The age business (which I hadn't looked into before) seems incidental. (Also, one would think that the client would send a timestamp in an authenticator... You know, a lot like what Kerberos does.) Nico --=20 From nobody Tue May 2 11:11:10 2017 Return-Path: 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 354CB129BFC for ; Tue, 2 May 2017 11:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 RmZWf1JCYiEA for ; Tue, 2 May 2017 11:11:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8955129C3F for ; Tue, 2 May 2017 11:08:04 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3B4137A32F1 for ; Tue, 2 May 2017 18:08:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 2 May 2017 14:08:03 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:11:08 -0000 > On May 2, 2017, at 1:52 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > it is not quite about the general use of tickets - only as they = pertain to 0-RTT data. My understanding is that 0-RTT is not = particularly interesting for SMTP, so would that be ok? Yes, if the change is narrowly tailored to 0-RTT, *and* if server TLS = stacks don't stop supporting ticket reuse for "normal" (not 0-RTT) sessions, = then I have no direct concerns with changes that affect 0-RTT alone. --=20 Viktor. From nobody Tue May 2 11:18:21 2017 Return-Path: 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 CFBEA129C0B for ; Tue, 2 May 2017 11:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 KiyI_2CSIVvw for ; Tue, 2 May 2017 11:18:18 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF65127868 for ; Tue, 2 May 2017 11:15:07 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id 8so37009671ybw.1 for ; Tue, 02 May 2017 11:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EftiTaJwacr+bNj6nfmQ/LtnN9J8LbD0kGi9BWdCAcI=; b=XwuIfrzwrE47WKwvFdibiZ0eaKZc8FDvCL3tP8lrJqNXQwj0zhzeZ4Mza+tZR/I1xH VYhjb4p2AUw1tvXyGQC2/DuBugWfaHniw4SVyYoNQIY5bLgTgRpF5EwlWS8tGCQE5/uN pHJGEf3gefZYaoxn+pLGZAiVXo9ycYSs8ZZhkSW0r3pMWSN9JWwJhtVdml9SRsWHrL1r DqqlWNTZUfuK8sSJFh0ocP03qQ4KGY+dZTBZs+UPx1fLoAxwbQpJr7pbtdzDAtfde5+G TSNMzSEBF4Tc0Bbqa/bm9yBkKDnQgA/wNPfsdzifrV8RaDcfnAHVgJqYeYLmWbInecM6 ChhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EftiTaJwacr+bNj6nfmQ/LtnN9J8LbD0kGi9BWdCAcI=; b=i++6woihwNFU5EvLrgD1KO/aU40d8pgcLDbpwHExAqpHklIz2WA4kJ3nCsLdMn7qed AZfHh92I3WcsVLIOzL1a7yhktMDQb9LdEgw2vQhWUutCC+R3SslWw0ZBFz9Fapvv9iPb snjhZ3pNnCvqozCUyBwTDZ0jVKrzC2zUkxQs1MrM5bpKorISiTblRLzZAt6yoBhowXRV aDnNKRuHV1wDsHHVerhCM+erDZaIgTRk55Gwn281DbSi263puq2+CrL4A7IiV0L5QcgZ rfeLu9bYuocu3duQaKEEcLK/588O0EWiNpWjM6+VZbEMPiPbrLOlIehoQXOnPSFIOkbG vvYg== X-Gm-Message-State: AN3rC/5Xb0fj0RXyhLRaCAd76JZopojzTfUiGbTtH8eGMmvTwY6vxCXM 8iH/FqmWGvR9qPKxQcfBdsTp9avtfw== X-Received: by 10.37.15.213 with SMTP id 204mr68022ybp.127.1493748906793; Tue, 02 May 2017 11:15:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 11:15:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 11:15:06 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a113f5ae6f95e42054e8e8488 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:18:20 -0000 --001a113f5ae6f95e42054e8e8488 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 11:08 AM, Viktor Dukhovni wrote: > Yes, if the change is narrowly tailored to 0-RTT, *and* if server TLS > stacks > don't stop supporting ticket reuse for "normal" (not 0-RTT) sessions, then > I have no direct concerns with changes that affect 0-RTT alone. > Great - I added a small errata comment on the github issue just recording that too. In that case, I only reason I see to stop using tickets multiple times is to protect the obfuscated age. It reads to me like its purpose would just be defeated. Is it really that hard for clients to use a 1-for-1 use-a-ticket-get-a-ticket approach? -- Colm --001a113f5ae6f95e42054e8e8488 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 11:08 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
Yes, if the= change is narrowly tailored to 0-RTT, *and* if server TLS stacks
don't stop supporting ticket reuse for "normal" (not 0-RTT) s= essions, then
I have no direct concerns with changes that affect 0-RTT alone.

Great - I added a small errata comment on the gith= ub issue just recording that too.=C2=A0

In that ca= se, I only reason I see to stop using tickets multiple times is to protect = the obfuscated age. It reads to me like its purpose would just be defeated.= Is it really that hard for clients to use a 1-for-1 use-a-ticket-get-a-tic= ket approach?

--
Colm
--001a113f5ae6f95e42054e8e8488-- From nobody Tue May 2 11:20:03 2017 Return-Path: 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 88EA7129C21 for ; Tue, 2 May 2017 11:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 2R5IHmL7gEPU for ; Tue, 2 May 2017 11:20:00 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C43E1314A6 for ; Tue, 2 May 2017 11:16:57 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 51C8EC086D1D; Tue, 2 May 2017 11:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; s=cryptonector.com; bh=a Vod6ixKGZi6FWuNMI4hZwDR6Ag=; b=mQ+8y/RT1zfOczkEmsUysSmXBeS/YGSJr /LCvjPjzPyInVilvYZYYs3LxR+E6OpwBqCFFPTQdi2dKaRbn07ZSbmFlwQ/vxHJN uENtHgp0F9pnhgl80ifYOIQ+X8a2Gysx9I5ypLVJMLxZ416OvNGUCaLtX7CFiWhm YptMIvcSfo= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id F1F33C0028A6; Tue, 2 May 2017 11:16:55 -0700 (PDT) Date: Tue, 2 May 2017 13:16:53 -0500 From: Nico Williams To: TLS WG Message-ID: <20170502181652.GF10188@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:20:02 -0000 On Tue, May 02, 2017 at 02:08:03PM -0400, Viktor Dukhovni wrote: > > On May 2, 2017, at 1:52 PM, Colm MacC=E1rthaigh w= rote: > > it is not quite about the general use of tickets - only as they > > pertain to 0-RTT data. My understanding is that 0-RTT is not > > particularly interesting for SMTP, so would that be ok? >=20 > Yes, if the change is narrowly tailored to 0-RTT, *and* if server TLS s= tacks > don't stop supporting ticket reuse for "normal" (not 0-RTT) sessions, t= hen > I have no direct concerns with changes that affect 0-RTT alone. In many environments (e.g., intra-corporate) the connection correlation issue might not be a concern at all. Though, of course, the default should be (MUST) to assume that connection correlation is a concern. So I would insist on the change being no stronger than "MUST NOT reuse tickets with 0-rtt unless connection correlation is not an issue for the application/user". Nico --=20 From nobody Tue May 2 11:20:56 2017 Return-Path: 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 E379D1294DF for ; Tue, 2 May 2017 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 PoJcy4WtQ3cr for ; Tue, 2 May 2017 11:20:53 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7C31294B8 for ; Tue, 2 May 2017 11:17:43 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l18so74079209ywh.3 for ; Tue, 02 May 2017 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TS1ayfEgi4Np1JuQFunqkPfANw2Z1oy52CQYPTrECoU=; b=QA7LO74Ssh/MRN3y6qgrMdnm1p5B2ZkuaChS61pDl3/LbrWy8mfkZFz5elJ6y37UKb GifsnDOWUAM40bJXgT5HLdpzLArUVQoMaKRte9TN/zGfxhljCAMb2JvHCVzr3M48jOYE 1B2sBInPn0Fj/VSfi+ETv0XCIkxfGKm7fjVWgRkZiLkhYIQjJt571EgLZb8XFo7hYVQg 4jOBQOZfmNqUnP7Fi1WDu2LE4Qyj/yEJq0mDbenu6cukmc8tLsfwj99AXBrrdt0ChCWj dsyrw+MjGOO3fZkbpMUP1V6kwKDqtiSW8HAJXuvCkGEd5jRUxUhSbFXUjRAWWj0UqAMU MNiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TS1ayfEgi4Np1JuQFunqkPfANw2Z1oy52CQYPTrECoU=; b=re3h0lsm9Hm43LTEIbtxzW9Ob15+ypkdybF0iz4fLYTvnzabvGVFOHEBR+x23Yi8bB J7EjrhVXV0HRmnGSMIOCVlp4VnNSp5TcW7QDMOskvXk1u7yzkC5RHb8ZKwIcV2HHl0Rf XJREzIiKeZ64TxuLiCSiNZKA40T4oc7HEioyRfL3DcPELcyXzDYeolxB/wx3mLR9zdf5 P9xQbXr+GqBPAHsHULVbl8ST5Bl+v2R9oYFemuUvjwW4JuLQTQM7BQCBWHeMVw58LmDj t3tPwgxHvCFD7HBPPv7aen5kd7eStN6YsbBXcULvZXZzuNaU5D+Ct4miE37ixjWvvWEa Z1ow== X-Gm-Message-State: AN3rC/4cx2aZqx0i7gRt4xRnCSlddoKHqt0fA42B46W6SEievhECF3zH 7sQJc6aHqDT53kF1VgHtQJOKzP+VKA== X-Received: by 10.129.152.4 with SMTP id p4mr25651953ywg.1.1493749062570; Tue, 02 May 2017 11:17:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 11:17:42 -0700 (PDT) In-Reply-To: <20170502180049.GE10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 11:17:42 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary=94eb2c0bd9ee4261d7054e8e8e77 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:20:55 -0000 --94eb2c0bd9ee4261d7054e8e8e77 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 11:00 AM, Nico Williams wrote: > I would think that the ticket itself is enough for that when using > 0-rtt. I.e., if you don't want connection correlation to be possible, > you can't use 0-rtt. I don't think so. If the ticket is encrypted when it issued, I don't follow how it could be used to correlate the original connection with the 0-RTT connection. -- Colm --94eb2c0bd9ee4261d7054e8e8e77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 11:00 AM, Nico Williams <nico@cryptonector.= com> wrote:
I would think that the ticket= itself is enough for that when using
0-rtt.=C2=A0 I.e., if you don't want connection correlation to be possi= ble,
you can't use 0-rtt.=C2=A0

I don't think so. If the ticket is = encrypted when it issued, I don't follow how it could be used to correl= ate the original connection with the 0-RTT connection.
--
Colm
--94eb2c0bd9ee4261d7054e8e8e77-- From nobody Tue May 2 11:28:01 2017 Return-Path: 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 90FCF129B8D for ; Tue, 2 May 2017 11:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 fRf5bLPgTPdU for ; Tue, 2 May 2017 11:27:58 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21DF127843 for ; Tue, 2 May 2017 11:25:33 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 438A2C086D1D; Tue, 2 May 2017 11:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=nwPAFOUAMuRlqHqzVnIgXQZPwdQ=; b=mBRAFbcar1g EdZiz1B/T3OEFL93R9Hxki/jfkud+NsMuuxPmoxS9R6cLn5QcWVvUFr57bW790U/ 07UoObfwHGDkssNqBYif0wNiQKxXbYy32vwDgqFNAKsbGansukfntmoBIZfvAe8+ LpdMI9S8OgFZmd4reDspnlP0tOC5zqq0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id B41A1C0028A3; Tue, 2 May 2017 11:25:32 -0700 (PDT) Date: Tue, 2 May 2017 13:25:30 -0500 From: Nico Williams To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Cc: TLS WG Message-ID: <20170502182529.GG10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:28:01 -0000 On Tue, May 02, 2017 at 11:17:42AM -0700, Colm MacC=E1rthaigh wrote: > On Tue, May 2, 2017 at 11:00 AM, Nico Williams > wrote: > > I would think that the ticket itself is enough for that when using > > 0-rtt. I.e., if you don't want connection correlation to be possible= , > > you can't use 0-rtt. >=20 > I don't think so. If the ticket is encrypted when it issued, I don't fo= llow > how it could be used to correlate the original connection with the 0-RT= T > connection. The ticket's _ciphertext_ is not visible to the eavesdropper when it is issued, but it IS visible to the eavesdropper when it is used in 0-rtt. The client cannot change the ticket's _ciphertext_. Therefore the eavesdropper can correlate 0-rtt connections when tickets are reused. The obfuscated ticket age is irrelevant to that. Now, I understand that the obfuscated ticket age goes in the clear in 0-rtt connections, and that if the attacker could work out the unobfuscated time then the attacker could correlate not just the 0-rtt ticket-reusing connections with each other, but also some earliere ticket-establishing connection(s) observed at that time. I find the obfuscated ticket age business a bit silly, but maybe I'm missing something. The client should really send an [encrypted] authenticator that includes a timestamp, thus allowing the server to detect replays and so on -- just like Kerberos. Then this problem wouldn't happen. In any case, given that ticket-reusing 0-rtt connections can be correlated with each other, the ability to further correlate them with a ticket-issuing connection(s) established earlier doesn't seem to be that much more of a big deal. If it's at all possible to move this timestamp into an authenticator at this point, I think that's the best solution. Nico --=20 From nobody Tue May 2 11:34:01 2017 Return-Path: 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 34C7112E054 for ; Tue, 2 May 2017 11:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 NdU9dAbS2XbL for ; Tue, 2 May 2017 11:33:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F131412EC29 for ; Tue, 2 May 2017 11:31:11 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 495087A32F1 for ; Tue, 2 May 2017 18:31:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 2 May 2017 14:31:10 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:33:59 -0000 > On May 2, 2017, at 2:15 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > In that case, I only reason I see to stop using tickets multiple times = is to protect > the obfuscated age. It reads to me like its purpose would just be = defeated. Is it > really that hard for clients to use a 1-for-1 = use-a-ticket-get-a-ticket approach? Yes, it is difficult to do 1-for-1. In postfix there are parallel = client processes reading a shared session cache, and parallel writers updating that = cache, and without major changes to the code, when two writers update the cache back to = back only one ticket (really SSL_SESSION object) is saved. Under load, many clients = would not find a ticket at all. --=20 Viktor.= From nobody Tue May 2 11:43:27 2017 Return-Path: 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 53D7F129C16 for ; Tue, 2 May 2017 11:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RJG20MDq3dxP for ; Tue, 2 May 2017 11:43:25 -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 82480129C11 for ; Tue, 2 May 2017 11:40:00 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1E90E496C17; Tue, 2 May 2017 18:40:00 +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 08AB2496C0A; Tue, 2 May 2017 18:40:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493750400; bh=Drpr88OpC+L16UId3MWUyk/DAmsc1UZi7mkOZH9BNj8=; l=1454; h=To:References:Cc:From:Date:In-Reply-To:From; b=So4a7Ztj4u+Frwo+UcuBjlU0fV+3lT+cb3zjnDyobc+NpCGF0iv8gGN91YMKQ+HXD glZsS5LlQiC044+fEtrRyh/w/uXsATlUyuV4I4Jd9IMCpo2zEnG92hu9mhatNhWiF4 h+C9ZueSyDPSuVRBzXqpIMU+VuLv+HNwMyq98sqQ= 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 AE5171E142; Tue, 2 May 2017 18:39:59 +0000 (GMT) To: Nico Williams References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> Cc: TLS WG From: Benjamin Kaduk Message-ID: Date: Tue, 2 May 2017 13:39:59 -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: <20170502182529.GG10188@localhost> Content-Type: multipart/alternative; boundary="------------B4A2ECD67678089F50C5514E" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:43:26 -0000 This is a multi-part message in MIME format. --------------B4A2ECD67678089F50C5514E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/02/2017 01:25 PM, Nico Williams wrote: > If it's at all possible to move this timestamp into an authenticator at > this point, I think that's the best solution. I thought TLS clients were supposed to have even worse clocks (in terms of absolute time) than Kerberos clients. The current ticket_age scheme only requires the client's clock *rate* to be reasonable, not its absolute time. -Ben --------------B4A2ECD67678089F50C5514E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 05/02/2017 01:25 PM, Nico Williams wrote:
If it's at all possible to move this timestamp into an authenticator at
this point, I think that's the best solution.

I thought TLS clients were supposed to have even worse clocks (in terms of absolute time) than Kerberos clients.  The current ticket_age scheme only requires the client's clock *rate* to be reasonable, not its absolute time.

-Ben
--------------B4A2ECD67678089F50C5514E-- From nobody Tue May 2 11:45:37 2017 Return-Path: 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 3832C129C4B for ; Tue, 2 May 2017 11:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 lbT81kQiRt0P for ; Tue, 2 May 2017 11:45:34 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D10129ABE for ; Tue, 2 May 2017 11:42:03 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l18so74415566ywh.3 for ; Tue, 02 May 2017 11:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5B7g050j5XvDVOlUu5iPLkFHr+9TkY29H0PxuPt8A14=; b=XuIDmJCM5SAVmU/1TV4D/Wpe4z4mn/h2mWDlERAyO/vIZl1YB7tjwNmRP/lTaxhGlv agjmmekx1uEE4w1lf4okWvQAzHA0xY9L+/EJ0r1/3WOcAn+rC1TU0s24Brw2Z4uHQwI1 VknqklEHnVE7hyhlhPkUmTK5OVpTb3163SkhRRH3dw6fMDx6HbIoi2iTbrs3CWEFYEof TNdb0anh6ZY8ZTX7ecfqYehf1mlZuh7pDQUc6P77/gILYe0VWKZjYkE8t/r6PJWlKdNH /rwG1YhmyxqAERS9lhdQN+FYvVKkqGVKT6dsnwJnCFpYkLuOU/Iottaj5WVktrD5qCZx fAXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5B7g050j5XvDVOlUu5iPLkFHr+9TkY29H0PxuPt8A14=; b=UPrMsv3bHcG6j+QNT7IvjSGdqNFooncoi2QBS3JNba1ReVK4R+D8v79Wj6LuzWIe6L b1phdPSUUAeBdU4wE/8vyJKCxBHE3IWFRpcpnJgHtg27i550AhKENUA8YX2AFyLq9W0w ZT+jrWbckRoi6dybz+GjQlFohH2WyzDBYUiibZD7kxETldnTSGRRq6xd7SkfZZcwp/NV IcvTKdhv4plELwI8bE0p4TtwMT2Bb/X3AnVNz73+v9+0hkJ616n6OVycco1rZZlzqEuX CKlaBlRgkUfuY2F4Oq37sBiyH2GifKCo4CMBnjfJxUscR5xqs2dVG+6patFhvBp/b/LU phVQ== X-Gm-Message-State: AN3rC/5MVKWVer4TjrNkZt4FYbclyTb8B+zZKCOhqfBRrEM6Tn2BUqgX NO3T5Yc3ewGJ3xBk4wqrWzdQBTdxSg== X-Received: by 10.129.105.198 with SMTP id e189mr25814712ywc.296.1493750522555; Tue, 02 May 2017 11:42:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 11:42:01 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 11:42:01 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a1147125647c7f1054e8ee51a Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:45:36 -0000 --001a1147125647c7f1054e8ee51a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2017 at 11:31 AM, Viktor Dukhovni wrote: > > > On May 2, 2017, at 2:15 PM, Colm MacC=C3=A1rthaigh = wrote: > > > > In that case, I only reason I see to stop using tickets multiple times > is to protect > > the obfuscated age. It reads to me like its purpose would just be > defeated. Is it > > really that hard for clients to use a 1-for-1 use-a-ticket-get-a-ticket > approach? > > Yes, it is difficult to do 1-for-1. In postfix there are parallel client > processes > reading a shared session cache, and parallel writers updating that cache, > and without > major changes to the code, when two writers update the cache back to back > only one > ticket (really SSL_SESSION object) is saved. Under load, many clients > would not > find a ticket at all. > That makes sense to me. Thanks for the detail. --=20 Colm --001a1147125647c7f1054e8ee51a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 11:31 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:

> On May 2, 2017, at 2:15 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
>
> In that case, I only reason I see to stop using tickets multiple times= is to protect
> the obfuscated age. It reads to me like its purpose would just be defe= ated. Is it
> really that hard for clients to use a 1-for-1 use-a-ticket-get-a-ticke= t approach?

Yes, it is difficult to do 1-for-1.=C2=A0 In postfix there are paral= lel client processes
reading a shared session cache, and parallel writers updating that cache, a= nd without
major changes to the code, when two writers update the cache back to back o= nly one
ticket (really SSL_SESSION object) is saved.=C2=A0 Under load, many clients= would not
find a ticket at all.

That makes sense = to me. Thanks for the detail.

--
Colm
--001a1147125647c7f1054e8ee51a-- From nobody Tue May 2 11:48:41 2017 Return-Path: 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 05316129A8F for ; Tue, 2 May 2017 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 dwY0h-9Aca7p for ; Tue, 2 May 2017 11:48:38 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F111289C3 for ; Tue, 2 May 2017 11:45:28 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id p143so37190870yba.2 for ; Tue, 02 May 2017 11:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8HO35HcV0Ory9qV3whwYTwGstGgOF/5mKIIl+b0AFzA=; b=StnZRgrIq8jzDO3ohvztW2OaSMUCAITCSAKHKEUrYbOZ1ihZq3KbTi45l6/iPbzfg9 SHtzZyinW81vEipD0FtgIBefVunUg43DyTl/BBMzbLzUXVvZj/sqnawIKcIajUGL/Knk 3caxAHZjsNcm1SIklQCAs40XwpwPDMBqayzd1ibLsVQqJhgtAz7tYTVtJEDTewPEFIvQ 8ZESEHvafcZBKYbFDhH+DsKigfQo4RDCGMv5trGw5skTCcyvQvnbdv5jlHp08BNZOGl5 m2x0P+oa2p+QrL9G1zajFhlcYPD44lbaS0qoTko1bnsqQZwuTIo/gcgjV1Z0vvn9p07T RX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8HO35HcV0Ory9qV3whwYTwGstGgOF/5mKIIl+b0AFzA=; b=FOaxvKMQz6MlXLwyT6rOr8lSzJJPaQyJElhDFlTUviPOdebjdIE7PViQEX0Ajb7v+G aMTwjJ3gNLUEnJhCa5n81IRZj04pdeHygepihv5GA5g6NQy5KCAfJv/+9vFMgKIcPzuq TqsNTEwJhy9nIpZWOkIuBXSjzWaizmqLBdUwN8sFDi1C5DW/Tt6gZlTs6Hmv2Ld2YApv XLVDjuqR+AZB9GQhxQlZRgKEtecmEEOOz1ca4aKkcvQu3pmfLAeiBoZyYxn5LIRxlzGb 8i7EivmLWT3HPSxbpePtSDaRClsI8x1iZWQnHSYUY/z8VICSPWqo51hI5z6EFTCAs4Ro HaYQ== X-Gm-Message-State: AN3rC/75A5kYmlLy08qU0CJOnoIM/gTFEUKuVjbPPHn4MSr+739vus9t rt2mtjkmrDXAwGRf5cbjJo1G/0Qnvg== X-Received: by 10.37.15.213 with SMTP id 204mr190374ybp.127.1493750727632; Tue, 02 May 2017 11:45:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 11:45:27 -0700 (PDT) In-Reply-To: References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 11:45:27 -0700 Message-ID: To: Benjamin Kaduk Cc: Nico Williams , TLS WG Content-Type: multipart/alternative; boundary=001a113f5ae68116a3054e8ef19a Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:48:40 -0000 --001a113f5ae68116a3054e8ef19a Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 11:39 AM, Benjamin Kaduk wrote: > I thought TLS clients were supposed to have even worse clocks (in terms of > absolute time) than Kerberos clients. The current ticket_age scheme only > requires the client's clock *rate* to be reasonable, not its absolute time. > Here I have some data. Over 7 days of examining requests from low power devices, 1 in 100 devices had a clock drift of at least 2 seconds. One in 1,000 had a drift of at least 43 seconds, and the worst offender had drifted by years. -- Colm --001a113f5ae68116a3054e8ef19a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 11:39 AM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
=20 =20 =20
I thought TLS clients were supp= osed to have even worse clocks (in terms of absolute time) than Kerberos clients.=C2=A0 The current ticket_age scheme only requires the client's clock *rate* to be reasonable, not its absolute time.

Here I have some data. Over 7 days of examining requests from low pow= er devices, 1 in 100 devices had a clock drift of at least 2 seconds. One i= n 1,000 had a drift of at least 43 seconds, and the worst offender had drif= ted by years.=C2=A0


--
Colm
--001a113f5ae68116a3054e8ef19a-- From nobody Tue May 2 11:49:18 2017 Return-Path: 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 4961212EAD9 for ; Tue, 2 May 2017 11:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 gj2pCcGsZ_EE for ; Tue, 2 May 2017 11:49:15 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF4129A90 for ; Tue, 2 May 2017 11:46:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B89BD21213; Tue, 2 May 2017 21:46:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id iTlUm2NfXN7M; Tue, 2 May 2017 21:46:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7BBE1C4; Tue, 2 May 2017 21:46:04 +0300 (EEST) Date: Tue, 2 May 2017 21:46:03 +0300 From: Ilari Liusvaara To: Nico Williams Cc: TLS WG Message-ID: <20170502184603.GA30300@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170502173905.GC10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170502173905.GC10188@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:49:17 -0000 On Tue, May 02, 2017 at 12:39:06PM -0500, Nico Williams wrote: > On Tue, May 02, 2017 at 01:33:37PM -0400, Viktor Dukhovni wrote: > > > > There's also an observation there that it should really be that > > > clients "MUST" use tickets only once. Any re-use likely discloses > > > the obfuscated ticket age, which is intended to be secret. Right now > > > it's a "SHOULD". > > Why should ticket age disclosure be a problem? How does ticket one-time > use not do the same? Ticket re-use is the reason why the masking uses add modulo 2^32 instead of xor (which is more common). Using add for masking does not leak identity of the parent session (xor would leak it) even on re-use. And ticket-reuse leaks the fact that the child sessions are related anyway, nothing that can be done about that. -Ilari From nobody Tue May 2 11:54:53 2017 Return-Path: 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 B6CB412E053 for ; Tue, 2 May 2017 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 8EYtyJ1bfTyj for ; Tue, 2 May 2017 11:54:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA3812947A for ; Tue, 2 May 2017 11:51:07 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0D4BD7A32F1 for ; Tue, 2 May 2017 18:51:07 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 2 May 2017 14:51:06 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <39C55E05-183F-415D-8E99-1798DD2303D8@dukhovni.org> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:54:52 -0000 > On May 2, 2017, at 2:39 PM, Benjamin Kaduk wrote: >=20 > I thought TLS clients were supposed to have even worse clocks (in = terms of absolute time) than Kerberos clients. The current ticket_age = scheme only requires the client's clock *rate* to be reasonable, not its = absolute time. Sure, and yet it might still have been better to transport the = "obfuscated ticket age" as an "encrypted ticket age", while keeping the elements of the design = that expect only a reasonable clock rate from the client. Of course making such a change = is likely prohibitive at this time... If the ticket is never re-used the "obfuscation" is perhaps sufficient, = and if it is re-used both obfuscation and encryption are defeated. So obfuscation = is perhaps acceptable. --=20 Viktor. From nobody Tue May 2 12:20:13 2017 Return-Path: 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 0509312EBAE for ; Tue, 2 May 2017 12:20:12 -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 U34z-VX7yJjR for ; Tue, 2 May 2017 12:20:09 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5512EA7A for ; Tue, 2 May 2017 12:17:18 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DDF8D4334AC; Tue, 2 May 2017 19:17:17 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C7A98433403; Tue, 2 May 2017 19:17:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493752637; bh=VWYxeHfPhn5xIeGBEC+2/xfhVwteMWcXxYYIh2r9r7I=; l=8573; h=To:References:Cc:From:Date:In-Reply-To:From; b=JbwPEjD7Qtze6lGcw/MMVMuo1TXO9B8Mu81tlLPab7hnLF6+feaUlLzpGstyYWuMP +4cmwkbrqSyij76kip9CO0CGG1j62jOVqJ5Rppk3AnoV8VdIm0znloslXG7Z199WmD rtureKmGGIlj06553S6IZF+i2Forq1cwSZa19qZU= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7F20E1FCF3; Tue, 2 May 2017 19:17:17 +0000 (GMT) To: Nico Williams , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> Cc: TLS WG From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> Date: Tue, 2 May 2017 14:17:17 -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: <20170502182529.GG10188@localhost> Content-Type: multipart/alternative; boundary="------------DE480319999F43CAB9484CEA" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:20:12 -0000 This is a multi-part message in MIME format. --------------DE480319999F43CAB9484CEA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit [replying to the part of your message I did not already cherry-pick and reply to...] On 05/02/2017 01:25 PM, Nico Williams wrote: > On Tue, May 02, 2017 at 11:17:42AM -0700, Colm MacCárthaigh wrote: >> On Tue, May 2, 2017 at 11:00 AM, Nico Williams >> wrote: >>> I would think that the ticket itself is enough for that when using >>> 0-rtt. I.e., if you don't want connection correlation to be possible, >>> you can't use 0-rtt. >> I don't think so. If the ticket is encrypted when it issued, I don't follow >> how it could be used to correlate the original connection with the 0-RTT >> connection. > The ticket's _ciphertext_ is not visible to the eavesdropper when it is > issued, but it IS visible to the eavesdropper when it is used in 0-rtt. > The client cannot change the ticket's _ciphertext_. Therefore the > eavesdropper can correlate 0-rtt connections when tickets are reused. > The obfuscated ticket age is irrelevant to that. > > Now, I understand that the obfuscated ticket age goes in the clear in > 0-rtt connections, and that if the attacker could work out the > unobfuscated time then the attacker could correlate not just the 0-rtt > ticket-reusing connections with each other, but also some earliere > ticket-establishing connection(s) observed at that time. > > I find the obfuscated ticket age business a bit silly, but maybe I'm > missing something. The client should really send an [encrypted] > authenticator that includes a timestamp, thus allowing the server to > detect replays and so on -- just like Kerberos. Then this problem > wouldn't happen. It's just to provide a little extra benefit on top of TLS 1.2 of unlinkability in some situations. In TLS 1.2, the session ticket was sent unencrypted, so the ticket ciphertext is always available to the attacker for correlation of ticket use to the original connection (and thus to other resumptions from that original connection). With TLS 1.3, the first time the observer sees the ticket ciphertext is when the client uses it. If the client only uses the ticket once, the naive conclusion is that the resumption is not linkable to anything else -- the original connection or other resumptions from the same original connection. But, because we have this ticket age anti-replay mechanism, the ticket age could be used to link resumptions from the original session together, as described shortly. This only matters when the client has multiple tickets to use that were granted at the same time/session, since if the client is reusing tickets then the ticket ciphertext links the reuse, as you already noted. So, if the ticket_age was in the clear, then the attacker could subtract that to find when the ticket was issued, and correlate the multiple tickets that were issued together. Obfuscating the ticket age prevents that correlation. That correlation was unavoidable with TLS 1.2 tickets; if you're happy with the 1.2 behavior, you don't need to care about reusing tickets or how obfuscated your ticket age is. (This is Viktor's postfix case, as I understand it.) > In any case, given that ticket-reusing 0-rtt connections can be > correlated with each other, the ability to further correlate them with a > ticket-issuing connection(s) established earlier doesn't seem to be that > much more of a big deal. Agreed. This whole anti-linkability thing is really in a very narrow use case, and only when each ticket is used at most once. (It's also a very minor benefit, in my mind, compared to the other security properties in scope.) -Ben --------------DE480319999F43CAB9484CEA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit [replying to the part of your message I did not already cherry-pick and reply to...]
On 05/02/2017 01:25 PM, Nico Williams wrote:
On Tue, May 02, 2017 at 11:17:42AM -0700, Colm MacCárthaigh wrote:

On Tue, May 2, 2017 at 11:00 AM, Nico Williams <nico@cryptonector.com>
wrote:

I would think that the ticket itself is enough for that when using
0-rtt.  I.e., if you don't want connection correlation to be possible,
you can't use 0-rtt.

I don't think so. If the ticket is encrypted when it issued, I don't follow
how it could be used to correlate the original connection with the 0-RTT
connection.

The ticket's _ciphertext_ is not visible to the eavesdropper when it is
issued, but it IS visible to the eavesdropper when it is used in 0-rtt.
The client cannot change the ticket's _ciphertext_.  Therefore the
eavesdropper can correlate 0-rtt connections when tickets are reused.
The obfuscated ticket age is irrelevant to that.

Now, I understand that the obfuscated ticket age goes in the clear in
0-rtt connections, and that if the attacker could work out the
unobfuscated time then the attacker could correlate not just the 0-rtt
ticket-reusing connections with each other, but also some earliere
ticket-establishing connection(s) observed at that time.

I find the obfuscated ticket age business a bit silly, but maybe I'm
missing something.  The client should really send an [encrypted]
authenticator that includes a timestamp, thus allowing the server to
detect replays and so on -- just like Kerberos.  Then this problem
wouldn't happen.

It's just to provide a little extra benefit on top of TLS 1.2 of unlinkability in some situations.  In TLS 1.2, the session ticket was sent unencrypted, so the ticket ciphertext is always available to the attacker for correlation of ticket use to the original connection  (and thus to other resumptions from that original connection).  With TLS 1.3, the first time the observer sees the ticket ciphertext is when the client uses it.  If the client only uses the ticket once, the naive conclusion is that the resumption is not linkable to anything else -- the original connection or other resumptions from the same original connection.  But, because we have this ticket age anti-replay mechanism, the ticket age could be used to link resumptions from the original session together, as described shortly.  This only matters when the client has multiple tickets to use that were granted at the same time/session, since if the client is reusing tickets then the ticket ciphertext links the reuse, as you already noted.  So, if the ticket_age was in the clear, then the attacker could subtract that to find when the ticket was issued, and correlate the multiple tickets that were issued together.  Obfuscating the ticket age prevents that correlation.

That correlation was unavoidable with TLS 1.2 tickets; if you're happy with the 1.2 behavior, you don't need to care about reusing tickets or how obfuscated your ticket age is.  (This is Viktor's postfix case, as I understand it.)

In any case, given that ticket-reusing 0-rtt connections can be
correlated with each other, the ability to further correlate them with a
ticket-issuing connection(s) established earlier doesn't seem to be that
much more of a big deal.

Agreed.  This whole anti-linkability thing is really in a very narrow use case, and only when each ticket is used at most once.  (It's also a very minor benefit, in my mind, compared to the other security properties in scope.)

-Ben

--------------DE480319999F43CAB9484CEA-- From nobody Tue May 2 12:23:34 2017 Return-Path: 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 3743B12EB05 for ; Tue, 2 May 2017 12:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 4YFr5WubT7rY for ; Tue, 2 May 2017 12:23:32 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBC612E03F for ; Tue, 2 May 2017 12:20:07 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 5021DC086D0C; Tue, 2 May 2017 12:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2u106uw+RXW3EP KKnZ0cVHtHTZA=; b=u4MvvfFQhh5Wcyo55mNZcDFOvp001062Wq3lOmMjW4RN1u mKQBQ7Q81f3D1V6sbPhYYOMm0y7IDRdC+fLl8ENrZdFtB5HK/4L8I5iTQ/VQFuX7 x+BAGWt/Y2UsMRNPIQ9t09/MWnXFJEJDm6+1cF5aKOvczKXzqnadUvrCywqH0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id ACB58C0028A3; Tue, 2 May 2017 12:20:06 -0700 (PDT) Date: Tue, 2 May 2017 14:20:04 -0500 From: Nico Williams To: Benjamin Kaduk Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , TLS WG Message-ID: <20170502192003.GH10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:23:33 -0000 On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote: > [ stuff about 1.2 elided ] OK, sure, but why not avoid the problem in the first place in 1.3 by sending an encrypted timestamp authenticator (sound familiar?). Nico -- From nobody Tue May 2 12:31:32 2017 Return-Path: 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 B33B0126C3D for ; Tue, 2 May 2017 12:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gjLSww6l6eNs for ; Tue, 2 May 2017 12:31:29 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id BC11612946D for ; Tue, 2 May 2017 12:28:38 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 425794334BC; Tue, 2 May 2017 19:28:38 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2C210433407; Tue, 2 May 2017 19:28:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493753318; bh=UpZ6JlMgIVNRWUFB5zbiDZJAihDGBgxXD4cXNtah5kg=; l=2225; h=To:References:Cc:From:Date:In-Reply-To:From; b=N2XTsAMWmm6em4TIXS7IlHxKTOt2p3w0TRPctLWYrv+fe6B7YTNadWcI4Xo9/Xa9H 9eMpEjP8C4J6Yz7iwv+NORz4lVUlTro2+nY13spyYiZVaZY7MOJjffrXGierbmpv5i q4rRpvn3/DyaTzWvKzWoXulPkoccl560BEkMWEnY= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id DB6541FD06; Tue, 2 May 2017 19:28:37 +0000 (GMT) To: Nico Williams References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> Cc: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , TLS WG From: Benjamin Kaduk Message-ID: Date: Tue, 2 May 2017 14:28:37 -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: <20170502192003.GH10188@localhost> Content-Type: multipart/alternative; boundary="------------BA97AD01801BE5FBAEFF73E2" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:31:31 -0000 This is a multi-part message in MIME format. --------------BA97AD01801BE5FBAEFF73E2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/02/2017 02:20 PM, Nico Williams wrote: > On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote: >> [ stuff about 1.2 elided ] > OK, sure, but why not avoid the problem in the first place in 1.3 by > sending an encrypted timestamp authenticator (sound familiar?). > If you mean an actual timestamp, see my previous reply about clock accuracy. If you mean an encrypted relative time, well, that's what it is. The encryption is incredibly ad hoc, and requires that the key only be used once, but the whole thing started by thinking of it as a super-janky encryption scheme. See https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby. -Ben --------------BA97AD01801BE5FBAEFF73E2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 05/02/2017 02:20 PM, Nico Williams wrote:
On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote:

[ stuff about 1.2 elided ]

OK, sure, but why not avoid the problem in the first place in 1.3 by
sending an encrypted timestamp authenticator (sound familiar?).

If you mean an actual timestamp, see my previous reply about clock accuracy.

If you mean an encrypted relative time, well, that's what it is.  The encryption is incredibly ad hoc, and requires that the key only be used once, but the whole thing started by thinking of it as a super-janky encryption scheme.  See https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby.

-Ben
--------------BA97AD01801BE5FBAEFF73E2-- From nobody Tue May 2 12:34:33 2017 Return-Path: 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 8C4C1129B81 for ; Tue, 2 May 2017 12:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 hLnTgOZ7_W09 for ; Tue, 2 May 2017 12:34:31 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56777129B7E for ; Tue, 2 May 2017 12:31:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 0DB58C0028A6; Tue, 2 May 2017 12:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yYhpPECGwiiC8I CQH/zsaxXKuZU=; b=HfFTtY0/ylvATdqV+G95A8cXtvJhEVi/+NYvkW0G1q3z1Z HEfOxfMCfUn5Zm3yIioG66PqOQnEBBnmdjKSl2K73f8SKrcXAgWfG6finJbz26pW z1zbCrrpvkgDrQ6mGwUCSddz+cBne5pNbKWwQDjtjk5q2XBIsvtethYyYwXWA= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id A3765C0028A3; Tue, 2 May 2017 12:31:48 -0700 (PDT) Date: Tue, 2 May 2017 14:31:46 -0500 From: Nico Williams To: Benjamin Kaduk Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , TLS WG Message-ID: <20170502193145.GI10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:34:33 -0000 On Tue, May 02, 2017 at 02:28:37PM -0500, Benjamin Kaduk wrote: > On 05/02/2017 02:20 PM, Nico Williams wrote: > > On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote: > >> [ stuff about 1.2 elided ] > > OK, sure, but why not avoid the problem in the first place in 1.3 by > > sending an encrypted timestamp authenticator (sound familiar?). > > If you mean an actual timestamp, see my previous reply about clock accuracy. Kerberos deas with that. > If you mean an encrypted relative time, well, that's what it is. The > encryption is incredibly ad hoc, and requires that the key only be used > once, but the whole thing started by thinking of it as a super-janky > encryption scheme. See > https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby. Yeah, it's an XOR with a one-time pad that... gets reused if you reuse the ticket. OF COURSE that fails. Everyone knows not to reuse one-time pads. So, in 1.3, at least with 0-rtt, can we replaced this with a proper encryption? Nico -- From nobody Tue May 2 12:44:39 2017 Return-Path: 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 02037128C81 for ; Tue, 2 May 2017 12:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 QsgoxJden-FG for ; Tue, 2 May 2017 12:44:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 717FC12EB0B for ; Tue, 2 May 2017 12:41:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B3A06200080; Tue, 2 May 2017 19:41:35 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 793B8200003; Tue, 2 May 2017 19:41:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493754095; bh=rUSnq6jSSl8xS2kWv4wH6RWFDC22PW4/DfuN6D1j3Aw=; l=3616; h=To:References:Cc:From:Date:In-Reply-To:From; b=mBqoZV9lJV5Gto6zq3DeYpjI5kIgXSJ3Uu+7WyDQUU04GnYU/Q0Ps2gUSEYts+IGz SA0PBylLcSLenKXQrluz1qlqRix5wF+je985SAup1N1MlqfKmoQgXj1Jv6I3oN75yR lyea/pkCiW3QqlfrFyk26VT/CMLHcpCy8A3hrMtw= 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 032891E08A; Tue, 2 May 2017 19:41:34 +0000 (GMT) To: Nico Williams References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> Cc: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , TLS WG From: Benjamin Kaduk Message-ID: <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> Date: Tue, 2 May 2017 14:41:34 -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: <20170502193145.GI10188@localhost> Content-Type: multipart/alternative; boundary="------------7B0F3A1EECB03434EC9110E4" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:44:37 -0000 This is a multi-part message in MIME format. --------------7B0F3A1EECB03434EC9110E4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/02/2017 02:31 PM, Nico Williams wrote: > On Tue, May 02, 2017 at 02:28:37PM -0500, Benjamin Kaduk wrote: >> On 05/02/2017 02:20 PM, Nico Williams wrote: >>> On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote: >>>> [ stuff about 1.2 elided ] >>> OK, sure, but why not avoid the problem in the first place in 1.3 by >>> sending an encrypted timestamp authenticator (sound familiar?). >> If you mean an actual timestamp, see my previous reply about clock accuracy. > Kerberos deas with that. > >> If you mean an encrypted relative time, well, that's what it is. The >> encryption is incredibly ad hoc, and requires that the key only be used >> once, but the whole thing started by thinking of it as a super-janky >> encryption scheme. See >> https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby. > Yeah, it's an XOR with a one-time pad that... gets reused if you reuse > the ticket. OF COURSE that fails. Everyone knows not to reuse one-time > pads. > > So, in 1.3, at least with 0-rtt, can we replaced this with a proper > encryption? > If you reuse the ticket, the only concrete stated benefit from this encryption is lost already. What benefit would be gained from using better encryption for ticket_age_add? -Ben --------------7B0F3A1EECB03434EC9110E4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 05/02/2017 02:31 PM, Nico Williams wrote:
On Tue, May 02, 2017 at 02:28:37PM -0500, Benjamin Kaduk wrote:

On 05/02/2017 02:20 PM, Nico Williams wrote:

On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote:

[ stuff about 1.2 elided ]

OK, sure, but why not avoid the problem in the first place in 1.3 by
sending an encrypted timestamp authenticator (sound familiar?).

If you mean an actual timestamp, see my previous reply about clock accuracy.

Kerberos deas with that.


If you mean an encrypted relative time, well, that's what it is.  The
encryption is incredibly ad hoc, and requires that the key only be used
once, but the whole thing started by thinking of it as a super-janky
encryption scheme.  See
https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby.

Yeah, it's an XOR with a one-time pad that... gets reused if you reuse
the ticket.  OF COURSE that fails.  Everyone knows not to reuse one-time
pads.

So, in 1.3, at least with 0-rtt, can we replaced this with a proper
encryption?

If you reuse the ticket, the only concrete stated benefit from this encryption is lost already.  What benefit would be gained from using better encryption for ticket_age_add?

-Ben
--------------7B0F3A1EECB03434EC9110E4-- From nobody Tue May 2 13:00:47 2017 Return-Path: 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 BD33C1294DF for ; Tue, 2 May 2017 13:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 B4GiEb8zth7w for ; Tue, 2 May 2017 13:00:43 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77B8129B0D for ; Tue, 2 May 2017 12:57:57 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 5EBC8C0028A3; Tue, 2 May 2017 12:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wum/bVO9YNhCzl ZnxPhJDEBmjz4=; b=DT1JkitNyimfoGSKkA0PoG87vFA7UfB3DQkDw+EK4GsXIy m+ejxk5VybpS/mDcnLUjxvrgBHpWXJrH51iqDts/TFQkgJCojfCAkHQH9wcY84rI yi4fDJYerPXmq+85JsJwiUvyc+QYRDTtt9IVpsdZC9vVw1m41iTMqLNXBnET0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id DF35DC0028A6; Tue, 2 May 2017 12:57:56 -0700 (PDT) Date: Tue, 2 May 2017 14:57:54 -0500 From: Nico Williams To: Benjamin Kaduk Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , TLS WG Message-ID: <20170502195753.GJ10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 20:00:45 -0000 On Tue, May 02, 2017 at 02:41:34PM -0500, Benjamin Kaduk wrote: > On 05/02/2017 02:31 PM, Nico Williams wrote: > > So, in 1.3, at least with 0-rtt, can we replaced this with a proper > > encryption? > > If you reuse the ticket, the only concrete stated benefit from this > encryption is lost already. What benefit would be gained from using > better encryption for ticket_age_add? Well, I did say that to me there's not much difference to _me_ between "connections reusing the same ticket can be correlated to each other" and "connections reusing the same ticket can be correlated to each other and the connection whence the ticket". Others might disagree, and if that is reasonable enough then the best thing to do is to encrypt this darned thing. On principle, too, I think one might prefer to encrypt properly just because we really shouldn't be doing this sort of thing. Among other things the lack of integrity protection for this field makes me think that we need to analyze not only passive attacks against it, but active attacks too. It'd be so much easier if we didn't have to. Nico -- From nobody Tue May 2 13:55:02 2017 Return-Path: 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 8B7F612EAB0 for ; Tue, 2 May 2017 13:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 ApbYBDZtTOTd for ; Tue, 2 May 2017 13:54:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 38CBF129418 for ; Tue, 2 May 2017 13:52:25 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6D9D6F993; Tue, 2 May 2017 16:52:25 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 13A4020662; Tue, 2 May 2017 16:52:21 -0400 (EDT) From: Daniel Kahn Gillmor To: Nico Williams , Benjamin Kaduk Cc: TLS WG In-Reply-To: <20170502195753.GJ10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> Date: Tue, 02 May 2017 16:52:17 -0400 Message-ID: <87a86vrnge.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 20:55:01 -0000 --=-=-= Content-Type: text/plain On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote: > Well, I did say that to me there's not much difference to _me_ between > "connections reusing the same ticket can be correlated to each other" > and "connections reusing the same ticket can be correlated to each other > and the connection whence the ticket". Others might disagree, I disagree, Nico! :) The difference here is between saying: * clients that want the latency benefit of session resumption can be careful to avoid ticket reuse and their connections will be unlinkable to a network observer who records session IDs. versus: * clients that want the latency benefit of session resumption must accept that a network observer can trivially know that each connection is linkable to the previous one. put another way: the difference between 0 required backlinks and 1 required backlink on each individual session resumption is the difference (for a cautious yet session-resuming client) between 0 connections linked by a network observer and all connections linked by a network observer. TLS session linkability is relevant: * When a client is behind a NAT and wants their connections to be mixed with (indistinguishable from) other clients behind the same NAT, to the perspective of a network observer outside the NAT. * When a client moves network locations and doesn't want their network position to be trackable by a network observer. * When a client uses a VPN as an encrypted Internet proxy (or uses Tor or some other similar IP-anonymizing service), and does not want a network observer outside the VPN from being able to distinguish their traffic from the traffic of other users of the anonymity network. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkI8YEACgkQFJitxsGS Mjc+MhAAhntkZtmPKVl2PMUOzNEWhD2su2kpubZQsho2P9zCkPY6TLitt1Vp5GjE F5OckEd/u1VdAWywvRa+2oz4vIp4MIHIUOIY5gNXnTG/eWCNNMNIalXvTkqJ0aLS mDrjC37VduIon+0KNlFGYTUaVPh6eROu8I1mTsf1CMKDSeTlCK65IhgKcmK4+i3O CZDoWyhYUK6oaqjmvMoHVnkzoyTIQAoqk5k3J7wnNGiEeXgUS0p4B7v4Ubk9jfMj 0jpbj8kboVEhsmU8dfwkjADO027w1wfto7c1YzAOch+LJ6k9ctDPtUQ0DoS3GH8i O7itpiOh1czf0p4IIKJKTLxWD6Py9mXRbjU0rLgK+uSNtxzpL5uoU1esrLbLeyh1 7k0s22AbIAT4GNoCYGJn7+lWxZjfj8+zpEh58dPC9JJtAX8Urfg2vx6L+B4OkC+j 1wryhbjpAwS5t63PH3K7lKQY1IY54jMY8hf1sh1xoXTTM1cfJwdAlyUOEVX2L1lx SaZLPqVA6xlWvQHPdbRPpfr49kPD9Fxh1yxBQJMQ8ZZMh9yyV0jRnNvxzLD1IIN9 Jipg+TXms8Qm1jbAK6qyylj/O26g0E78zGaZZwJY1i14F1pAJVptpRtCfxCVSLgD BnY9wQX1BuaTXWvZymrVRQzisao2plkoD5Uy1uUPX8wO2/oOjO8= =9bPQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 2 14:06:36 2017 Return-Path: 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 177BF129AA4 for ; Tue, 2 May 2017 14:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 s6lOq7EJyEoR for ; Tue, 2 May 2017 14:06:31 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669F6129A90 for ; Tue, 2 May 2017 14:04:09 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id j17so11553364ybj.0 for ; Tue, 02 May 2017 14:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YZlqTaVWnjQfvLgf+GfANRGqrDIR7IVmOH5oLWPBR0o=; b=U+8md8L8hDJUZ6vlz44fcPhZUtbSz+IxiXoie+KYBpKYWA5VFdGDkLTy37+Y5AXJNp iNDfbj71Fsu60qcNWVvKogQw0zPKBkDCcNLnLCblMvw/sh1xdNL3Ja9Dhybe0dODQcN8 CJTk00o4dKvl6gAtEVi0bi0qTJXqQVcvNi+b/tl9LUNYX/BOMvFkRCaC6JgTwH+NZTfD 5IREpWbA+vkufXOBc3PLzrhRIoLr2kYkWdLazWsmTGtP2TJ0Oa33k3SxK4T2qSG5KMRv yNpjXErEn7uy0Z6kWEsF0GEDHrwdeNAbqyLouWzeCzJoCMF0XtHdjSpwgWEIEK4g9hEe vDJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YZlqTaVWnjQfvLgf+GfANRGqrDIR7IVmOH5oLWPBR0o=; b=Uo1zQFRi7Q/TovrSPpTCz3GNj2izx32ft2w8P1NAbKJbRqtuGEkzbvJbFQLUqz45Uy QmKBQ8mP9YxeNJ8Pn7qCX6Md2cv2+AQLOwl8WEJcr7PUsRYnmnajae6mc+HkHxssnULd u1E5x6BkSlYChpnSmmEOC1G06oV++1ULa00Mf2DnH7Q504y7gsmkCzJsb49Bxu6t2Pjt XXAnoPf57+wi4Vln7AqDpyPpNROQJOU9HNHjd8ULbqbMpiZzDSnzRdLc9tVyuP56OxtA LaJyLmAI30oxyYltoU/4xrJILtWlJrGBpRpJ9RvRdjiyMFXEdUCp5o2ioZwCtRnlZEEH x1Xw== X-Gm-Message-State: AN3rC/6JcU7Gsju1baYXHCVu5xvwl47eHx/NBGw9jqX1J9h9fR3GpwPW XqX4l6cO/Op2K0w7St7qf7Cgu6FtEA== X-Received: by 10.37.22.84 with SMTP id 81mr26184102ybw.33.1493759048535; Tue, 02 May 2017 14:04:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 14:04:07 -0700 (PDT) In-Reply-To: <87a86vrnge.fsf@fifthhorseman.net> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 14:04:07 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: Nico Williams , Benjamin Kaduk , TLS WG Content-Type: multipart/alternative; boundary=001a114160e077f36a054e90e196 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:06:34 -0000 --001a114160e077f36a054e90e196 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 1:52 PM, Daniel Kahn Gillmor wrote: > On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote: > > Well, I did say that to me there's not much difference to _me_ between > > "connections reusing the same ticket can be correlated to each other" > > and "connections reusing the same ticket can be correlated to each other > > and the connection whence the ticket". Others might disagree, > > I disagree, Nico! :) > > The difference here is between saying: > > * clients that want the latency benefit of session resumption can be > careful to avoid ticket reuse and their connections will be > unlinkable to a network observer who records session IDs. > versus: > > * clients that want the latency benefit of session resumption must > accept that a network observer can trivially know that each > connection is linkable to the previous one. > Agreed with your summary, but just a small note: clients might also want forward secrecy which is why I was suggesting that clients be able to request/enforce a STEK-less ticket. -- Colm --001a114160e077f36a054e90e196 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 1:52 PM, Daniel Kahn Gillmor &= lt;dkg@fifthhors= eman.net> wrote:
On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote:
> Well, I did say that to me there's not much difference to _me_ bet= ween
> "connections reusing the same ticket can be correlated to each ot= her"
> and "connections reusing the same ticket can be correlated to eac= h other
> and the connection whence the ticket".=C2=A0 Others might disagre= e,

I disagree, Nico! :)

The difference here is between saying:

=C2=A0* clients that want the latency benefit of session resumption can be<= br> =C2=A0 =C2=A0careful to avoid ticket reuse and their connections will be =C2=A0 =C2=A0unlinkable to a network observer who records session IDs.=C2= =A0

versus:

=C2=A0* clients that want the latency benefit of session resumption must =C2=A0 =C2=A0accept that a network observer can trivially know that each =C2=A0 =C2=A0connection is linkable to the previous one.

Agreed with your summary, but just a small note: clients = might also want forward secrecy which is why I was suggesting that clients = be able to request/enforce a STEK-less ticket.=C2=A0

--
Colm
--001a114160e077f36a054e90e196-- From nobody Tue May 2 14:34:35 2017 Return-Path: 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 D43F0129465 for ; Tue, 2 May 2017 14:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 fk4E59pOsyg5 for ; Tue, 2 May 2017 14:34:32 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98379129498 for ; Tue, 2 May 2017 14:31:10 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 45047C086D1F; Tue, 2 May 2017 14:30:41 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 710E8C086D23; Tue, 2 May 2017 14:29:57 -0700 (PDT) Date: Tue, 2 May 2017 16:29:54 -0500 From: Nico Williams To: Daniel Kahn Gillmor Cc: Benjamin Kaduk , TLS WG Message-ID: <20170502212953.GK10188@localhost> References: <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87a86vrnge.fsf@fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:34:34 -0000 On Tue, May 02, 2017 at 04:52:17PM -0400, Daniel Kahn Gillmor wrote: > On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote: > > Well, I did say that to me there's not much difference to _me_ betwee= n > > "connections reusing the same ticket can be correlated to each other" > > and "connections reusing the same ticket can be correlated to each ot= her > > and the connection whence the ticket". Others might disagree, >=20 > I disagree, Nico! :) Excellent. So now consider what followed the above. That is, that the correct thing to do is to properly encrypt a timestamp rather than XOR an OTP that then gets reused when the ticket gets reused. Why on Earth are still doing improper crypto in TLS?!=E2=80=BD In TLS 1.= 3 no less! Call it "janky", call it what you will. It's broken. Please fix. Nico --=20 From nobody Tue May 2 15:56:42 2017 Return-Path: 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 6064B12946D for ; Tue, 2 May 2017 15:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 egwFONP9a-fH for ; Tue, 2 May 2017 15:56:38 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E981294DF for ; Tue, 2 May 2017 15:54:29 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id p143so38688707yba.2 for ; Tue, 02 May 2017 15:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gd0RL04bIjb9198Ftl/CGnQ24hsJ+T95SASUlruEZJE=; b=a0s1EfYvgFrYYkMr8oEXCrnwgB2jXCfuA0QMchmzBiYNGPlABelVJ/2JAnyUBeF/34 nFCfffPbYInkjGGpwQe/eAQUPtnCRonm5dhakdnUXIeUsQ16M6+CbbrrQf6G6ZzH+0lj n3l1Egg+AEA2eWMZtSMojJiEyDjoCctPbwWPNA8HKU5FsVG0St2QoPbrCK2XmygMxvZq +968dVOLvNViJAd4g0G3oP9vfyeiCxMIFrlcb+KlKDl7Fes5FBzERLfiF87XIRRHh418 Xp5mdoQumcLyX7SIR20DW97TeCrIey0tmSxWuSGzVN6gOOZOPwOyOM5zednPSiTdpRai lQDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gd0RL04bIjb9198Ftl/CGnQ24hsJ+T95SASUlruEZJE=; b=GA4thTFMOToqmXLvCni5UnD2bJdk5hS6Q0jinbc7/Sk+WZBEoKa/UIB8Nqmiqc1QW+ S8a4rMP/hAG//uoHDJ5ZI5E59j4cnDiUTvBu4ALcqAZ2D01M7xWeKJq77zyjXNC/kBM8 CoLBEPa0Uf37w7bWSC1Yc4t9CrtCTQffFtiPRY95eUz1S5gwpRs03JK772GPIB1imLyG I9GPndjr6pTvHwWq5N5R3lhg2tAoe+CLmq/tsw3XHZ7r0rJvwIbbqqumdsuK0zcudTl7 jFAAePr9fyAfrtrIr28WBeJezCiJNaSaWStnHs53gxtfDms4b2mYl69rywEEncj5idul rL9w== X-Gm-Message-State: AN3rC/7sWBhheDhdVxQmLaKur08rBWOPp9V34EpMGvLfyzIP4r6l3QF/ Zq0/eqSP+g830VMI2OW2UY1fLRxE605W X-Received: by 10.37.220.15 with SMTP id y15mr25929280ybe.16.1493765669303; Tue, 02 May 2017 15:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 2 May 2017 15:53:48 -0700 (PDT) In-Reply-To: <20170502212953.GK10188@localhost> References: <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> <20170502212953.GK10188@localhost> From: Eric Rescorla Date: Tue, 2 May 2017 15:53:48 -0700 Message-ID: To: Nico Williams Cc: Daniel Kahn Gillmor , TLS WG Content-Type: multipart/alternative; boundary=94eb2c18f09218e41c054e926ca1 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 22:56:40 -0000 --94eb2c18f09218e41c054e926ca1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2017 at 2:29 PM, Nico Williams wrote= : > On Tue, May 02, 2017 at 04:52:17PM -0400, Daniel Kahn Gillmor wrote: > > On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote: > > > Well, I did say that to me there's not much difference to _me_ betwee= n > > > "connections reusing the same ticket can be correlated to each other" > > > and "connections reusing the same ticket can be correlated to each > other > > > and the connection whence the ticket". Others might disagree, > > > > I disagree, Nico! :) > > Excellent. So now consider what followed the above. That is, that the > correct thing to do is to properly encrypt a timestamp rather than XOR > an OTP that then gets reused when the ticket gets reused. > It's not XOR. It's addition mod 2^32. That's important because the *difference* between the ticket replay times is directly observable anyway. -Ekr Why on Earth are still doing improper crypto in TLS?!=E2=80=BD In TLS 1.3 = no > less! Call it "janky", call it what you will. It's broken. Please > fix. > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c18f09218e41c054e926ca1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 2:29 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Tue, May 02, 2017 at 04:52:17PM -0400, Daniel Kahn Gillmor wrote:
> On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote:
> > Well, I did say that to me there's not much difference to _me= _ between
> > "connections reusing the same ticket can be correlated to ea= ch other"
> > and "connections reusing the same ticket can be correlated t= o each other
> > and the connection whence the ticket".=C2=A0 Others might di= sagree,
>
> I disagree, Nico! :)

Excellent.=C2=A0 So now consider what followed the above.=C2=A0 That= is, that the
correct thing to do is to properly encrypt a timestamp rather than XOR
an OTP that then gets reused when the ticket gets reused.
<= div>
It's not XOR. It's addition mod 2^32. That's= important because the *difference*
between the ticket replay tim= es is directly observable anyway.

-Ekr
<= br>


Why on Earth are still doing improper crypto in TLS?!=E2=80=BD=C2=A0 In TLS= 1.3 no
less!=C2=A0 Call it "janky", call it what you will.=C2=A0 It'= s broken.=C2=A0 Please
fix.

Nico
--

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c18f09218e41c054e926ca1-- From nobody Tue May 2 16:05:47 2017 Return-Path: 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 85B83129C56 for ; Tue, 2 May 2017 16:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 pkushbHSMWDx for ; Tue, 2 May 2017 16:05:38 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DE012E03F for ; Tue, 2 May 2017 16:03:03 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id B24AEA004B18; Tue, 2 May 2017 16:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=YI0w4+AGxXYwfV uum2SwFMU9pR4=; b=UHk8HI8yBfIFMs9qIyYkFX5h1Of0Msx8H8JjFM0jH5efHi CSvLF73ioJ2Ku5n2rseGsRIl4jdVn66ephC/ZSVHo/JTmhFLX6rIJfs4I5MtdHH4 4cX6ZHGjawdXbmzYcjz/lM86zMMfsE5h8l1zh5Xw067kW9bD5ME4LC+uPF9Kc= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id E276DA004B17; Tue, 2 May 2017 16:03:01 -0700 (PDT) Date: Tue, 2 May 2017 18:02:59 -0500 From: Nico Williams To: Eric Rescorla Cc: Daniel Kahn Gillmor , TLS WG Message-ID: <20170502230258.GL10188@localhost> References: <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> <20170502212953.GK10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 23:05:39 -0000 On Tue, May 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote: > It's not XOR. It's addition mod 2^32. That's important because the > *difference* > between the ticket replay times is directly observable anyway. Computationally there's no real difference between that and XOR. From nobody Tue May 2 16:44:04 2017 Return-Path: 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 D56551274D0 for ; Tue, 2 May 2017 16:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 o3Atd6RkZLeP for ; Tue, 2 May 2017 16:44:01 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5931292F5 for ; Tue, 2 May 2017 16:42:33 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id 203so77469638ywe.0 for ; Tue, 02 May 2017 16:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zrmL966KZBflwwLhI/xjs/agJn931HGw2Xa6nJFBXvU=; b=qExfhiLKXgel03NSAyreiHEyNTQnycHTQmqi6jUad1k0WXhJv4H/Ynn/bfECQfgsbk 6DjL0CgU98dlfYluJosI461WJWkeQNJhkD3bLXiNF9bSiMZXaKtolmzHll6kA3squ/27 UGeEHdx2pcv71JJATTjaTntooV6WYgRFKq+5VM0gbolEwZzAm7GIl0EvfmShPEZTZI9y rps2wL7ybgUC3iOp5vqICP1mgD91ngcxoh3VSzV6o2O6MGBB5FOgPbB/iE8gRQsUo+Mz vVcNyLpXRA5HGU8fejuLhpGET8mHgH20E1weALC3aR3jT7ymtSdRHoWOEGAADL5DDF6m LvzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zrmL966KZBflwwLhI/xjs/agJn931HGw2Xa6nJFBXvU=; b=XC+R9HbWbt3z8AhxHxgItakjaV4uo7AJPhxv/Z1LVBsxrl5QmGZQrlXFtnmglfmgpv ChFR4+7nyctkNAcOlfLYLPK1o2GffuLlCwiDTztmh5l+rYLWsR461eNIGbR/pQEa4iW8 mTs/E3JcS06L5E0K05k3AKKxnM1NOVvikq0yVnAAjV2zH8smClh2nTSdGr5fzphSHsM2 sUNCgodrjTKGntvu6jHuYqaHkQfCl7N4XRkLUY/kIdb/Yl2/++tLFkn2ypCnVE+ymjBP kz81uGQyg5TmRe6t4nD3EQG4z9ggR+0kC9eOM9xsd+036W0u9dfP1U00zyRoFiyZeOkC Vixw== X-Gm-Message-State: AN3rC/7CwBXfo+pUVE9hOGu7gGULdFxaJ682Mk7adHLF7zylkhd1LTUQ s3VEaORSEJE7RaUYTIXf4uKf2wQedhhY X-Received: by 10.129.52.141 with SMTP id b135mr26916251ywa.85.1493768553125; Tue, 02 May 2017 16:42:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 2 May 2017 16:41:52 -0700 (PDT) In-Reply-To: <20170502230258.GL10188@localhost> References: <20170502182529.GG10188@localhost> <466fad64-5acd-d888-1574-10f95b2ab7bc@akamai.com> <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> <20170502212953.GK10188@localhost> <20170502230258.GL10188@localhost> From: Eric Rescorla Date: Tue, 2 May 2017 16:41:52 -0700 Message-ID: To: Nico Williams Cc: Daniel Kahn Gillmor , TLS WG Content-Type: multipart/alternative; boundary=001a11408984fc74a8054e9317ac Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 23:44:03 -0000 --001a11408984fc74a8054e9317ac Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 4:02 PM, Nico Williams wrote: > On Tue, May 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote: > > It's not XOR. It's addition mod 2^32. That's important because the > > *difference* > > between the ticket replay times is directly observable anyway. > > Computationally there's no real difference between that and XOR. > What information do you believe you are gathering here? As I stated, when the ticket is replayed, you already know the absolute time difference between those replays. -Ekr --001a11408984fc74a8054e9317ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 4:02 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Tue, Ma= y 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote:
> It's not XOR. It's addition mod 2^32. That's important bec= ause the
> *difference*
> between the ticket replay times is directly observable anyway.

Computationally there's no real difference between that and XOR.=

What information do you believe you ar= e gathering here?

As I stated, when the ticket is = replayed, you already know the absolute time
difference between t= hose replays.

-Ekr
=C2=A0

--001a11408984fc74a8054e9317ac-- From nobody Tue May 2 16:52:12 2017 Return-Path: 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 4BFA3126DED for ; Tue, 2 May 2017 16:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 YgGhTp4gXBvN for ; Tue, 2 May 2017 16:52:09 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12C3129486 for ; Tue, 2 May 2017 16:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1493768995; x=1525304995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rKUyFPVfxGyO5oe+jTjrpg+bzP9zVHR/7mc5pFB02Ac=; b=Qxu8Pb7FGv7UCXCnuPWMpGpuCfFnpSwu5pzmwGCTktoZys/zdQfHdiWD gWHSMHkQEz56ksT0vB8yaSNOhOl4pxe1Zmq0rFFiYrWGKiHjBtGtoJgkU 2ISkSaFW71NuJHTzeioxjFNM06q2m+thyYOyp9dyVE8hxLgXZL2h6FhqS q3Kus7o56BjsvGtxh/5htmUt4EJWWkZj4ov/se8L7OxEcKlE3iLNkI2Jh 25mtXSNFe4fRniQOhYii5HQSidmrNMGqPVFgnpYO5bNjR53LHx/38CFbF zl4Lnj2VKCblCoCdYUpy4+k3WnkIvMlfapNqhE0KBfsF5L5J6TmO1KzEx Q==; X-IronPort-AV: E=Sophos;i="5.38,281,1491220800"; d="scan'208";a="152519370" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 May 2017 11:49:32 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 11:49:31 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Wed, 3 May 2017 11:49:31 +1200 From: Peter Gutmann To: Benjamin Kaduk , Nico Williams CC: TLS WG Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NPTAGYfwrCc0yRmMInbVKyjKHghKSAgAABiQCAAAKfgIAAA3MAgAAEtgCAAAIuAIAABAyAgAEfkNM= Date: Tue, 2 May 2017 23:49:31 +0000 Message-ID: <1493768953994.69753@cs.auckland.ac.nz> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 23:52:11 -0000 Benjamin Kaduk writes:=0A= =0A= >I thought TLS clients were supposed to have even worse clocks (in terms of= =0A= >absolute time) than Kerberos clients.=0A= =0A= Many of the devices I work with don't have clocks (at best they have non-= =0A= persistent monotonic counters), so I guess that's true in some sense...=0A= =0A= Peter.=0A= =0A= = From nobody Tue May 2 17:30:03 2017 Return-Path: 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 5C34012E872 for ; Tue, 2 May 2017 17:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 H-f2xE_FmMOq for ; Tue, 2 May 2017 17:30:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009D612945F for ; Tue, 2 May 2017 17:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1493771280; x=1525307280; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XAFYlP8vrTmFLBXLyaJo8yS0TPRiV6j0qgXbxKK7Rqc=; b=XLME7JG5wq7dNb6SVDv5rpEcMfRG+etSHfqVDLlLnZHY5QpNJc2xpeQO p82cRgyoiVSdVddjAYbAzQTT4RdEFvGbVAd9fXlnXiDUaWXA99j213pds E3rAPiutzu+0Upd8on0QKrI+Wwmku6F5Qsx3H5CQsbaGl68z0rAyFfvWb Yft5u1WOHkO9rbr1U6yYFWz70VMDMv3boMhDAPekNIIiOgIrVNVmhMu3T 4tdjHAn1tbM3L1luAYlxYcxON8IFNiNTLDPgBLoYyntEov9zYhTYzARwT 6cnljkjW0+S5C9qlNbSM0TvHdbXo1P+r/pMHyyF+Y1uch7QZNwwWcZ+9R Q==; X-IronPort-AV: E=Sophos;i="5.38,281,1491220800"; d="scan'208";a="152528948" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 May 2017 12:27:55 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 12:27:55 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Wed, 3 May 2017 12:27:55 +1200 From: Peter Gutmann To: "Fries, Steffen" , "tls@ietf.org" Thread-Topic: Definition of cipher suites for TLS 1.2 still possible? Thread-Index: AdLDTWpeLBLLQHFiTSKY+DwL/vtEYAAVpeCi Date: Wed, 3 May 2017 00:27:54 +0000 Message-ID: <1493771256879.29376@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Definition of cipher suites for TLS 1.2 still possible? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 00:30:01 -0000 Fries, Steffen writes:=0A= =0A= >it may be a na=EFve question, but is it still possible to define and=0A= >standardize new cipher suites for TLS 1.2 as an RFC, when TLS 1.3 is almos= t=0A= >finished?=0A= =0A= Why not?=A0 TLS 1.2 will be with us for many more years, possibly decades. = There=0A= are entire industry segments who are still in the process of moving off TLS= =0A= 1.0 over the next 5-10 years.=0A= =0A= Peter.=0A= = From nobody Tue May 2 17:31:00 2017 Return-Path: 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 E968E129B48 for ; Tue, 2 May 2017 17:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 guBVwq02b0i1 for ; Tue, 2 May 2017 17:30:53 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B9C129B82 for ; Tue, 2 May 2017 17:28:41 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 203so77799418ywe.0 for ; Tue, 02 May 2017 17:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UU010+FdkYnx1AyCpdPXXJ6ZcbvuMZVGjQ/mddXLhHc=; b=lrfrVB/DFZS4OImVTnBXFi8haDmYlZw6zQI4dOQVuJvrzmMPxYogEpEQ6MuGlSWc/D Qr5losX/G5KyDUGefPOq0rWEYArU2Y5Brdzs9sBoNuZyKlVSasz2pPIZ1Ho2kBMCZieO I2CDBTjhDnA8kbT7yYe85uhd2NDuQ60rHDWZ5JU/AaNAU9MiIN3RPmEUwAcAO0nubpeK cX9l+hc75IiqC4YHlvnZOkyjO7m4nLJsyA8l1q8LirbbhjE8ZVkrn34J5GpLHyaMCfpQ rRxgDDISHecRq6PugWOx0VnfeNtt/IlH1gRyOlPBOWvL1XO+lKQ7kDXko1ZtfIEL3isc euFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UU010+FdkYnx1AyCpdPXXJ6ZcbvuMZVGjQ/mddXLhHc=; b=ObpesPPl1zJetxd4q2GxqPZBO+Q36EplTOyfhvQchsEw8zbXjjjIbATYHhCPhdhpj8 E6VQFqTtL3AaWrzexZvjy7doInt5WUeYOZwW2JN+21eASxunHy63nNe+uk3wJErHuqIp tsxJuCYbSi0g0cLYRoHxKVjqeonCGHYL+iyexe70JYCPw6XjI9FKSRmP2TZTbp2KbpkW 1ge60+T/sM8Yi2g3Uo7nYKJaoDtcJaUlsYMnMw4xtL+TLihE3hjCkpsoUtsOYVS5urxM gZVl1ZxeQ7E8xfr9ixWX+6EhgOC7yyrnwd1G7nOzrt8sHvyyHJ5hrp/h1hwMX71KO+an EYSA== X-Gm-Message-State: AN3rC/7RpUIObg3ioJSR7JXflbqkmV76EjBDWcUNWQmW3IKDWLRBLhvx EgNa+n/+ozUVjynEUlAsJemD4B+ICZZx X-Received: by 10.129.152.4 with SMTP id p4mr26904601ywg.1.1493771320234; Tue, 02 May 2017 17:28:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 17:28:39 -0700 (PDT) In-Reply-To: <1493768953994.69753@cs.auckland.ac.nz> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 17:28:39 -0700 Message-ID: To: Peter Gutmann Cc: Benjamin Kaduk , Nico Williams , TLS WG Content-Type: multipart/alternative; boundary=94eb2c0bd9eeeb4692054e93bc45 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 00:30:58 -0000 --94eb2c0bd9eeeb4692054e93bc45 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 4:49 PM, Peter Gutmann wrote: > Benjamin Kaduk writes: > > >I thought TLS clients were supposed to have even worse clocks (in terms of > >absolute time) than Kerberos clients. > > Many of the devices I work with don't have clocks (at best they have non- > persistent monotonic counters), so I guess that's true in some sense... > This whole problem of needing client-side clocks, and having to obfuscate an age, goes away if we remove the ticket age entirely. Hopefully the security review makes a strong case that the age is fairly useless from a security point of view. Even with the age, an attacker can still generate millions to billions of replays. Even with very conservative numbers, e.g. to just one host, the attacker can still certainly generate tens of thousands of replays within the permitted window. Better to require servers to reject duplicates (when used with Zero-RTT), and leave it at that. -- Colm --94eb2c0bd9eeeb4692054e93bc45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 4:49 PM, Peter Gutmann <pgut001@cs.auck= land.ac.nz> wrote:
Benjamin Kaduk <bkaduk@aka= mai.com> writes:

>I thought TLS clients were supposed to have even worse clocks (in terms= of
>absolute time) than Kerberos clients.

Many of the devices I work with don't have clocks (at best they = have non-
persistent monotonic counters), so I guess that's true in some sense...=

This whole problem of needing client-s= ide clocks, and having to obfuscate an age, goes away if we remove the tick= et age entirely.=C2=A0

Hopefully the security revi= ew makes a strong case that the age is fairly useless from a security point= of view. Even with the age, an attacker can still generate millions to bil= lions of replays. Even with very conservative numbers, e.g. to just one hos= t, the attacker can still certainly generate tens of thousands of replays w= ithin the permitted window.=C2=A0 Better to require servers to reject dupli= cates (when used with Zero-RTT), and leave it at that.=C2=A0

--
Colm
--94eb2c0bd9eeeb4692054e93bc45-- From nobody Tue May 2 17:54:57 2017 Return-Path: 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 7E77E129405 for ; Tue, 2 May 2017 17:54:56 -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] 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 JzHS6N8qd9Vs for ; Tue, 2 May 2017 17:54:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7160129410 for ; Tue, 2 May 2017 17:51:50 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 04FAA7A32F1 for ; Wed, 3 May 2017 00:51:43 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 2 May 2017 20:51:43 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <803FB95F-3271-407A-B483-5C0C996D3F04@dukhovni.org> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 00:54:56 -0000 > On May 2, 2017, at 8:28 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > This whole problem of needing client-side clocks, and having to = obfuscate an age, goes away if we remove the ticket age entirely.=20 >=20 > Hopefully the security review makes a strong case that the age is = fairly useless from a security point of view. Even with the age, an = attacker can still generate millions to billions of replays. Even with = very conservative numbers, e.g. to just one host, the attacker can still = certainly generate tens of thousands of replays within the permitted = window. Better to require servers to reject duplicates (when used with = Zero-RTT), and leave it at that.=20 Some choices are driven by practical engineering considerations. The ticket lifetime is likely to be considerably longer than the replay clock window. The server should indeed reject replays, but if it is able to flush the replay cache faster, it may be able to handle that job a lot more efficiently under load. What is a likely ticket lifetime for a server that supports 0-RTT (let's assume an HTTP server)? How wide a replay clock window is likely reasonable (to allow for RTT and TCP retransmission delays)? If the two are approximately the same, then just rejecting duplicates and expired tickets is enough. If the ticket lifetime is 10x or 100x larger, it may make sense to be able to limit the lifetime of replay cache entries to the smaller TCP skew. --=20 Viktor. From nobody Tue May 2 18:48:50 2017 Return-Path: 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 2014D1293EC for ; Tue, 2 May 2017 18:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 NZfta2d7Megb for ; Tue, 2 May 2017 18:48:47 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDC1129B23 for ; Tue, 2 May 2017 18:45:54 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id k11so78397395ywb.1 for ; Tue, 02 May 2017 18:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DLISk/ABsf4Kq5EhmAq5MnRVTiGIWbrvb6YXT/3gyg0=; b=CWL3nN2NcMIeGKv+HMXhob7ppODzshOaTwbiY4dhAS465FgRTwgHP2trqCs94FN7Jg Euo95gRnPPohN+HJVSXgPasCc8vSYks9Epn8dVB+8MLrXYRnXutu3/rPE08zJ5xUuOp9 c4xBGn+9ZAef597MzStdID2ODrnfrQB6wBr+uIx77H32daV0Zt6eebIIc+9ZkMhFwfO7 zT4mYaUx5Sr/BT0mktVah/84qrsATtc/FcdqLUHEaUr8f7gOafX4MkM1f3Kk06RILxpS Wm9+/tOAMlcelW1Hh7U4xCtlt7sB6XFHE+Nvu/40eg/ZdhHn66lSWhw/4RkrWZt3fO1g FEzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DLISk/ABsf4Kq5EhmAq5MnRVTiGIWbrvb6YXT/3gyg0=; b=IHtovkzGkSptlEPM+BYj0gF/eAiWPGhL3NLFPEzrg4Vy/95PCLYXDDqczdOl2RPU+X 2OV8MGGrtpnrgADuAr27uazb8SuRsahN/NvK5YNeljHoakoolZf82uSXycZrmiq5qMlT ImMeXNuWSqDH3C0Z2A7CVgTDi6oVSpXXoFA2vksXWsDtQhDv9SXO22BIKZL0cXFraJxB KPZ8pusJM8ciI1XzFx5cvgnvM1HtQTTES1BEU5lJT3TAeGjv3AvyGSD6ayO5nb9PSWiv DaU8dhRUyv9cK/Se/xwEWW/ezmXSWKjbq1S+oxhgnSPPUxdaYforATX0Xo1QzJGzibXp awSw== X-Gm-Message-State: AN3rC/7VV5wCacgK6CJbPp9Km6VcWAd81Sc2v3BLLpE66cR606UVdMLH uYBBX2LoHyge4ezC3eAGpa+bJ4P6Hw== X-Received: by 10.129.105.198 with SMTP id e189mr27167031ywc.296.1493775953492; Tue, 02 May 2017 18:45:53 -0700 (PDT) MIME-Version: 1.0 References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> <803FB95F-3271-407A-B483-5C0C996D3F04@dukhovni.org> In-Reply-To: <803FB95F-3271-407A-B483-5C0C996D3F04@dukhovni.org> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 03 May 2017 01:45:42 +0000 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a1147125615696f054e94d143 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 01:48:49 -0000 --001a1147125615696f054e94d143 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni wrote: > .Some choices are driven by practical engineering considerations. > The ticket lifetime is likely to be considerably longer than the > replay clock window. The server should indeed reject replays, > but if it is able to flush the replay cache faster, it may be able > to handle that job a lot more efficiently under load. > Good point! It's also common for caches to implement LRU, where a shorter lifetime is better. What is a likely ticket lifetime for a server that supports 0-RTT > (let's assume an HTTP server)? I'm going to guess that providers will set it as high as they can ... every little helps. So 7 days. > How wide a replay clock window is likely reasonable (to allow for RTT and > TCP retransmission delays)? > I think we have to assume that a replay attempt could come at any time. A time based mitigation doesn't work. -- Colm -- Colm --001a1147125615696f054e94d143 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On = Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
.Some choices are = driven by practical engineering considerations.

The ticket lifetime is likely to be considerably longer than the
replay clock window.=C2=A0 The server should indeed reject replays,
but if it is able to flush the replay cache faster, it may be able
to handle that job a lot more efficiently under load.

Goo= d point! It's also common for caches to implement LRU, where a shorter = lifetime is better.=C2=A0

What is a likely ticket lifetime for a server that supports 0-RTT
(let's assume an HTTP server)?=C2=A0

=
I'm going to guess that providers will set it as high as th= ey can ... every little helps. So 7 days.
=C2=A0
How wide a replay clock window is=C2=A0lik= ely reasonable (to allow for RTT and TCP retransmission delays)?

I think we have to assume that a rep= lay attempt could come at any time. A time based mitigation doesn't wor= k.=C2=A0
=

--
Colm
--
Colm
--001a1147125615696f054e94d143-- From nobody Tue May 2 19:40:14 2017 Return-Path: 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 18784129B42 for ; Tue, 2 May 2017 19:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 si43p-2lY7WO for ; Tue, 2 May 2017 19:40:11 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3AB129B83 for ; Tue, 2 May 2017 19:38:11 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l18so18750258oig.2 for ; Tue, 02 May 2017 19:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Wbc3j+0jzE3BW0KWuYWyuiIV+bYbwfOAG8kshCoOs9U=; b=Foi/XbngGaD3aMsnrmInIbcOYPFW3JYSOPpWxCNxoO4Qkjv3ivQtlXec8s2aGDgGAV qq2YWo5Zx9eZqRXsi0TpyF29DnFw2EMTs9mzqRQwkERK9QLJFLmmP1wiYevLsnJ+PXO3 kiAKNld22CxRvFwTK9U+dTQF6u/BjCPXROhygxd6Lx1S0evI9rmwoJIMpwFpFvfr2ePG Hn/sL3s/AhnnkFntvTLlmtoldTZibbTWvABaGP49h6uJF4UL7wpsmulEWJ/lyXpICN37 HMN1l7dz8YjDf6a5f92xGUMwP98fCYaQgc42Yvo16+4e/Pol68Nn4TtAoC/hVjcKKZj1 fzTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=Wbc3j+0jzE3BW0KWuYWyuiIV+bYbwfOAG8kshCoOs9U=; b=aPyR33qeMqMffGXbFIBQlvLV/m3j/InnOd3uJxSpKtIHDk6NlTcFwNyVZUVCofljwU LGGsytbHuAoXEI4UZbppTBsUrcZCtPl22HFTCEgXVtFaDFINXPm8GlPaEjxZjvOwmixu Ne5gJk6Ev84nvEytsL1lCzMf3DhSpnP/f51LbMrPP51+ybYZ94j5929BnSbnssgMYtoT IevwxG/l+iUyE5zT+VNGbyeLJCyFz5Dnh4W0v/K+wjDhXFplNtdD1vh9IBqSheRbiXwV Y0icLqLKTtLfYRxiMq2hThPO26bcdx49rjbFER7Hvl3UhtyLTbPIqcKIkfrlMF2pf3we TiEQ== X-Gm-Message-State: AN3rC/629dwFXQfApBdWMkO+oxuR0DU2K8dbd0qiXwNzeUDTVTvySMr9 RkTh0WwfV+N8t/WCG/vz95Vu01mKSrcOkGg= X-Received: by 10.202.77.195 with SMTP id a186mr11172146oib.117.1493779090714; Tue, 02 May 2017 19:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.139.199 with HTTP; Tue, 2 May 2017 19:38:09 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> <803FB95F-3271-407A-B483-5C0C996D3F04@dukhovni.org> From: Jeffrey Walton Date: Tue, 2 May 2017 22:38:09 -0400 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: TLS WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 02:40:13 -0000 On Tue, May 2, 2017 at 9:45 PM, Colm MacC=C3=A1rthaigh = wrote: > > On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni > wrote: >> >> .Some choices are driven by practical engineering considerations. >> >> The ticket lifetime is likely to be considerably longer than the >> replay clock window. The server should indeed reject replays, >> but if it is able to flush the replay cache faster, it may be able >> to handle that job a lot more efficiently under load. > > Good point! It's also common for caches to implement LRU, where a shorter > lifetime is better. > >> What is a likely ticket lifetime for a server that supports 0-RTT >> (let's assume an HTTP server)? > > I'm going to guess that providers will set it as high as they can ... eve= ry > little helps. So 7 days. It seems like this would follow the same policies for session management and/or authentication and authorizations. If its low value data (like a GMail account), then let it live longer, like weeks. If its high value data (like executive compensation, mergers and acquisitions or pending litigation), then its probably shorter, like hours to days. What's the polyfill that allows data sensitivity levels to trickle down into the transport layer? Jeff From nobody Tue May 2 20:19:56 2017 Return-Path: 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 6AD8C129BF8 for ; Tue, 2 May 2017 20:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 mV5aoJF2okId for ; Tue, 2 May 2017 20:19:51 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26729129C60 for ; Tue, 2 May 2017 20:17:47 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id 203so78982751ywe.0 for ; Tue, 02 May 2017 20:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eji5ZrkwxOmCKOzwKaYLG9eZEDMaPk35CqGNjMIZ24o=; b=ivz5J6XPP933mpdtBUrFRYB0c70w8BBckDYNQ0+gq59g21GAwImTedqM1tLOkz/BL3 M105xHKAec6iUsSRH+MeDlp8sGNK6/b3eEUR3t8vn5tRHCgV2BJ2XZzjtqTv3nkq3kwL aBQ/cbj7kpm5ttbky7Q2LV4e9j9cSq1t91n5zio05sJu9eQdDoCB2gcH3PLIIf66tqKT D/TPdiDiICRLh9e3/dJNHr/pnarDzgjuZyQ71z22t3hIkbtkE3F9k3p+h+dDVhDBhuAI +xSR+4ExUUfoV1Cycz1hQQg2fKmz+JC15k7qGN1ZH9Vqm8QWKnJ0Sk/xrsFc/CE2BccC YKLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Eji5ZrkwxOmCKOzwKaYLG9eZEDMaPk35CqGNjMIZ24o=; b=UFvJeix8hHHJJRhBzTwJkddbKLeu4FLcg56ms4vw8dpk9mgM6S9efUMWV/28UMg3xO dJOea77efgo41mDHNrfz50AX7EXNyqcbcPA6VRCjoTTDJ1ykimLGVTzQk7liGEBQXQN/ hT7HlqzgxmSC0vLAB+Viyaq6ek+sVKgPhZ58oCrWGFGcRt426P2BL0Skrb9omPEGEZCs c4p6H+CDpZV824Pur0iTlhACCXJl69x60y0KAJc/X9HsHtSzo2R1byB3fA2K/73SODgG JrB5RPzVTTmrecx5PX/ElPw6H8/dqe/4zW58vSfPonz/K7OCucEvlX/hiuwd1H+6QRCq CfBw== X-Gm-Message-State: AN3rC/5QAuZBb7QlpbpVKMrQnuID5zGasgSWDjQyT7p/9RfxSuXU/3iK Hw0QJjPMcSSdGu7UIhY8Mym0RSfP5AdYgag= X-Received: by 10.129.52.141 with SMTP id b135mr27442030ywa.85.1493781466206; Tue, 02 May 2017 20:17:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 2 May 2017 20:17:05 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 2 May 2017 20:17:05 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11408984aaaf0b054e961926 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 03:19:54 -0000 --001a11408984aaaf0b054e961926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colm, Thanks for your review. Interesting stuff. Scrolling ahead to the recommendations, I see you have: * Require implementations to robustly prevent Ticket re-use for 0-RTT. This seems like a good idea. I think it's arguable that we got a bit nihilistic about this, and as you say, you can do a pretty good job of reducing replay within a given data center using some local anti-replay mechanism. I would tend to think that a strong SHOULD is what you want here, as a MUST is going to be a lot more like a 6919 MUST (BUT WE KNOW YOU WON'T). I'll start preparing a PR on this. Here are the points I plan to make: - There are a series of attacks involving lots of replays (cherry-picking your draft) - Implementations cannot completely prevent replay but can do a lot to limit it using the following techniques (focusing on strike register and single-use cache). I understand from your document and our previous conversation that you believe single-use tokens are easier to implement on the server side, but I'm not sure I really follow your argument. If you want to provide some short text on that that we can all agree on, then I think we could incorporate this as well. * Partial mitigation for Gilmor attacks: deliberately duplicate 0-RTT data This seems like some sort of extra-grease, but I'm kinda skeptical that anyone is going to do it. Perhaps it would be useful to add it to draft-ietf-tls-grease? * Require TLS proxies to operate 0-RTT transitively I've read this several times but I have to admit I don't understand it. Do you think you could rephrase? The following doesn't appear in your recommendations, but I think you also think we should: * Adopt something like PR#998 to make each PSK_id correspond to a different PSK even when they are issued on the same connection. This seems straightforward, and I think we would also want to add some text in security considerations describing the security implications of the use of session-cache style PSKs to those of ticket-style PSKs, especially when this technique is used. * Require that clients only use tickets once. For the reasons Viktor indicated, I tend to think this is inadvisable. As you indicate, there are two implications of ticket reuse: - It leaks some of ticket_age If the server wants to support it, it - needs to not have a single-use session cache, so that threatens PFS. As discussed on the list, the ticket_age issue is principally a linkage issue, and the ticket is inherently linkable [0]. WRT the PFS issue, the server can always implement a single-use cache if it wants to, and if the server is doing ordinary tickets (which I understand you don't like, but I don't think we are going to ban), then the PFS situation seems unchanged. I have considered whether we should have a way for the server to say "only use this ticket once" but I'm not sure how that helps as the server can just unilaterally forget the tickeet. * Remove ticket_age This doesn't seem like a good idea: if you are implementing a strike register, you want to use ticket_age to help distinguish "fresh" from "unknown state". I.e., the ticket_age + the ticket issue time allows you to determine approximately when a CH was sent, and any CH that is significantly older or newer than now is forced back into 1-RTT. -Ekr [0] With that said, it wouldn't honestly be that hard to Derive-Secret() a mask off of the PSK at the same time we derive the early data key, if we really wanted to. On Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh = wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2= n. > Thanks to feedback in the room I've now tightened up the findings from th= e > review and posted them as an issue on the draft GitHub repo: > > https://github.com/tlswg/tls13-spec/issues/1001 > > I'll summarize the summary: Naturally the focus was on forward secrecy an= d > replay. On forward secrecy the main finding was that it's not necessary t= o > trade off Forward Secrecy and 0-RTT. A single-use session cache can provi= de > it, and with the modification that ekr has created in > https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for > both pre-auth and post-auth tickets, and it allows clients to build up > pools of meaningfully distinct tickets. > > There's also an observation there that it should really be that clients > "MUST" use tickets only once. Any re-use likely discloses the obfuscated > ticket age, which is intended to be secret. Right now it's a "SHOULD". > > On replay, the main finding is that what's in the draft is not workably > secure, and the review includes 5 different attacks against 0-RTT data to > illustrate that. Attacks 1 and 2 show that the kind of replay permitted b= y > the draft is very different from the kind of replay permitted by dkg's > existing downgrade-and-retry attack. I also go over why it very very > difficult to many applications to achieve that idempotency, and why one > idempotency pattern actually relies on non-replayable messages. > > Attack 3 shows that idempotency is not sufficient, applications must also > be free of measurable side-effects, which is not practical. Attack 4 sho= ws > that 0-RTT breaks a common security mechanism: spoofing-resistant > throttles. Attack 5 shows that 0-RTT replay-ability enables an additional > form of traffic analysis. > > The recommendation in the review is that implementations "MUST" prevent > replays of 0-RTT section, with some additional discussion about why the > existing advice is unlikely to be followed, and why consistent > interoperability matters here. > > Unfortunately, I wasn't aware until Friday that this review would be > coming so late in the TLD1.3 draft process, and my apologies for that. I = am > now planning to attend the future WG in-person meetings and look forward = to > seeing many of you there. > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11408984aaaf0b054e961926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colm,

Thanks for your review= . Interesting stuff.

Scrolling ahead to the recomm= endations, I see you have:

* Require implementatio= ns to robustly prevent Ticket re-use for 0-RTT.

Th= is seems like a good idea. I think it's arguable that we got a bit
nihilistic about this, and as you say, you can do a pretty good job o= f
reducing replay within a given data center using some local
anti-replay mechanism. I would tend to think that a strong SHOULD is=
what you want here, as a MUST is going to be a lot more like a 6= 919
MUST (BUT WE KNOW YOU WON'T). I'll start preparing a = PR on this.=C2=A0 Here
are the points I plan to make:
<= br>
- There are a series of attacks involving lots of replays
=C2=A0 (cherry-picking your draft)

- Implem= entations cannot completely prevent replay but can do a lot to
= =C2=A0 limit it using the following techniques (focusing on strike register=
=C2=A0 and single-use cache).

I underst= and from your document and our previous conversation that you
bel= ieve single-use tokens are easier to implement on the server side,
but I'm not sure I really follow your argument. If you want to provid= e
some short text on that that we can all agree on, then I think = we
could incorporate this as well.

* Par= tial mitigation for Gilmor attacks: deliberately duplicate 0-RTT
= =C2=A0 data

This seems like some sort of extra-gre= ase, but I'm kinda skeptical
that anyone is going to do it. P= erhaps it would be useful to add it to
draft-ietf-tls-grease?


* Require TLS proxies to operate 0-RTT= transitively

I've read this several times but= I have to admit I don't understand
it. Do you think you coul= d rephrase?


The following doesn'= ;t appear in your recommendations, but I think you
also think we = should:


* Adopt something like PR#9= 98 to make each PSK_id correspond to a
=C2=A0 different PSK even = when they are issued on the same connection.

This = seems straightforward, and I think we would also want to add some
text in security considerations describing the security implications
=
of the use of session-cache style PSKs to those of ticket-style PSKs,<= /div>
especially when this technique is used.

=
* Require that clients only use tickets once.

=
For the reasons Viktor indicated, I tend to think this is inadvi= sable.
As you indicate, there are two implications of ticket reus= e:

- It leaks some of ticket_age If the server wan= ts to support it, it
- needs to not have a single-use session cac= he, so that threatens PFS.

As discussed on the lis= t, the ticket_age issue is principally a
linkage issue, and the t= icket is inherently linkable [0]. WRT the PFS
issue, the server c= an always implement a single-use cache if it wants
to, and if the= server is doing ordinary tickets (which I understand
you don'= ;t like, but I don't think we are going to ban), then the PFS
situation seems unchanged. I have considered whether we should have a
way for the server to say "only use this ticket once" but I= 'm not sure
how that helps as the server can just unilaterall= y forget the tickeet.


* Remove tick= et_age

This doesn't seem like a good idea: if = you are implementing a strike
register, you want to use ticket_ag= e to help distinguish "fresh" from
"unknown state&= quot;. I.e., the ticket_age + the ticket issue time allows
you to= determine approximately when a CH was sent, and any CH that
is s= ignificantly older or newer than now is forced back into 1-RTT.
<= br>
-Ekr

[0] With that said, it wouldn&#= 39;t honestly be that hard to
Derive-Secret() a mask off of the P= SK at the same time we derive the
early data key, if we really wa= nted to.




<= div>




<= div>

On Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh <colm@allcosts.n= et> wrote:
On Sunday at the TLS:DIV workshop I presented a summary of findings of a s= ecurity review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. = Thanks to feedback in the room I've now tightened up the findings from = the review and posted them as an issue on the draft GitHub repo:

https://github.com/tlswg/tls13-spec/issues/1001

I'll summarize the summary: Naturally the focus = was on forward secrecy and replay. On forward secrecy the main finding was = that it's not necessary to trade off Forward Secrecy and 0-RTT. A singl= e-use session cache can provide it, and with the modification that ekr has = created in=C2=A0https://github.com/tlswg/tls13-spec/pull/998 , suc= h a cache works for both pre-auth and post-auth tickets, and it allows clie= nts to build up pools of meaningfully distinct tickets.

There's also an observation there that it should really be that c= lients "MUST" use tickets only once. Any re-use likely discloses = the obfuscated ticket age, which is intended to be secret. Right now it'= ;s a "SHOULD".=C2=A0

On replay, the main= finding is that what's in the draft is not workably secure, and the re= view includes 5 different attacks against 0-RTT data to illustrate that. At= tacks 1 and 2 show that the kind of replay permitted by the draft is very d= ifferent from the kind of replay permitted by dkg's existing downgrade-= and-retry attack. I also go over why it very very difficult to many applica= tions to achieve that idempotency, and why one idempotency pattern actually= relies on non-replayable messages.=C2=A0

Attack 3= shows that idempotency is not sufficient, applications must also be free o= f measurable side-effects, which is not practical.=C2=A0 Attack 4 shows tha= t 0-RTT breaks a common security mechanism: spoofing-resistant throttles. A= ttack 5 shows that 0-RTT replay-ability enables an additional form of traff= ic analysis.=C2=A0

The recommendation in the revie= w is that implementations "MUST" prevent replays of 0-RTT section= , with some additional discussion about why the existing advice is unlikely= to be followed, and why consistent interoperability matters here.=C2=A0

Unfortunately, I wasn't aware until Friday that = this review would be coming so late in the TLD1.3 draft process, and my apo= logies for that. I am now planning to attend the future WG in-person meetin= gs and look forward to seeing many of you there.=C2=A0

--
Colm<= /div>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11408984aaaf0b054e961926-- From nobody Tue May 2 20:29:09 2017 Return-Path: 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 BDD79129BB2 for ; Tue, 2 May 2017 20:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 qpfKIlNfRp1g for ; Tue, 2 May 2017 20:29:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E361205D3 for ; Tue, 2 May 2017 20:27:06 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id ED4E67A32F1 for ; Wed, 3 May 2017 03:27:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 2 May 2017 23:27:04 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <48763856-04CB-4DC3-9A71-126F6EDB4279@dukhovni.org> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> <803FB95F-3271-407A-B483-5C0C996D3F04@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 03:29:08 -0000 > On May 2, 2017, at 9:45 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > I think we have to assume that a replay attempt could come at any = time. > A time based mitigation doesn't work. A time-based mitigation does not remove the need for an anti-replay cache (where a service protocol, supports 0-RTT, but is not idempotent). What I am saying, is that a time-based counter-measure can substantially reduce the size of the required cache, because out-of-window replays are rejected. That replay window can be a narrow window around the time the ticket is first (and never again legitimately) used, rather than the much larger ticket validity interval. The obfuscated_ticket_age field makes it possible to determine which transmissions are "in-window". It remains an exercise for the = implementor to handle "in-window" replays appropriately. I agree with Nico that additive obfuscation feels like a hack, but am willing to accept this as somewhat "natural" within the design tradition of TLS. Could someone explain how observing ticket reuse reveals the secret "ticket_age_add" value? The situation seems "time translation invariant" under changes in the "ticket_age_add" value. Doesn't the attacker see the same result as he would see with a for an offset "ticket_age_add" obtained at a corresponding offset time in the past? --=20 Viktor. From nobody Tue May 2 21:23:59 2017 Return-Path: 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 73EF9127867 for ; Tue, 2 May 2017 21:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 x_Jo9BT-Od5Y for ; Tue, 2 May 2017 21:23:56 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D603C129413 for ; Tue, 2 May 2017 21:21:54 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 2EFA3A00762E; Tue, 2 May 2017 21:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nNbT18lczbUu5U 4r0kWLhP5hjbA=; b=jSbk5+nw8iDz6bFD+ZZAG1EZWLEyuK6ncjJ2cM7jkPT38t 0EHTMwDGT77Jy2QhkyMzgZUtp5DdV/h/UtP0+Us1XB0PZ34TgJNYMiEcF9miI0O1 somBQS9ANgKv2McoJLYQz5YZbcxsQUGqay8dpfcE7gE8/uX2ZjLj2vj61K1q4= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id BD618A00762D; Tue, 2 May 2017 21:21:53 -0700 (PDT) Date: Tue, 2 May 2017 23:21:51 -0500 From: Nico Williams To: Peter Gutmann Cc: Benjamin Kaduk , TLS WG Message-ID: <20170503042150.GM10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1493768953994.69753@cs.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 04:23:58 -0000 On Tue, May 02, 2017 at 11:49:31PM +0000, Peter Gutmann wrote: > Benjamin Kaduk writes: > >I thought TLS clients were supposed to have even worse clocks (in terms of > >absolute time) than Kerberos clients. > > Many of the devices I work with don't have clocks (at best they have non- > persistent monotonic counters), so I guess that's true in some sense... Yeah, but a non-persistent clock is fine if the client can learn time from the server (and keep a different offset from system time to every server if need be, learning system time from one of them, or from NTP, or whatever). Nico -- From nobody Tue May 2 21:24:43 2017 Return-Path: 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 842D3128CFF for ; Tue, 2 May 2017 21:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 a7L8U6uEol1h for ; Tue, 2 May 2017 21:24:41 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A11712762F for ; Tue, 2 May 2017 21:22:31 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id E6F66A007630; Tue, 2 May 2017 21:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=aQpQqML+8g5cpY RO5jVNaCALDZA=; b=gk0Mo4nBQFLIzEUM/X6lMkH9Z/1OBKXO4BF2Yq+oLjBZDb eFfkneIZjCv1y953o9K0UrDEQKP7oeGoNgjMDGcvhTyGH+isnZlK0pLNyUW1Xc9g Hj/KWy2c9liEm4v1T6992a4cSErwjM2AdQQMKMHH34Mm4bIvHk49ORcfsCLaM= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 8B4B9A00762F; Tue, 2 May 2017 21:22:30 -0700 (PDT) Date: Tue, 2 May 2017 23:22:28 -0500 From: Nico Williams To: Eric Rescorla Cc: Daniel Kahn Gillmor , TLS WG Message-ID: <20170503042227.GN10188@localhost> References: <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> <20170502212953.GK10188@localhost> <20170502230258.GL10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 04:24:42 -0000 On Tue, May 02, 2017 at 04:41:52PM -0700, Eric Rescorla wrote: > On Tue, May 2, 2017 at 4:02 PM, Nico Williams wrote: > > On Tue, May 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote: > > > It's not XOR. It's addition mod 2^32. That's important because the > > > *difference* > > > between the ticket replay times is directly observable anyway. > > > > Computationally there's no real difference between that and XOR. > > What information do you believe you are gathering here? I believe the attack described is finding the time of the session's establishment. Nico -- From nobody Tue May 2 21:26:54 2017 Return-Path: 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 4BB6D12922E for ; Tue, 2 May 2017 21:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 kZn8YzeRQdTw for ; Tue, 2 May 2017 21:26:50 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E24312EAAA for ; Tue, 2 May 2017 21:24:40 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 61323A00762F; Tue, 2 May 2017 21:24:39 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 02452A00762E; Tue, 2 May 2017 21:24:38 -0700 (PDT) Date: Tue, 2 May 2017 23:24:36 -0500 From: Nico Williams To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Cc: Peter Gutmann , Benjamin Kaduk , TLS WG Message-ID: <20170503042435.GO10188@localhost> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 04:26:52 -0000 On Tue, May 02, 2017 at 05:28:39PM -0700, Colm MacC=E1rthaigh wrote: > This whole problem of needing client-side clocks, and having to obfusca= te > an age, goes away if we remove the ticket age entirely. >=20 > Hopefully the security review makes a strong case that the age is fairl= y > useless from a security point of view. Even with the age, an attacker c= an > still generate millions to billions of replays. Even with very conserva= tive > numbers, e.g. to just one host, the attacker can still certainly genera= te > tens of thousands of replays within the permitted window. Better to > require servers to reject duplicates (when used with Zero-RTT), and lea= ve > it at that. It's hard to disagree with this. The only problem is that the caches needed for server-side replay protection are non-trivial to implement, especially with high concurrency, and even more so for clustered services. Nico --=20 From nobody Tue May 2 21:30:32 2017 Return-Path: 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 E4F1E1200F1 for ; Tue, 2 May 2017 21:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 E0Q8jantLKBV for ; Tue, 2 May 2017 21:30:29 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E5B12EAAD for ; Tue, 2 May 2017 21:28:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 7C1F1A00762E; Tue, 2 May 2017 21:28:07 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 3DECBA00762D; Tue, 2 May 2017 21:28:07 -0700 (PDT) Date: Tue, 2 May 2017 23:28:05 -0500 From: Nico Williams To: TLS WG Message-ID: <20170503042804.GP10188@localhost> References: <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz> <803FB95F-3271-407A-B483-5C0C996D3F04@dukhovni.org> <48763856-04CB-4DC3-9A71-126F6EDB4279@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <48763856-04CB-4DC3-9A71-126F6EDB4279@dukhovni.org> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 04:30:31 -0000 On Tue, May 02, 2017 at 11:27:04PM -0400, Viktor Dukhovni wrote: > > On May 2, 2017, at 9:45 PM, Colm MacC=E1rthaigh w= rote: > > I think we have to assume that a replay attempt could come at any tim= e. > > A time based mitigation doesn't work. >=20 > A time-based mitigation does not remove the need for an anti-replay > cache (where a service protocol, supports 0-RTT, but is not idempotent)= . Bingo. There's no need for a replay cache for the 0 payload if it represents an idempotent operation. As long as the server can fall back on a full handshake, all is good. > What I am saying, is that a time-based counter-measure can substantiall= y > reduce the size of the required cache, because out-of-window replays > are rejected. That replay window can be a narrow window around the tim= e > the ticket is first (and never again legitimately) used, rather than th= e > much larger ticket validity interval. I don't believe replay cache size is that big a deal (though it's not nothing). The hard thing is concurrency. > I agree with Nico that additive obfuscation feels like a hack, but am > willing to accept this as somewhat "natural" within the design traditio= n > of TLS. That is... a ringing endorsement of he obfuscation thing! :) Nico --=20 From nobody Tue May 2 21:43:24 2017 Return-Path: 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 18ED6128B4E for ; Tue, 2 May 2017 21:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 9k1UeGTuVyiu for ; Tue, 2 May 2017 21:43:21 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96850129418 for ; Tue, 2 May 2017 21:41:41 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id k11so79540407ywb.1 for ; Tue, 02 May 2017 21:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aalde8G2Cn1NJf9GqwY8B4zYPniq5vh1FK0h+pfYyIU=; b=hgjdFLp+mUeAbvqTyNrgybNSBr8GJEECTvxqK2xpNIqMoL8eoJuNnlK09lBOIP0XpL y4qK2xmn0jMIP5nRE7tHzcSWRLqZKYoGpxFU/D6ekw8u6EtFWLztvbAzAJ8vGBTz5a4b jQ9XPdK2pdFMmc8GSg4QMbyRH7UT8Kp1GsuGOmnH37NkCA/Sz+lDI5gAEXnKAD7nKOqV z+wBm8pXgJyt3na2PrCqk3lmHa8/mFWf1NaffiewlIlEJRMhkXxl9z6J7ITUGfPRyd31 Ut0tyJREQpoBZAd9/O0Hbq2PsgLfUaJk2HqX6gSX2JjvRoZSiz5D92ns8pk+6sAtD+EH DLVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Aalde8G2Cn1NJf9GqwY8B4zYPniq5vh1FK0h+pfYyIU=; b=M3HV6mBs+5K/EvthNoo2K3/iV2MxJhWiiBlPccQDiAUkEapTk12YA3ZbOzsYBPlH9P UQyVM32yBcPhcQJs/FdADckd2t9BztRAhEyF2UxUEok3yhlB6zxku9iqVpFAAXifzpMo 2NbwXhBgmypZWzagaeOns/U0ZQZYZxGzyBoW2ZrwTYcjuGC2kaHTNtWQTNVOaaWq49v8 t632kDhO8sGOptgx3P/st45+U2eILIZNqmJGpcoa14jfWoWJoFfZXUbfm2v7zJWzNzZ3 0qA2Ukf1ZwtMkB12/Pg5HPLRhE1QtvKjXgYc8K7Avej3FMg+U2xp8Vm1grRFE9FXHXTm wl1w== X-Gm-Message-State: AN3rC/5KsV1SGay94MdMwHWOy5zhPsuJ9zubb5tZV9fZpBOJZd5gvlCd lC+b60UpwwM9UercWAfvMsx0U2gYuZW6 X-Received: by 10.129.52.141 with SMTP id b135mr27601930ywa.85.1493786500831; Tue, 02 May 2017 21:41:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 2 May 2017 21:41:00 -0700 (PDT) In-Reply-To: <20170503042227.GN10188@localhost> References: <20170502192003.GH10188@localhost> <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> <20170502212953.GK10188@localhost> <20170502230258.GL10188@localhost> <20170503042227.GN10188@localhost> From: Eric Rescorla Date: Tue, 2 May 2017 21:41:00 -0700 Message-ID: To: Nico Williams Cc: Daniel Kahn Gillmor , TLS WG Content-Type: multipart/alternative; boundary=001a11408984c0cf88054e9745bd Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 04:43:22 -0000 --001a11408984c0cf88054e9745bd Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 9:22 PM, Nico Williams wrote: > On Tue, May 02, 2017 at 04:41:52PM -0700, Eric Rescorla wrote: > > On Tue, May 2, 2017 at 4:02 PM, Nico Williams > wrote: > > > On Tue, May 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote: > > > > It's not XOR. It's addition mod 2^32. That's important because the > > > > *difference* > > > > between the ticket replay times is directly observable anyway. > > > > > > Computationally there's no real difference between that and XOR. > > > > What information do you believe you are gathering here? > > I believe the attack described is finding the time of the session's > establishment. Hmm.... Can you walk me through how you think that works? -Ekr > Nico > -- > --001a11408984c0cf88054e9745bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 9:22 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Tue, May 02, 2017 at 04:41:52PM -0700, Eric Rescorla wrote:
> On Tue, May 2, 2017 at 4:02 PM, Nico Williams <nico@cryptonector.com> wrote:
> > On Tue, May 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote: > > > It's not XOR. It's addition mod 2^32. That's imp= ortant because the
> > > *difference*
> > > between the ticket replay times is directly observable anywa= y.
> >
> > Computationally there's no real difference between that and X= OR.
>
> What information do you believe you are gathering here?

I believe the attack described is finding the time of the session= 9;s
establishment.

Hmm.... Can you walk me thro= ugh how you think that works?

-Ekr
=C2= =A0
=C2=A0
Nico
--

--001a11408984c0cf88054e9745bd-- From nobody Tue May 2 22:34:59 2017 Return-Path: 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 445A7129B5A for ; Tue, 2 May 2017 22:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 UajjgGfBSFEk for ; Tue, 2 May 2017 22:34:56 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B43A12940F for ; Tue, 2 May 2017 22:32:52 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id 203so79817531ywe.0 for ; Tue, 02 May 2017 22:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ndiCDVom8qMsJB3TPqyAJCJZH9OIyZS5yeTBYgxQisI=; b=TyUzlrpgqrThD+dwPzA3E9ebm7Dx7TFEAnEi4JrRCLGKqmZRKPlnFZizheMGmTDmPT 1UqQxNRr0brrLiyQqDuPrPchwjfGEn/xGwBmtsR5IdLPgw/9WVqGfEgzCmWPyDKmCj0/ 331Z6q77zL+HIKWJr41i/yCP/PKtSsc+H0ziBcQNntHV1xSPnu1FfAstgkv0pKYQn+VJ cqenxaaJskDxmsMIFeEgXXKuYiy0dE8haWHhFAyWOODXN1Ww37fc7Fbn0LPSxFU7uXtR vHoOBCi7cops+4O7BUVOCDmWtNhdgBlRpbtMeQizhJI8av3hQQME73I0Ag3EE17RuogN SI5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ndiCDVom8qMsJB3TPqyAJCJZH9OIyZS5yeTBYgxQisI=; b=uA8GuXG7dPaCif6BoxdibdHdmPcHQZ6d+zewROTRdqsJUbJkM+wT1Fg6UtT5PqOyt9 6J1pe7OGpwGstkSWy9RVfrbpcS880eiL0AK7Lb3W1ydhCeTVWh538W7Qey1YLe25OOjS YA88zMaG51tMu0Fj7UYTyxSBZkE8owPfwnJkT7jUma8UjZ50NZ2x8Rn5GcSDGZ94/Fpl QFcGCZf/2Dj4IYWldxDpYybl620VPPchnQwILtvYgHGKX+JpJVEfw6wGZThCP1m5f+SX 1OnZ/32XfhNjztVsc1o2Hf7nL+4Sy/k2O+gWDT8f1m6XBsfDkvqIz102w9XS+55r4Vus XufA== X-Gm-Message-State: AN3rC/75N65TNbJapCpU/iaSFRTLzHfkZO+4oKJuMVjAh9Vvk1i/xLgG uWm15xFQuZWMagE1BWpIMp7HPoSDCf44 X-Received: by 10.129.53.207 with SMTP id c198mr30351366ywa.14.1493789571660; Tue, 02 May 2017 22:32:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 22:32:50 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 2 May 2017 22:32:50 -0700 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1142e7ecc9d950054e97fcb4 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 05:34:58 -0000 --001a1142e7ecc9d950054e97fcb4 Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 8:17 PM, Eric Rescorla wrote: > Colm, > > Thanks for your review. Interesting stuff. > Thanks too for taking the time to read it. > Scrolling ahead to the recommendations, I see you have: > > * Require implementations to robustly prevent Ticket re-use for 0-RTT. > > This seems like a good idea. I think it's arguable that we got a bit > nihilistic about this, and as you say, you can do a pretty good job of > reducing replay within a given data center using some local > anti-replay mechanism. I would tend to think that a strong SHOULD is > what you want here, as a MUST is going to be a lot more like a 6919 > MUST (BUT WE KNOW YOU WON'T). > A provider choosing to allow replays to their own applications is on them, they can own the stack top to bottom, take the risk, have a response team handle attack events, etc ... That's a legitimate case for "SHOULD", there are exceptions to everything. But at the same time, what I think we should care most about is the interoperability case. So for example, if a TLS library, a web server, or an upstream CDN, can break the assumptions of a down-stream service or application, that's where we'll see CVEs cropping up. In those cases, I think the problem is the upstream component, breaking long-held and fair assumptions. In those cases, it feels like a "MUST". I'm not sure how to strike a balance, so chose the more secure option. > I understand from your document and our previous conversation that you > believe single-use tokens are easier to implement on the server side, > but I'm not sure I really follow your argument. If you want to provide > some short text on that that we can all agree on, then I think we > could incorporate this as well. > It's probably not important to get into a single-use token cache in the draft itself. That was just intended for implementors. One thing that makes a single-use cache slightly easier to implement is that reads and writes to keys need not be sequenced relative to any kind of checkpoint. With a strike register, some kind of checkpoint process is needed. A simple one is to start with a clean slate, accept only writes for a time period equivalent to the replay window, and then go read-write. But that kind of modality is, I think, required. With a single-use cache, it need only sequence the reads and writes to individual keys. Though it must store much much more state, so there are different trade-offs to consider. > * Partial mitigation for Gilmor attacks: deliberately duplicate 0-RTT > data > > This seems like some sort of extra-grease, but I'm kinda skeptical > that anyone is going to do it. Perhaps it would be useful to add it to > draft-ietf-tls-grease? > Grease is a good place for it for sure. > * Require TLS proxies to operate 0-RTT transitively > > I've read this several times but I have to admit I don't understand > it. Do you think you could rephrase? > What's in the draft is that there should be an application profile and that TLS implementations should provide applications with special functions to tell apart the early and regular data. The problem is that doesn't work with TLS proxies (like CDNs) ... because the proxies are re-combulating the data as a single stream to the origin. So the origin can't tell which data was replayable. If 0-RTT replay is tolerated, I think that's a big gnarly problem leading to CVEs. If we prevent replay by other means, like the strike register, it's not so big a deal. What I was suggesting was that such proxies always send an outgoing 0-RTT section to the origin that exactly lines up with the 0-RTT section that came in on the front end. It's quite hard to make that all work; the CDN would have to accept 0-RTT only if the origin also does. But I can't see another way that really works, especially for Layer 4 accelerators. Again, if 0-RTT replay is forbidden, not nearly as big a deal. > The following doesn't appear in your recommendations, but I think you > also think we should: > > * Adopt something like PR#998 to make each PSK_id correspond to a > different PSK even when they are issued on the same connection. > Big +1 to this. > For the reasons Viktor indicated, I tend to think this is inadvisable. > I've been thinking more about this. What if tickets are single-use when used with 0-RTT, but otherwise allowed for multiple uses? If that's acceptable, then could we drop the age from tickets purely used for resumption. That way the age would only appear on tickets that are used once. I think that way we get everything. * Remove ticket_age > > This doesn't seem like a good idea: if you are implementing a strike > register, you want to use ticket_age to help distinguish "fresh" from > "unknown state". I.e., the ticket_age + the ticket issue time allows > you to determine approximately when a CH was sent, and any CH that > is significantly older or newer than now is forced back into 1-RTT. > Yep, I was wrong about this, I get it now, and that makes sense. -- Colm --001a1142e7ecc9d950054e97fcb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 2, 2017 at 8:17 PM, Eric Rescorla <ekr@rtfm.com> = wrote:
Colm,

=
Thanks for your review. Interesting stuff.

Thanks too for taking the time to read it.
=C2= =A0
Scrolling ahead to the reco= mmendations, I see you have:

* Require implementat= ions to robustly prevent Ticket re-use for 0-RTT.

= This seems like a good idea. I think it's arguable that we got a bit
nihilistic about this, and as you say, you can do a pretty good job= of
reducing replay within a given data center using some local
anti-replay mechanism. I would tend to think that a strong SHOULD = is
what you want here, as a MUST is going to be a lot more like a= 6919
MUST (BUT WE KNOW YOU WON'T).
=

A provider choosing to allow replays to their own appli= cations is on them, they can own the stack top to bottom, take the risk, ha= ve a response team handle attack events, etc ... That's a legitimate ca= se for "SHOULD", there are exceptions to everything.=C2=A0
<= div>
But at the same time, what I think we should care most a= bout is the interoperability case. So for example, if a TLS library, a web = server, or an upstream CDN, can break the assumptions of a down-stream serv= ice or application, that's where we'll see CVEs cropping up. In tho= se cases, I think the problem is the upstream component, breaking long-held= and fair assumptions. In those cases, it feels like a "MUST".=C2= =A0

I'm not sure how to strike a balance, so c= hose the more secure option.=C2=A0
=C2=A0
=
I understand from your document and our previous conv= ersation that you
believe single-use tokens are easier to impleme= nt on the server side,
but I'm not sure I really follow your = argument. If you want to provide
some short text on that that we = can all agree on, then I think we
could incorporate this as well.=

It's probably not importan= t to get into a single-use token cache in the draft itself. That was just i= ntended for implementors. One thing that makes a single-use cache slightly = easier to implement is that reads and writes to keys need not be sequenced = relative to any kind of checkpoint.=C2=A0

With a s= trike register, some kind of checkpoint process is needed. A simple one is = to start with a clean slate, accept only writes for a time period equivalen= t to the replay window, and then go read-write. But that kind of modality i= s, I think, required. With a single-use cache, it need only sequence the re= ads and writes to individual keys. Though it must store much much more stat= e, so there are different trade-offs to consider.=C2=A0
=C2=A0
* Partial mitigation for Gilmor a= ttacks: deliberately duplicate 0-RTT
=C2=A0 data

This seems like some sort of extra-grease, but I'm kinda skept= ical
that anyone is going to do it. Perhaps it would be useful to= add it to
draft-ietf-tls-grease?
Grease is a good place for it for sure.=C2=A0
=C2=A0= =C2=A0
* Require TLS proxies to= operate 0-RTT transitively

I've read this sev= eral times but I have to admit I don't understand
it. Do you = think you could rephrase?

What&= #39;s in the draft is that there should be an application profile and that = TLS implementations should provide applications with special functions to t= ell apart the early and regular data. The problem is that doesn't work = with TLS proxies (like CDNs) ... because the proxies are re-combulating the= data as a single stream to the origin. So the origin can't tell which = data was replayable.=C2=A0

If 0-RTT replay is tole= rated, I think that's a big gnarly problem leading to CVEs. If we preve= nt replay by other means, like the strike register, it's not so big a d= eal.

What I was suggesting was that such proxies a= lways send an outgoing 0-RTT section to the origin that exactly lines up wi= th the 0-RTT section that came in on the front end. It's quite hard to = make that all work; the CDN would have to accept 0-RTT only if the origin a= lso does. But I can't see another way that really works, especially for= Layer 4 accelerators. Again, if 0-RTT replay is forbidden, not nearly as b= ig a deal.=C2=A0


The following doesn't appear in your recommendations, b= ut I think you
also think we should:

* A= dopt something like PR#998 to make each PSK_id correspond to a
= =C2=A0 different PSK even when they are issued on the same connection.

Big +1 to this.
=C2=A0
For the reasons Viktor indicated,= I tend to think this is inadvisable.

I've been thinking more about this. What if tickets are single-u= se when used with 0-RTT, but otherwise allowed for multiple uses? If that&#= 39;s acceptable, then could we drop the age from tickets purely used for re= sumption. That way the age would only appear on tickets that are used once.= =C2=A0

I think that way we get everything.=C2=A0

* Remove ticket_a= ge

This doesn't seem like a good idea: if you = are implementing a strike
register, you want to use ticket_age to= help distinguish "fresh" from
"unknown state"= ;. I.e., the ticket_age + the ticket issue time allows
you to det= ermine approximately when a CH was sent, and any CH that
is signi= ficantly older or newer than now is forced back into 1-RTT.

Yep, I was wrong about this, I get it now, and= that makes sense.=C2=A0

--
Colm
--001a1142e7ecc9d950054e97fcb4-- From nobody Wed May 3 00:05:20 2017 Return-Path: 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 3CC3E12951F for ; Wed, 3 May 2017 00:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LkHLhxXt-xyq for ; Wed, 3 May 2017 00:05:18 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC186129549 for ; Wed, 3 May 2017 00:03:03 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id u65so135744753wmu.1 for ; Wed, 03 May 2017 00:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1PVug8daZg6ku3parucry8cc2T584zzs73hUzV57iRU=; b=hkAXemfIvYCgFGcwmDx5bvu/orZnWHV8YBNwQrlVc6ruwLhBT7723mBTZQUkekKU4l fe6V8uw8CvIGDfb8euTtRpBOBqS+2agSTva/zeMSnqvH5poHg25CGxAsJ5EKb8wRMzpH xH+0a8s1xKpCq2Ft1jmV2KyHS3GWKQrZqERtuU4JjXfLsDb7Qq6BAOi5mngagaJv0DZG iWR0hfvaEZb2yxmAGpIe77u9OHQlkj4c+VLkL0N0OJvTo+bC/cN5dG0ghQs13oUQam74 hYT2xH8+CP4Xj5KFMJg7R2/irBG+ez6rIuM4C1JoQ3xLpNUOk/sSai4FTAiPAYBq6Hov GuIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1PVug8daZg6ku3parucry8cc2T584zzs73hUzV57iRU=; b=X0y/UFLJHhp9Uh/ea/gpC3nygTKBbRI52o+FTqUrcV6gOEBU8W0gr7f8KxPynpVHkL KNXoKwalc8IXuh4VJx1zf83MpV0pi0QPqnbJ8EfSh0UH5FXvSNtGpwPcaIVtvDL7ETtb zR2SvpcGHyMIREI+xRSoXLs5qbiaNpPC3mrHzl67O9IkZpdMCZxSKkNRQPp8zQuXDphC Tw8vg+mCB/DR0f3QY2F55iQLCye82w5Mu5iljI1hv0nGoDqhF5kBK0esEoPf8VzEgMDL aEn2ckTcgg3pLaIsvk5ufhWyAdN5xgwVCQ8Xc5Ml8ShTb4PJ4TgrvLQAuFbBxIwRDkka Tu/Q== X-Gm-Message-State: AN3rC/7cZC5fGCaJEF69UHYY91KKRoX03dj6DvzkrcTHkmc+pEH3e9OJ /wi4d9ixvwdwOtHLZmfz87zkGPDUMI16 X-Received: by 10.25.213.130 with SMTP id m124mr11187992lfg.50.1493794982386; Wed, 03 May 2017 00:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 00:03:01 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 3 May 2017 17:03:01 +1000 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 07:05:19 -0000 On 3 May 2017 at 15:32, Colm MacC=C3=A1rthaigh wrote: > I've been thinking more about this. What if tickets are single-use when u= sed > with 0-RTT, but otherwise allowed for multiple uses? If that's acceptable= , > then could we drop the age from tickets purely used for resumption. That = way > the age would only appear on tickets that are used once. I could see the way to moving the ticket age to the early_data extension. It saves a few bytes in an uncommon case, complicates a bit of the design, but otherwise isn't overly disruptive. From nobody Wed May 3 02:17:54 2017 Return-Path: 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 1189312941C for ; Wed, 3 May 2017 02:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 ieUz_0MfRuLD for ; Wed, 3 May 2017 02:17:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF6E12943C for ; Wed, 3 May 2017 02:15:07 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LlESk-1dgXyJ10VC-00b1JM; Wed, 03 May 2017 11:15:05 +0200 To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "tls@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 3 May 2017 11:15:03 +0200 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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BCNt5k9BiMNIiFinQE5PRFO8w6bgXDsT7" X-Provags-ID: V03:K0:apQQaNFlKm7oyDj29i3eMKmchSlrh2ZrB6dmNlJFGBR+lztnEo8 JoK/gmoafXcDlvddyxxkQ71CQjgAoqgPUFr6pPogGhDv7w/CUwTYQ9N4QZZ3VsWfBGacj1Z ++8ld7i6sjZ8LaH+txMDb4NadV3bFBbvSEd+tWfzanNuYAuC5myCXcyupt/y0Vv1mHl2mkO sMuqZScBjcQiHaQs4FVMQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0G1nvrqWc7w=:9reI+hUO8fp6IQed1YRoxS qYJHRngofkBBCCCh0u74xKfkpARAQ1T4UR5/zZYp+2ZZ4hBB3QfwD0niqaRqrs9/QgL6Q1UTX CX4ADH6VXM/4GigXmJyQR3AjsvY1pCRqWdjvyYoLSGXCE+PMiWgsLFsp4Q7OMNBsQ6YiNoBSy t8N2jy7Mxjh+UTvQJ5OAL3jJY/TLE3OWhm2q4WZ53W2tV+PWENhdNw2+5YFaVD+JrX+M3NtOK zaB+JW3e+mUfQF7R0dVXP+CDMwJjjwPusSHuLVCBQgmTVCZoUj8TrYNDp4FkWGEx3kTp6mjRS MRKovFW0F3xVrnsXwG8mA1tUvSpQUrPoJL2KABypV77QcWXXVwrC9nW8I/Mia7ldD2PPYrO+6 FwD3StGvhtfSdEYhiREySw9NsoUjV4rjLoZyPeVwaA74yeRnFubcwA17HUdj6qMIa/cEw5Lxa 8juGPS5waJpxK53al8geoYFHcVhO/suky2cia/ZaeruhU82lq4gS7+UmZHt05Lj80l4xYIVeC RH+rV1/2wxDEYWx8Pyuv2R7BH5yoxc6cZMYVZ1aXFbbZQ0rA+9+TC/Ef3EET2JJyrdnbCZU8B S4mAEIJshT0FsImWRtn1k3rV5PEjhKcB7BmP07mZV6GN7NgZ3d1ApYpNeTp6VAVrBD1CFhSZr oMIK7TQCctaMKXf1GGv/90Buel67G/kM3rJ5CKbmaWlxAPIZ+Z6CR6fyYM4k5nVT9avOHqsMJ IKfVUH5bcsPSyHhRBRebFfUL5u+8x9UMt7+hz8YmQQZ0LzcPlNmCQ3urDV0= Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 09:17:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BCNt5k9BiMNIiFinQE5PRFO8w6bgXDsT7 Content-Type: multipart/mixed; boundary="NSBdGCi9XODUcUEoPj43g668Jb06N1BBm"; protected-headers="v1" From: Hannes Tschofenig To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Security review of TLS1.3 0-RTT References: In-Reply-To: --NSBdGCi9XODUcUEoPj43g668Jb06N1BBm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Colm, thanks for your review. I disagree with your assessment in a few places. First, talk about tickets and point out that distributing the session key for encrypting the ticket content (Session Ticket Encryption Keys (STEKs)) is a challenge and raises security concerns. You point to Akamai CDN and their huge number of hosts. The TLS 1.3 ticket concept combines three types of tickets approaches standardized for earlier versions of TLS, namely session resumption (which caches keys on both sides), and RFC 5077, which allows you to use self-contained tokens aka tickets in the style of Kerberos tickets. Finally, you could use RFC 5077 with references to tickets but you loose the stateless nature (since you have to write keys, and other necessary parameters in a database). Which approach is best depends on your infrastructure. When you use TLS in your environment you need to make a few decisions about the algorithms you want to support, key lengths, etc. You also have to determine what ticket concept you want. Maybe the right decision for a deployment that has to synchronize STEKs across so many hosts isn't a great idea. Second, you talk about 0-RTT and replay attacks. In a 0-RTT exchange you cannot rely on the nonce exchange for replay protection (as it was done in earlier TLS versions). Instead, you have to rely on other replay protection mechanisms, and taking the application semantic into account is obvious approach. Clearly 0-RTT is not applicable to all environments and hence the spec contains a warning: "Protocols MUST NOT use 0-RTT data without a profile that defines its use." What I could, however, imagine is to add either in the TLS handshake or at the application layer something like a timestamp or a sequence number so that the server-side can check for replays. This is what has been done with other security protocols in the past. Is the TLS layer the right place or the application layer? Hard to say. Minor issues: You also suggest that 0-RTT supports PFS. The definition of PFS unfortunately is not super helpful here when there are so many keys in play. The PFS definition talks about the loss of the long-term key. What you care about is the potential loss of the STEKs, which is not a long-term key. You write: "Any client that attempts to use a ticket multiple times will also likely leak the obfuscated_ticket_age value, which is intended to be secret." The obfuscated_ticket_age is not secret - it is sent in the clear. What is supposed to be kept confidential is the ticket age. I have been wondering myself what the privacy value of the obfuscated_ticket_age, and the ticket age is and I am still not convinced that it provides much benefit. Ciao Hannes PS: You talk about OATH in this paragraph: " To avoid simple spoofing risks, many such systems perform throttling post-authentication. For example the request may be signed cryptographically (see the AWS SIGv4 signing protocol or the OATH signing process), that signature is verified prior to throttling. This post-authentication property is one reason why such protocols are designed to be extremely fast to verify, which often means as much cryptography as possible must be pre-computed, making random nonces infeasible in many cases. " What you actually mean is OAuth (OATH is a different effort also related to earlier IETF work on one-time-passwords). Your reference points to an old OAuth specification that has been replaced by OAuth 2.0, which does not use the same application layer signing anymore. On 05/02/2017 04:44 PM, Colm MacC=E1rthaigh wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of = a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in > s2n. Thanks to feedback in the room I've now tightened up the findings > from the review and posted them as an issue on the draft GitHub repo: >=20 > https://github.com/tlswg/tls13-spec/issues/1001 >=20 > I'll summarize the summary: Naturally the focus was on forward secrecy > and replay. On forward secrecy the main finding was that it's not > necessary to trade off Forward Secrecy and 0-RTT. A single-use session > cache can provide it, and with the modification that ekr has created > in https://github.com/tlswg/tls13-spec/pull/998 > , such a cache works for= > both pre-auth and post-auth tickets, and it allows clients to build up > pools of meaningfully distinct tickets. >=20 > There's also an observation there that it should really be that clients= > "MUST" use tickets only once. Any re-use likely discloses the obfuscate= d > ticket age, which is intended to be secret. Right now it's a "SHOULD". = >=20 > On replay, the main finding is that what's in the draft is not workably= > secure, and the review includes 5 different attacks against 0-RTT data > to illustrate that. Attacks 1 and 2 show that the kind of replay > permitted by the draft is very different from the kind of replay > permitted by dkg's existing downgrade-and-retry attack. I also go over > why it very very difficult to many applications to achieve that > idempotency, and why one idempotency pattern actually relies on > non-replayable messages.=20 >=20 > Attack 3 shows that idempotency is not sufficient, applications must > also be free of measurable side-effects, which is not practical. Attac= k > 4 shows that 0-RTT breaks a common security mechanism: > spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability > enables an additional form of traffic analysis.=20 >=20 > The recommendation in the review is that implementations "MUST" prevent= > replays of 0-RTT section, with some additional discussion about why the= > existing advice is unlikely to be followed, and why consistent > interoperability matters here.=20 >=20 > Unfortunately, I wasn't aware until Friday that this review would be > coming so late in the TLD1.3 draft process, and my apologies for that. = I > am now planning to attend the future WG in-person meetings and look > forward to seeing many of you there.=20 >=20 > --=20 > Colm >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --NSBdGCi9XODUcUEoPj43g668Jb06N1BBm-- --BCNt5k9BiMNIiFinQE5PRFO8w6bgXDsT7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZCZ+XAAoJEGhJURNOOiAtJ6cIAIQ0us26zGZNQ9xc5RYDUuSV m1C4MVc5OxmoakrSzubl2x83Aolxd+gt8jtfVF4tNj8JBhl654QTPfAQtBOmm3bu 9PgpLMkE7zOpMQOfdybcQBsX+bsJ9vvRnfkXjlNviKSW5zl0EtVtP6VDW8BWZDod 8dRcqnlE6AgG8kBC+AxHl8+6nBoyL07FSJKxCxWWdhMGSxJm/Yt0mrib5d/zEipi KGyUHHB6skxrSP11y8UX1f7LcIyC12MT4flAQB0Z5xKT4EM0Ag4CL3/QCVQjh6wb M3ouuTTv63Oodq37F48AlI0gub+2pOlWC9IYzm4leBTzy/sIX56VI8LhMVpJ91I= =d2hE -----END PGP SIGNATURE----- --BCNt5k9BiMNIiFinQE5PRFO8w6bgXDsT7-- From nobody Wed May 3 05:48:02 2017 Return-Path: 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 0A96412948E for ; Wed, 3 May 2017 05:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 QuF9Uhs8RtM1 for ; Wed, 3 May 2017 05:47:57 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247A912948A for ; Wed, 3 May 2017 05:45:18 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id k11so83952058ywb.1 for ; Wed, 03 May 2017 05:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NDLsSZ7+6AmDtFWMUz5F7ADNWjrxVjznMvcaG41Olyg=; b=19hqKWsRytl36UhcdBgohlZXHvHQ6cuxFsTSI1GXQNI1SYWWyZQC1aROB+VRLR2JNh EbsdHXd7jFe4F1Fk5VFB8X78Ftpij1KASMBdzUP6/ZKDA1ffc72lbPJmyp/rHEegfNZi CZ7tLUYQ93M8LxbYoh5bEXaXh69jv9BS5LqJ7NW56B2yYODbT1B/xlvrcTF7uv0saTDf gPDcBUpDuoHUC7w5iL3w0wA6frlOW3Ao8Gt037DuylsfyGaQC/zX/HGPn/fX7/2F+2iG 47ii1DWNSpmFJuTn9xhud6h2fvRTESpfWNSXJIS3hncCkpuZYuGmkh5pEJLARwre9Smd n1/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NDLsSZ7+6AmDtFWMUz5F7ADNWjrxVjznMvcaG41Olyg=; b=S91a+s+4w8+BFPA/MkcSl9cgN866arkp+wZCbkyU8qgDPt/f5X+DpReTpHoVsZW6rS ijthT57SgJ9du5VWlUWP7cOYuat62hImsTZjBG5fpL2tvR1GEnyoWS9b1lvHcq146bvP kop5vE58XTD0JSeVWlqQiK3jCfQ5AK3madGmInspWuty/+st32kyVjHJQlR4stzFMqu/ jVLg90juLb/k4WzoYFzRs6B00RV8SGNyWvcLKMqhPNEumzTf6bCtAgw+jkunFFf6af8h g5kxBPzpb7pl7Ct0yD4Boe+DsY+usXBJGy6J9d4G3QtGME+dbpygkdz06Ojx679eRt/G XS6Q== X-Gm-Message-State: AN3rC/7L/8eLsnxPBuR6AWh7Qxi3JoafuqWjw/sL8DE1ufgIDHG9FVfE x+KhrPIkQ1uVmiDDktJf+OeNRsoaSLla4Fs= X-Received: by 10.129.152.4 with SMTP id p4mr28804629ywg.1.1493815517284; Wed, 03 May 2017 05:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 05:45:16 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 05:45:16 -0700 Message-ID: To: Hannes Tschofenig Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0bd9ee44afcb054e9e07cd Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 12:48:00 -0000 --94eb2c0bd9ee44afcb054e9e07cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 2:15 AM, Hannes Tschofenig wrote: > > First, talk about tickets and point out that distributing the session > key for encrypting the ticket content (Session Ticket Encryption Keys > (STEKs)) is a challenge and raises security concerns. You point to > Akamai CDN and their huge number of hosts. > I used Akamai as a reference as they are probably the worlds largest deployment of TLS, measured by hosts. But to be clear; Akamai has always done great work on securing keys and I know it's something they take very seriously. > Which approach is best depends on your infrastructure. > Here I want to be more opinionated than that. I think that forward secrecy is important and is more secure, and should always be provided. Its absence is a security issue, so it's appropriate to highly in a security review. It's possible in all cases, as shown, and the trade-off is unnecessary from first principles. The fundamental problem with STEKs is that there is no forward secrecy, and in the case of TLS1.3, no FS for critical data. It's an unfortunate alignment, as it really undoes a lot of the collective good work to deploy PFS in practice. Deploying the PFS cipher suites took nudging providers along; and was not without cost. I think the same thing may happen with STEKs in the not-too-distant future. People seem to care about getting forward secrecy. Smart customers with particularly sensitive workloads will insist. What I could, however, imagine is to add either in the TLS handshake or > at the application layer something like a timestamp or a sequence number > so that the server-side can check for replays. This is what has been > done with other security protocols in the past. Is the TLS layer the > right place or the application layer? Hard to say. > This is easy to say; the TLS layer is the right place. It is not practical for applications to defend themselves, especially from timing attacks. You also suggest that 0-RTT supports PFS. The definition of PFS > unfortunately is not super helpful here when there are so many keys in > play. The PFS definition talks about the loss of the long-term key. What > you care about is the potential loss of the STEKs, which is not a > long-term key. > As the crypto-shortcuts paper showed, in some cases servers had STEKs in place for the duration of the experiment (months) and perhaps years. > You write: "Any client that attempts to use a ticket multiple times will > also likely leak the obfuscated_ticket_age value, which is intended to > be secret." The obfuscated_ticket_age is not secret - it is sent in the > clear. What is supposed to be kept confidential is the ticket age. I have been wondering myself what the privacy value of the > obfuscated_ticket_age, and the ticket age is and I am still not > convinced that it provides much benefit. > Sorry, you're right, it's the ticket_age_add which should remain secret. My understanding is that as NewSesstionTickets messages occur post-handshake, that they are encrypted under the session keys, and that value is secret. > > Ciao > Hannes > > PS: You talk about OATH in this paragraph: > > " > To avoid simple spoofing risks, many such systems perform throttling > post-authentication. For example the request may be signed > cryptographically (see the AWS SIGv4 signing protocol or the OATH > signing process), that signature is verified prior to throttling. This > post-authentication property is one reason why such protocols are > designed to be extremely fast to verify, which often means as much > cryptography as possible must be pre-computed, making random nonces > infeasible in many cases. > " > > What you actually mean is OAuth (OATH is a different effort also related > to earlier IETF work on one-time-passwords). Your reference points to an > old OAuth specification that has been replaced by OAuth 2.0, which does > not use the same application layer signing anymore. > Thanks for letting me know! > > On 05/02/2017 04:44 PM, Colm MacC=C3=A1rthaigh wrote: > > On Sunday at the TLS:DIV workshop I presented a summary of findings of = a > > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in > > s2n. Thanks to feedback in the room I've now tightened up the findings > > from the review and posted them as an issue on the draft GitHub repo: > > > > https://github.com/tlswg/tls13-spec/issues/1001 > > > > I'll summarize the summary: Naturally the focus was on forward secrecy > > and replay. On forward secrecy the main finding was that it's not > > necessary to trade off Forward Secrecy and 0-RTT. A single-use session > > cache can provide it, and with the modification that ekr has created > > in https://github.com/tlswg/tls13-spec/pull/998 > > , such a cache works for > > both pre-auth and post-auth tickets, and it allows clients to build up > > pools of meaningfully distinct tickets. > > > > There's also an observation there that it should really be that clients > > "MUST" use tickets only once. Any re-use likely discloses the obfuscate= d > > ticket age, which is intended to be secret. Right now it's a "SHOULD". > > > > On replay, the main finding is that what's in the draft is not workably > > secure, and the review includes 5 different attacks against 0-RTT data > > to illustrate that. Attacks 1 and 2 show that the kind of replay > > permitted by the draft is very different from the kind of replay > > permitted by dkg's existing downgrade-and-retry attack. I also go over > > why it very very difficult to many applications to achieve that > > idempotency, and why one idempotency pattern actually relies on > > non-replayable messages. > > > > Attack 3 shows that idempotency is not sufficient, applications must > > also be free of measurable side-effects, which is not practical. Attac= k > > 4 shows that 0-RTT breaks a common security mechanism: > > spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability > > enables an additional form of traffic analysis. > > > > The recommendation in the review is that implementations "MUST" prevent > > replays of 0-RTT section, with some additional discussion about why the > > existing advice is unlikely to be followed, and why consistent > > interoperability matters here. > > > > Unfortunately, I wasn't aware until Friday that this review would be > > coming so late in the TLD1.3 draft process, and my apologies for that. = I > > am now planning to attend the future WG in-person meetings and look > > forward to seeing many of you there. > > > > -- > > Colm > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --=20 Colm --94eb2c0bd9ee44afcb054e9e07cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 2:15 AM, Hannes Tschofenig <= ;hannes.tsch= ofenig@gmx.net> wrote:
First, talk about tickets and point out that distributing the session
key for encrypting the ticket content (Session Ticket Encryption Keys
(STEKs)) is a challenge and raises security concerns. You point to
Akamai CDN and their huge number of hosts.

<= div>I used Akamai as a reference as they are probably the worlds largest de= ployment of TLS, measured by hosts. But to be clear; Akamai has always done= great work on securing keys and I know it's something they take very s= eriously.=C2=A0
=C2=A0=C2=A0
Which approach is best depends on your infrastructure.

Here I want to be more opinionated than that. I think that = forward secrecy is important and is more secure, and should always be provi= ded. Its absence is a security issue, so it's appropriate to highly in = a security review. It's possible in all cases, as shown, and the trade-= off is unnecessary from first principles.=C2=A0

Th= e fundamental problem with STEKs is that there is no forward secrecy, and i= n the case of TLS1.3, no FS for critical data. It's an unfortunate alig= nment, as it really undoes a lot of the collective good work to deploy PFS = in practice.=C2=A0

Deploying the PFS cipher su= ites took nudging providers along; and was not without cost. I think the sa= me thing may happen with STEKs in the not-too-distant future. People seem t= o care about getting forward secrecy. Smart customers with particularly sen= sitive workloads will insist.

What I could, however, imagine is to add either in the TLS handshake or
at the application layer something like a timestamp or a sequence number so that the server-side can check for replays. This is what has been
done with other security protocols in the past. Is the TLS layer the
right place or the application layer? Hard to say.
This is easy to say; the TLS layer is the right place. It is no= t practical for applications to defend themselves, especially from timing a= ttacks.=C2=A0

You also suggest that 0-RTT supports PFS. The definition of PFS
unfortunately is not super helpful here when there are so many keys in
play. The PFS definition talks about the loss of the long-term key. What you care about is the potential loss of the STEKs, which is not a
long-term key.

As the crypto-shortcuts = paper showed, in some cases servers had STEKs in place for the duration of = the experiment (months) and perhaps years.=C2=A0
=C2=A0
You write: "Any client that attempts to use a ticket mult= iple times will
also likely leak the obfuscated_ticket_age value, which is intended to
be secret." The obfuscated_ticket_age is not secret - it is sent in th= e
clear. What is supposed to be kept confidential is the ticket age. I
have been wondering myself what the privacy value of the
obfuscated_ticket_age, and the ticket age is and I am still not
convinced that it provides much benefit.

Sorry, you're right, it's the=C2=A0ticket_age_add=C2=A0which should = remain secret.=C2=A0M= y understanding is that as NewSesstionTickets messages occur post-handshake= , that they are encrypted under the session keys, and that value is secret.= =C2=A0
=C2=A0
=C2=A0

Ciao
Hannes

PS: You talk about OATH in this paragraph:

"
To avoid simple spoofing risks, many such systems perform throttling
post-authentication. For example the request may be signed
cryptographically (see the AWS SIGv4 signing protocol or the OATH
signing process), that signature is verified prior to throttling. This
post-authentication property is one reason why such protocols are
designed to be extremely fast to verify, which often means as much
cryptography as possible must be pre-computed, making random nonces
infeasible in many cases.
"

What you actually mean is OAuth (OATH is a different effort also related to earlier IETF work on one-time-passwords). Your reference points to an old OAuth specification that has been replaced by OAuth 2.0, which does
not use the same application layer signing anymore.
Thanks for letting me know!
=C2=A0

On 05/02/2017 04:44 PM, Colm MacC=C3=A1rthaigh wrote:
> On Sunday at the TLS:DIV workshop I presented a summary of findings of= a
> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in=
> s2n. Thanks to feedback in the room I've now tightened up the find= ings
> from the review and posted them as an issue on the draft GitHub repo:<= br> >
> https://github.com/tlswg/tls13-spec/issues/= 1001
>
> I'll summarize the summary: Naturally the focus was on forward sec= recy
> and replay. On forward secrecy the main finding was that it's not<= br> > necessary to trade off Forward Secrecy and 0-RTT. A single-use session=
> cache can provide it, and with the modification that ekr has created > in https://github.com/tlswg/tls13-spec/pull/99= 8
> <https://github.com/tlswg/tls13-spec/pull/9= 98> , such a cache works for
> both pre-auth and post-auth tickets, and it allows clients to build up=
> pools of meaningfully distinct tickets.
>
> There's also an observation there that it should really be that cl= ients
> "MUST" use tickets only once. Any re-use likely discloses th= e obfuscated
> ticket age, which is intended to be secret. Right now it's a "= ;SHOULD".
>
> On replay, the main finding is that what's in the draft is not wor= kably
> secure, and the review includes 5 different attacks against 0-RTT data=
> to illustrate that. Attacks 1 and 2 show that the kind of replay
> permitted by the draft is very different from the kind of replay
> permitted by dkg's existing downgrade-and-retry attack. I also go = over
> why it very very difficult to many applications to achieve that
> idempotency, and why one idempotency pattern actually relies on
> non-replayable messages.
>
> Attack 3 shows that idempotency is not sufficient, applications must > also be free of measurable side-effects, which is not practical.=C2=A0= Attack
> 4 shows that 0-RTT breaks a common security mechanism:
> spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability=
> enables an additional form of traffic analysis.
>
> The recommendation in the review is that implementations "MUST&qu= ot; prevent
> replays of 0-RTT section, with some additional discussion about why th= e
> existing advice is unlikely to be followed, and why consistent
> interoperability matters here.
>
> Unfortunately, I wasn't aware until Friday that this review would = be
> coming so late in the TLD1.3 draft process, and my apologies for that.= I
> am now planning to attend the future WG in-person meetings and look > forward to seeing many of you there.
>
> --
> Colm
>
>
> ______= _________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>




--
=
Colm
--94eb2c0bd9ee44afcb054e9e07cd-- From nobody Wed May 3 06:10:14 2017 Return-Path: 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 1985E12441E for ; Wed, 3 May 2017 06:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 UXGvIn7M7j7X for ; Wed, 3 May 2017 06:10:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC591129400 for ; Wed, 3 May 2017 06:07:18 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0755F7A32F1 for ; Wed, 3 May 2017 13:07:17 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 09:07:16 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:10:13 -0000 > On May 3, 2017, at 8:45 AM, Colm MacC=C3=A1rthaigh = wrote: >=20 > The fundamental problem with STEKs is that there is no forward secrecy Sorry, STEKs are not long-term keys. So it makes little sense to claim that use of STEKs breaks forward secrecy. Indeed STEKs may be more safe than server-side storage of complete sessions, since the latter are much more likely to end up on disk. It is a shared meme that session tickets break forward secrecy, but it = is not correct. Poorly implemented session ticket keys can be a problem, = but so can poorly implemented session caches. The distributed single-use caches you are imagining are very complex = beasts, and I am much less inclined to trust those than a comparatively simple = key rollover system (just three keys need to be known at any time, the past = key for as yet unexpired sessions, the current key used to mint and decrypt new sessions and the future key created shortly before the current key = becomes the past key, giving enough time for all the cluster nodes to get a = copy). The time window for session compromise is never zero, after all, the = keys are in memory while the connection is active. It is unwise to insist = that forward-secrecy is broken if session keys are not destroyed = instantaneously at session closure. A reasonably short non-zero window of exposure may = yield greater security benefit than a design which appears to be more secure = by attempting synchronous destruction of keys at much greater overall = design complexity. --=20 --=20 Viktor. From nobody Wed May 3 08:24:37 2017 Return-Path: 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 57BA31200E5 for ; Wed, 3 May 2017 08:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 9EW-We6QanWI for ; Wed, 3 May 2017 08:24:34 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94BB6124D68 for ; Wed, 3 May 2017 08:22:02 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u70so86704777ywe.2 for ; Wed, 03 May 2017 08:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+SPOXmR90jCRv8j89EOPn3Iu1StI94OTEC14ofzEWEA=; b=rH+lHN3l3EdGRG0lKRmDLxHciOV2ZzoUfoZ9aSdWuqBCFLQv9HHTERVCSENm0P/7QB 6IpGQvj22tu6f5Bbh45JGI1X+ESOiiCovzWKx2CymwHHNeh41gHLr5wC9rX3gy76uTRI IJp7XRSaRRYIVsdO2kpfPrD085p2Z8PLVx1qYehmUiVls1dmERoPRoP9C8voLd9awQth JmNLMjdC92zSTA744l/dPvSoFmra4ABk67ccCpPEb0gbq61vwPeb1qsQG0fbSgRfanfs Lt7f6pirARnvoXfkxH7eitXM5EIs8NXsFH4drobP8bnVbanyk2wn0piVQtZOIthFoMs1 BFFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+SPOXmR90jCRv8j89EOPn3Iu1StI94OTEC14ofzEWEA=; b=bAI629+yxBnixrhApqrzpbiAm8kkloP2neNQ8C4oUYksX2paHFk4N3BF+FgcxMM7Eg O05SV4mxts0SA8DUapPocl4FdBgQ7DC+ODxIzlwSug0LH6U3M9EbY8eJbOjqCrKhMZLt R6gyypMFpY6fJVPCkwvc1E2aTB2WLIAourcQDFFHxfUfOLJOQEKqG0yEsH+JIeylnXgN RIK7w/hk/IQCKFjNzepyb8w3HICZgW83KBAVk8FogQsspuPdqRZKcGyP9ZEsm/KzAo8a 3LWfDU7OdFHAqYKBc406DVcAiWqIT/y+MKvWPZL+z6Iq9WllCl9tRbyQXzh8pd4JYhuX Fwig== X-Gm-Message-State: AN3rC/6i2ezesbWCWub8FIjkafR5ga+AYrezjb0zZgDcAKjEElaAhzrg 3IO27Ld3RZ4MHS6/1BWf9woeFG5QZwht X-Received: by 10.129.105.198 with SMTP id e189mr29592051ywc.296.1493824921379; Wed, 03 May 2017 08:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 08:22:00 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 08:22:00 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a11471256cbc517054ea03773 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:24:36 -0000 --001a11471256cbc517054ea03773 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 6:07 AM, Viktor Dukhovni wrote: > > > On May 3, 2017, at 8:45 AM, Colm MacC=C3=A1rthaigh = wrote: > > > > The fundamental problem with STEKs is that there is no forward secrecy > > Sorry, STEKs are not long-term keys. There's nothing enforcing that, and research has shown STEKs being used for long periods of time. I think if we ask the question "What is probably the weakest security point in all of TLS?" I would give STEKs a strong nomination. Some problems; * STEKs can be used for years at a time * STEKs can be used across many domains and certificates * STEKs are often stored unencrypted on disk, hardcoded in configs * No mechanism to enforce how tickets are encrypted. Could be RC4. Most likely is AES, which mode? * Tickets are replay-able, weakening the protections against side channels. Most common algorithm is not side-channel resistant. They just seem to undo a lot of the good work we do in moving TLS endpoints to better algorithms and security modes. > So it makes little sense to claim that use of STEKs breaks forward > secrecy. I don't think this is even a controversial claim; the draft itself describes it. STEKs do break forward secrecy. > Indeed STEKs may be more safe > than server-side storage of complete sessions, since the latter are much > more likely to end up on disk. > STEKs often go in config .. which is usually on dist. Caches are most often in-memory only. > It is a shared meme that session tickets break forward secrecy, but it is > not correct. Poorly implemented session ticket keys can be a problem, bu= t > so can poorly implemented session caches. > That's true about caches, but one of the points in the review is that the economics work a little different and may favor security. > > The distributed single-use caches you are imagining are very complex beas= ts > My bias here is that I work on distributed systems, but a single-key distributed hash table is one of the simplest things we build. Though I acknowledge that it takes good attention to detail to properly secure access, and the data. > and I am much less inclined to trust those than a comparatively simple ke= y > rollover system (just three keys need to be known at any time, the past k= ey > for as yet unexpired sessions, the current key used to mint and decrypt > new sessions and the future key created shortly before the current key > becomes > the past key, giving enough time for all the cluster nodes to get a copy)= . > You can take a hybrid approach where you use such keys to encrypt the data in the cache itself. I think that gives you the "good" combined security properties of both. The time window for session compromise is never zero, after all, the keys > are in memory while the connection is active. It is unwise to insist tha= t > forward-secrecy is broken if session keys are not destroyed instantaneous= ly > at session closure. Others argue for something even stronger than this: that the keys should be ratcheted/rekeyed even while the session is still in use, to provide some forward secrecy for prior data on a connection that is still active. This is the general direction of best practice. > A reasonably short non-zero window of exposure may yield > greater security benefit than a design which appears to be more secure by > attempting synchronous destruction of keys at much greater overall design > complexity. > Yep, that is true. --=20 Colm --001a11471256cbc517054ea03773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 6:07 AM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
> On May 3, 2017, at 8:45 AM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
>
> The fundamental problem with STEKs is that there is no forward secrecy=

Sorry, STEKs are not long-term keys.

There's nothing enforcing that, and research has shown STEKs being use= d for long periods of time.=C2=A0

I think if we as= k the question "What is probably the weakest security point in all of = TLS?" I would give STEKs a strong nomination. Some problems;

* STEKs can be used for years at a time
* STEKs c= an be used across many domains and certificates
* STEKs are often= stored unencrypted on disk, hardcoded in configs
* No mechanism = to enforce how tickets are encrypted. Could be RC4. Most likely is AES, whi= ch mode?
* Tickets are replay-able, weakening the protections aga= inst side channels. Most common algorithm is not side-channel resistant.=C2= =A0

They just seem to undo a lot of the good work = we do in moving TLS endpoints to better algorithms and security modes.=C2= =A0
=C2=A0
So it makes little= sense to claim=C2=A0that use of STEKs breaks forward secrecy.=C2=A0

I don't think this is even a controversial cl= aim; the draft itself describes it. STEKs do break forward secrecy.=C2=A0
=C2=A0
Indeed STEKs may be mo= re safe
than server-side storage of complete sessions, since the latter are much more likely to end up on disk.

STEKs of= ten go in config .. which is usually on dist. Caches are most often in-memo= ry only.=C2=A0
=C2=A0
It is a shared meme that session tickets break forward secrecy, but it is not correct.=C2=A0 Poorly implemented session ticket keys can be a problem,= but
so can poorly implemented session caches.

That's true about caches, but one of the points in the review is tha= t the economics work a little different and may favor security.=C2=A0
=

The distributed single-use caches you are imagining are very complex beasts=

My bias here is that I work on distrib= uted systems, but a single-key distributed hash table is one of the simples= t things we build. Though I acknowledge that it takes good attention to det= ail to properly secure access, and the data.=C2=A0
=C2=A0
and I am much less inclined to trust those than a comparatively simple key<= br> rollover system (just three keys need to be known at any time, the past key=
for as yet unexpired sessions, the current key used to mint and decrypt
new sessions and the future key created shortly before the current key beco= mes
the past key, giving enough time for all the cluster nodes to get a copy).<= br>

You can take a hybrid approach where yo= u use such keys to encrypt the data in the cache itself. I think that gives= you the "good" combined security properties of both.=C2=A0
=

The time window for session compromise is never zero, after all, the keys are in memory while the connection is active.=C2=A0 It is unwise to insist = that
forward-secrecy is broken if session keys are not destroyed instantaneously=
at session closure.

Others argue for someth= ing even stronger than this: that the keys should be ratcheted/rekeyed even= while the session is still in use, to provide some forward secrecy for pri= or data on a connection that is still active. This is the general direction= of best practice. =C2=A0
=C2=A0
=C2=A0 A reasonably short non-zero window of exposure may yield
greater security benefit than a design which appears to be more secure by attempting synchronous destruction of keys at much greater overall design complexity.

Yep, that is true.=C2=A0

--
Colm
--001a11471256cbc517054ea03773-- From nobody Wed May 3 08:33:44 2017 Return-Path: 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 98D0A127A91 for ; Wed, 3 May 2017 08:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 DJBqeQ3_KeaE for ; Wed, 3 May 2017 08:33:34 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00964129B88 for ; Wed, 3 May 2017 08:31:04 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v43FQmnR016245; Wed, 3 May 2017 16:31:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=01jURIaDFlVxXPz194Duhnbz8Lkyw1UU+bO0pHjrX48=; b=kyKXzvWN4FmC8RpmjfD2GL6QZlt9McYv73pr+I2t4LWU/8GuLZVn9ROFmaRZPLbv2g4X zbi70L5qcsMmHSoHJjLHUDaf/49EFc9rpcXpi9KdvSmReLXb1NJfgHZ18VED2PbuP7tJ bzr3TN0WiWHwEU90ChDgJBcVefZiC9gSgnIVvnUTE6b4pdQVKmSrX6m2yJExOOcH6vUY AoVu5dMmSroxyyTovQMaj1PzCPG4Bn/M+34XcFhmehwNdOLsdQRAeCTPFDXXc4AhKQQn kJSWpCMUxg5XKydY5+msSRIUqsJb0yQLAu8DZopfw+xlifUT7JxlfcmI4BTlG5XPpidk lA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2a72my3wqw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 16:31:03 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v43FPirt006499; Wed, 3 May 2017 11:31:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a72m919up-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 11:31:02 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 10:31:01 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 10:31:01 -0500 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , TLS WG Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NICDv1l4S8FUWU9Zh5nPuktKHiqKmAgAA6vACAAAYlAIAAJaUA//+uO5A= Date: Wed, 3 May 2017 15:31:00 +0000 Message-ID: <80117b9d07ac40138bd059a603b37847@ustx2ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.217] Content-Type: multipart/alternative; boundary="_000_80117b9d07ac40138bd059a603b37847ustx2exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030285 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030285 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:33:37 -0000 --_000_80117b9d07ac40138bd059a603b37847ustx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVywgSSBhZ3JlZSB3aXRoIENvbG0gYWJvdXQgU1RFS+KAmXMgYmVpbmcgVExTIDEuM+KAmXMg d2Vha2VzdCBwb2ludCwgZm9yIHRoZSByZWFzb25zIGhlIGxpc3RzLiAgVGhlIHNlY3VyaXR5IHBy b3BlcnRpZXMgYXJlIHZlcnkgZGlmZmVyZW50IGZyb20gdGhlIGZ1bGwtaGFuZHNoYWtlIFRMUyAx LjMsIGFuZCB0aGF0IGlzIHdoeSBPcGVuU1NMIHRyZWF0cyDigJxlYXJseSBkYXRh4oCdIGFzIGEg Y29tcGxldGVseSBzZXBhcmF0ZSB0aGluZyBmcm9tIHRoZSDigJxub3JtYWwgc3RyZWFtLuKAnQ0K DQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVu U1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoN Cg== --_000_80117b9d07ac40138bd059a603b37847ustx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZXSVcsIEkgYWdyZWUgd2l0aCBDb2xtIGFib3V0IFNURUvi gJlzIGJlaW5nIFRMUyAxLjPigJlzIHdlYWtlc3QgcG9pbnQsIGZvciB0aGUgcmVhc29ucyBoZSBs aXN0cy4mbmJzcDsgVGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgYXJlIHZlcnkgZGlmZmVyZW50IGZy b20gdGhlIGZ1bGwtaGFuZHNoYWtlIFRMUyAxLjMsIGFuZA0KIHRoYXQgaXMgd2h5IE9wZW5TU0wg dHJlYXRzIOKAnGVhcmx5IGRhdGHigJ0gYXMgYSBjb21wbGV0ZWx5IHNlcGFyYXRlIHRoaW5nIGZy b20gdGhlIOKAnG5vcm1hbCBzdHJlYW0u4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LS0mbmJzcDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWVtYmVyLCBPcGVu U1NMIERldiBUZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_80117b9d07ac40138bd059a603b37847ustx2exdag1mb1msgcorpak_-- From nobody Wed May 3 08:58:02 2017 Return-Path: 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 10671129B19 for ; Wed, 3 May 2017 08:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 Fd4wNizH4smt for ; Wed, 3 May 2017 08:57:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF161129435 for ; Wed, 3 May 2017 08:55:47 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 644CB7A32F1 for ; Wed, 3 May 2017 15:55:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 11:55:45 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:58:01 -0000 > On May 3, 2017, at 11:22 AM, Colm MacC=C3=A1rthaigh = wrote: >=20 > There's nothing enforcing that, and research has shown STEKs being = used for long periods of time. That's an implementation defect. Not a problem with STEKs as such. In Postfix STEK lifetime =3D=3D 2 * session lifetime (the latter = defaults to 1 hour). Some time this year I'll introduce key rotation by default into OpenSSL, = which will result in short-term STEKs for all applications that don't = implement session ticket key management callbacks. That way, it is not just applications = that take the time to handle key rotation that will get short-term STEKs.=20 Mind you, long-lived servers such as Apache, Nginx, ... should also = implement key rotation via the relevant callback mechanisms and should not use = static keys. Sloppy implementations are not a problem with STEKs, the same = sloppy implementations will just as likely have insecure caches. --=20 Viktor. From nobody Wed May 3 09:04:16 2017 Return-Path: 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 2B55B129ABE for ; Wed, 3 May 2017 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 VywnmnSflqMk for ; Wed, 3 May 2017 09:04:14 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28C4129ACD for ; Wed, 3 May 2017 09:01:55 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v43FukAN008544 for ; Wed, 3 May 2017 17:01:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=mK9YplqOdmXTEVuwm/WYYEJpsdxUr8BYu31sZDtFuUM=; b=ZB+r2DBH+r0daHq0WIQRJliXB9V1bKK5yjzrB571WUGjHZEsGUCfX+xEBWFxyCvahA0r uoKCILKZKfqDKdAxEHOUl+cn/SIcBQBcBqpvLgJrgAVUzRqkRxGkQODyJcq8JtfagVUm FhxAzPPI1+fnrSGE6fcXkNYIxbv9VKpsEQFJga3pFFLSCSlTX84G3K9ZQ92kGse3ka/1 CK/izFddKI57cO+2PeWAu32Ft/vdCDTpCErEV9TqRy6PJJSxnmF4S5YugI07RWCi1Skz s3VBH5UOuy27g18lUaIng9hxR8jSnsOfnjQFfHMa6TWznfkUI5qU7ukoBqHvPdvXrhbO qw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2a72n4vcm5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 03 May 2017 17:01:52 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v43Fp2dx021692 for ; Wed, 3 May 2017 12:01:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a72m91bky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 03 May 2017 12:01:49 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 09:01:47 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 11:01:47 -0500 From: "Salz, Rich" To: TLS WG Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NICDv1l4S8FUWU9Zh5nPuktKHiqKmAgAA6vACAAAYlAIAAJaUAgAAJboD//62gwA== Date: Wed, 3 May 2017 16:01:46 +0000 Message-ID: <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> In-Reply-To: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030292 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030294 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:04:15 -0000 PiBTb21lIHRpbWUgdGhpcyB5ZWFyIEknbGwgaW50cm9kdWNlIGtleSByb3RhdGlvbiBieSBkZWZh dWx0IGludG8gT3BlblNTTCwgd2hpY2gNCg0KR3JlYXQgOikNCg0KPiB1c2Ugc3RhdGljIGtleXMu ICBTbG9wcHkgaW1wbGVtZW50YXRpb25zIGFyZSBub3QgYSBwcm9ibGVtIHdpdGggU1RFS3MsIHRo ZQ0KPiBzYW1lIHNsb3BweSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBqdXN0IGFzIGxpa2VseSBoYXZl IGluc2VjdXJlIGNhY2hlcy4NCg0KVGhlIHByb3RvY29sIGRlc2lnbiBzaG91bGQgYXZvaWQgc2V0 dGluZyB0cmFwcyBmb3IgdGhlIHVud2FyeS4NCg0K From nobody Wed May 3 09:12:28 2017 Return-Path: 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 76778126B7F for ; Wed, 3 May 2017 09:12:26 -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] 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 VOT1a1oF8-nD for ; Wed, 3 May 2017 09:12:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151F012869B for ; Wed, 3 May 2017 09:10:13 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3920E7A32F1 for ; Wed, 3 May 2017 16:10:13 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 3 May 2017 12:10:12 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:12:26 -0000 > On May 3, 2017, at 12:01 PM, Salz, Rich wrote: > > The protocol design should avoid setting traps for the unwary. No, that responsibility falls on libraries. STEKs are not a trap for the unweary. Libraries that support static session tickets by default can be viewed as such a trap. So the onus to fix this is on us (OpenSSL team) not the TLS protocol. -- Viktor. From nobody Wed May 3 09:17:27 2017 Return-Path: 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 557B812783A for ; Wed, 3 May 2017 09:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 Q19pfIHZXuyA for ; Wed, 3 May 2017 09:17:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2478128E19 for ; Wed, 3 May 2017 09:15:25 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v43GF4Ob014777 for ; Wed, 3 May 2017 17:15:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=loQ0yDINLsRlgLN7rWVozPMkcML8ZUOFfKC8QCv6xWc=; b=EPMKFxF6U05vl2ullBNQsJ610ZSkyLc01BQ0rv1qzmOLPJ7Hce+YwjECiQAWOFOM3xk2 VudRU9vKYEOFXZIRaVJ0NMfkNGcdtKob2qJ51oJ1+DQtp/m1WJzS8gTx5aC9sm8xjZkE GhVJSfbWhKJr/xwCITVb72HoVjV72tGc+UYZagFT3ty2o3aFVVxiFJiI23YX3RveBzOV 13nxbWrcg63Ws7IbGRQ37ySzBRMvBXMdbXwylZsxrOZ1oTIY8EM4Xi9jxsXTjc8cZ2xJ wy5acn0qHhl4onyrNSGoDqA/or2x4OEeqcwed4TutWIB4Fvahy3QmfhKj2DABty/VTMa Rw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2a72pcm192-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 03 May 2017 17:15:21 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v43G4NCE014814 for ; Wed, 3 May 2017 12:15:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2a72mb20y1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 03 May 2017 12:15:15 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 11:15:14 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 11:15:14 -0500 From: "Salz, Rich" To: TLS WG Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NICDv1l4S8FUWU9Zh5nPuktKHiqKmAgAA6vACAAAYlAIAAJaUAgAAJboD//62gwIAAVmoA//+tbDA= Date: Wed, 3 May 2017 16:15:14 +0000 Message-ID: <7e8cdee4abfb43b692efe2f570059bfb@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> In-Reply-To: <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.217] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030294 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030297 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:17:25 -0000 > No, that responsibility falls on libraries. STEKs are not a trap for the= unweary. Unweary :) Funny. We disagree. And I think the concerns Colm has raised show that others are= also in agreement. From nobody Wed May 3 09:31:23 2017 Return-Path: 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 052F1129B21 for ; Wed, 3 May 2017 09:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 hKlBD1x9x1fe for ; Wed, 3 May 2017 09:31:20 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22799129B3C for ; Wed, 3 May 2017 09:29:15 -0700 (PDT) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 29EF0184 for ; Wed, 3 May 2017 17:29:12 +0100 (BST) Received: by mail-it0-f46.google.com with SMTP id e65so40335788ita.1 for ; Wed, 03 May 2017 09:29:12 -0700 (PDT) X-Gm-Message-State: AN3rC/6ajBXtYVJadPYLaK+jZYaoi+oFYWk9BPOP/9LFEMuPitgsmX6M XzqTl2DITBKWKgO7mLpHNBZZqU1MCQ== X-Received: by 10.36.60.132 with SMTP id m126mr1545439ita.113.1493828951564; Wed, 03 May 2017 09:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.127.79 with HTTP; Wed, 3 May 2017 09:29:11 -0700 (PDT) From: Matt Caswell Date: Wed, 3 May 2017 17:29:11 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] OpenSSL now at draft-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:31:22 -0000 FYI, I have just made the necessary updates to bring the OpenSSL master branch up to draft-20 compatibility. Please test!! Thanks Matt From nobody Wed May 3 11:18:50 2017 Return-Path: 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 5E09A129B5E for ; Wed, 3 May 2017 11:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Wj-FkSMVahfY for ; Wed, 3 May 2017 11:18:48 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBC4129B9A for ; Wed, 3 May 2017 11:16:48 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id F3D3DA007630; Wed, 3 May 2017 11:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+3OukeRx6QwJYN WxoufhuuiaPFg=; b=FqZPueB/KFXazFBlrVZfHjyrbYg92Qp7NZ2B2q1qpWQCM3 yArnh0ozk6fDgsHn/aniRNaL9gGnLJC78Ck9fvvBty+2OlIU6W0Y71NhDTH1q6wn Er23rOtRzwrWdRTAjUQ+iqRyvLUE1XCvJc+f0wNQl+GqbXHFNPUk2zxlgcOpY= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 9666CA00762D; Wed, 3 May 2017 11:16:47 -0700 (PDT) Date: Wed, 3 May 2017 13:16:45 -0500 From: Nico Williams To: Eric Rescorla Cc: Daniel Kahn Gillmor , TLS WG Message-ID: <20170503181644.GQ10188@localhost> References: <20170502193145.GI10188@localhost> <42522b3c-8987-ea2a-2173-bcadaf6ff326@akamai.com> <20170502195753.GJ10188@localhost> <87a86vrnge.fsf@fifthhorseman.net> <20170502212953.GK10188@localhost> <20170502230258.GL10188@localhost> <20170503042227.GN10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:18:49 -0000 On Tue, May 02, 2017 at 09:41:00PM -0700, Eric Rescorla wrote: > On Tue, May 2, 2017 at 9:22 PM, Nico Williams wrote: > > > On Tue, May 02, 2017 at 04:41:52PM -0700, Eric Rescorla wrote: > > > On Tue, May 2, 2017 at 4:02 PM, Nico Williams > > wrote: > > > > On Tue, May 02, 2017 at 03:53:48PM -0700, Eric Rescorla wrote: > > > > > It's not XOR. It's addition mod 2^32. That's important because the > > > > > *difference* > > > > > between the ticket replay times is directly observable anyway. > > > > > > > > Computationally there's no real difference between that and XOR. > > > > > > What information do you believe you are gathering here? > > > > I believe the attack described is finding the time of the session's > > establishment. > > Hmm.... Can you walk me through how you think that works? Well, I hadn't done it myself. I see now though that the attack doesn't work. I would still prefer proper encryption. But this works. Nico -- From nobody Wed May 3 11:23:15 2017 Return-Path: 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 9A196128A32 for ; Wed, 3 May 2017 11:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 gS9DUBcuDgtd for ; Wed, 3 May 2017 11:23:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B40129B37 for ; Wed, 3 May 2017 11:20:59 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 32A287A32F1 for ; Wed, 3 May 2017 18:20:59 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <7e8cdee4abfb43b692efe2f570059bfb@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 3 May 2017 14:20:58 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <7e8cdee4abfb43b692efe2f570059bfb@ustx2ex-dag1mb1.msg.corp.akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:23:15 -0000 > On May 3, 2017, at 12:15 PM, Salz, Rich wrote: >=20 > We disagree. And I think the concerns Colm has raised show that = others are also in agreement. I see all the talk of STEKs (session ticket encryption keys) breaking = forward-secrecy as FUD. All kinds of poor implementation and/or operational practices may = compromise confidentiality, The (mis)use of long-term STEKs is not particularly special among such = practices. If libraries implement "long-term" STEKs, that's a library bug, not a = protocol issue. --=20 Viktor. From nobody Wed May 3 11:31:53 2017 Return-Path: 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 5A9F51294EF for ; Wed, 3 May 2017 11:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 BuOT2U3FSAwF for ; Wed, 3 May 2017 11:31:50 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD2912955A for ; Wed, 3 May 2017 11:30:00 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BE2C6A00762F; Wed, 3 May 2017 11:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=WjZgXdv8FKMlnZLpWwIV+P2ufW8 =; b=pRn1Wx8cbpznYD8oL8b1G/o6iEe81ZckDRqyi0uSoDrJ63XZIjoJEQ4e+CC AbZrfl2jo+JS5BBJds7eF2FHtCwPidHe7uIAkgrE8dpES1RVFJ6ZcIRC6pruAakA ov/Au/8zjDJbBxwsxHiFxoL3JgpqHNER3nOETZ0LB5FFz0HU= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 7133AA00762D; Wed, 3 May 2017 11:29:59 -0700 (PDT) Date: Wed, 3 May 2017 13:29:56 -0500 From: Nico Williams To: TLS WG Message-ID: <20170503182955.GR10188@localhost> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:31:51 -0000 On Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote: > > On May 3, 2017, at 12:01 PM, Salz, Rich wrote: > > The protocol design should avoid setting traps for the unwary. > > No, that responsibility falls on libraries. STEKs are not a trap for the > unweary. Libraries that support static session tickets by default can be > viewed as such a trap. So the onus to fix this is on us (OpenSSL team) > not the TLS protocol. A big +1 to this. I think it would terrible if we couldn't have resumption at all because one common implementation mishandles old key deletion. Nico -- From nobody Wed May 3 11:35:49 2017 Return-Path: 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 E1D52129BD1 for ; Wed, 3 May 2017 11:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.onmicrosoft.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 j8ra3_al4y0R for ; Wed, 3 May 2017 11:35:43 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0076.outbound.protection.outlook.com [104.47.36.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0642B129B40 for ; Wed, 3 May 2017 11:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=69rMsJeAXx+us/9xMnb+cjMmXDYgyulWDPI0U1f1F44=; b=uL3+Fq83V0gI/4rMu+ncoszYTFxaQnYhORn+LcSOwx/rlQGUfEEIJBoIBZcxAT0w3snDOhKTt4h2DczrKNu4dq6ecRXujsMPQDM5XRbdnFu0vWxNytLcFdOMG2Bzd0FlhUm0ErXk+ztfPnH3EAN9jG6yJLD9xvEsqZz7Xko1AZA= Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1733.namprd10.prod.outlook.com (10.172.69.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Wed, 3 May 2017 18:33:33 +0000 Received: from CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) by CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) with mapi id 15.01.1075.010; Wed, 3 May 2017 18:33:33 +0000 From: Timothy Jackson To: Nico Williams , TLS WG Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NKNF5IQ29vr0umUMeDlmEnG6HiVNeAgAA6vACAAAYmAIAAJaUAgAAJboCAAAGuAIAAAlsAgAAnCwD//4usgA== Date: Wed, 3 May 2017 18:33:33 +0000 Message-ID: <51724E2C-45A3-4A18-A5FE-0A6B33C23077@mobileiron.com> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> In-Reply-To: <20170503182955.GR10188@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cryptonector.com; dkim=none (message not signed) header.d=none;cryptonector.com; dmarc=none action=none header.from=mobileiron.com; x-originating-ip: [198.61.62.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR10MB1733; 7:fY1ZqAcJkppFucsUaGmCbYzOH9jj6E97Mn1sg/N0uKAVFnt/5k2VjH8YxK2avg/DG1WRLrQPUnSBz/uDMV5C8qQmsCPcA6yPqociFqYw8odqAeGuP5s6XsRk2OerQ9G7de3QXQzf7z+qZ9ZysIfBZOHYwFOftcuj9TBEfE55eajiZccgbNd39rsqJwlsmazOW1OFteE/TqWxTHRldEmWzdKSvIbyFVMrWekgWuV6SxTmqUfzHIwXOZyHj8/06lDFnAGY5NJ70Yri3iAX/YOIct09WZ8xbun1G3d2rHpQ1iTrqGh0kBABynZAEpaGDlg6Wh0oLkQFzPTm3lX33LvtGA== x-ms-office365-filtering-correlation-id: 3be4bd97-2714-4977-f053-08d49252e78c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR10MB1733; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY4PR10MB1733; BCL:0; PCL:0; RULEID:; SRVR:CY4PR10MB1733; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(24454002)(377454003)(36756003)(2900100001)(93886004)(6512007)(6306002)(15650500001)(122556002)(99286003)(478600001)(3660700001)(81166006)(53546009)(86362001)(38730400002)(6246003)(189998001)(25786009)(53936002)(7736002)(6116002)(6436002)(76176999)(8936002)(50986999)(3846002)(54356999)(102836003)(305945005)(8676002)(33656002)(229853002)(6486002)(2950100002)(2906002)(6506006)(77096006)(5660300001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1733; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <52CA0D9172EEA24794695A7D2104D255@namprd10.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 18:33:33.3667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1733 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:35:48 -0000 PiAgICBUaGUgKG1pcyl1c2Ugb2YgbG9uZy10ZXJtIFNURUtzIGlzIG5vdCBwYXJ0aWN1bGFybHkg c3BlY2lhbCBhbW9uZyBzdWNoIHByYWN0aWNlcy4NCg0KVGhpcyBtYXkgYmUgdHJ1ZSwgYnV0IHRo YXQgc3RpbGwgZG9lc27igJl0IG1ha2UgaXQgYSBnb29kIGlkZWEuIFdlIHNob3VsZCBwcm9iYWJs eSBkbyAqc29tZXRoaW5nKiBhYm91dCB0aGlzLiBKDQoNCj4gICAgVGhlIHByb3RvY29sIGRlc2ln biBzaG91bGQgYXZvaWQgc2V0dGluZyB0cmFwcyBmb3IgdGhlIHVud2FyeS4gICAgDQo+ICAgIElm IGxpYnJhcmllcyBpbXBsZW1lbnQgImxvbmctdGVybSIgU1RFS3MsIHRoYXQncyBhIGxpYnJhcnkg YnVnLCBub3QgYSBwcm90b2NvbCBpc3N1ZS4NCg0KU2VlbXMgdG8gbWUgdGhhdCBib3RoIHBvaW50 cyBhcmUgdmFsaWQgYW5kIG5vdCBtdXR1YWxseSBleGNsdXNpdmUuIFdoeSBkb27igJl0IHdlIGNh cHR1cmUgdGhpcyBkaXNjdXNzaW9uIGluIHRoZSBSRkMgaXRzZWxmPyBXZSBvZnRlbiBwcm92aWRl IGd1aWRhbmNlL2FsZXJ0cyBmb3IgaW1wbGVtZW50ZXJzLiBXaHkgc2hvdWxkIHRoaXMgYmUgZGlm ZmVyZW50PyBTdWNoIGEgd2FybmluZyB3b3VsZCBwcmVzdW1hYmx5IHByZXZlbnQgaXQgZnJvbSBi ZWluZyBhIHRyYXAgZm9yIHRoZSB1bndhcnkgKG9yIHVud2VhcnksIGRlcGVuZGluZyBvbiBob3cg bXVjaCByZXN0IHRoZXnigJl2ZSBnb3R0ZW4pIHdpdGhvdXQgcmVxdWlyaW5nIGEgY2hhbmdlIHRv IHRoZSBwcm90b2NvbCBpdHNlbGYuIA0KDQpXZSBjb3VsZCBldmVuIGdvIHNvIGZhciBhcyB0byBh ZGQgYSDigJxTSE9VTEQgTk9U4oCdIGFyb3VuZCB1c2luZyBTVEVLcyB0aGF0IGFyZSBsb25nLWxp dmVkPyBUaGF0IHdvdWxkIHByb3ZpZGUgYSBzdHJvbmcgaGludCB0byBpbXBsZW1lbnRlcnMgYnV0 IGxlYXZlIGZsZXhpYmlsaXR5IGZvciB0aG9zZSB3aG8gbmVlZCBkaWZmZXJlbnQgYmVoYXZpb3Ig YW5kIHVuZGVyc3RhbmQgdGhlIHJpc2tzPw0KDQpDaGVlcnMsDQoNClRpbQ0K4oCUDQpUaW0gSmFj a3NvbiB8IFByb2R1Y3QgU2VjdXJpdHkgQXJjaGl0ZWN0IHwgTW9iaWxlSXJvbiwgSW5jLg0KDQpP biA1LzMvMTcsIDExOjI5IEFNLCAiTmljbyBXaWxsaWFtcyIgPG5pY29AY3J5cHRvbmVjdG9yLmNv bT4gd3JvdGU6DQoNCiAgICBPbiBXZWQsIE1heSAwMywgMjAxNyBhdCAxMjoxMDoxMlBNIC0wNDAw LCBWaWt0b3IgRHVraG92bmkgd3JvdGU6DQogICAgPiA+IE9uIE1heSAzLCAyMDE3LCBhdCAxMjow MSBQTSwgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4gd3JvdGU6DQogICAgPiA+IFRoZSBw cm90b2NvbCBkZXNpZ24gc2hvdWxkIGF2b2lkIHNldHRpbmcgdHJhcHMgZm9yIHRoZSB1bndhcnku DQogICAgPiANCiAgICA+IE5vLCB0aGF0IHJlc3BvbnNpYmlsaXR5IGZhbGxzIG9uIGxpYnJhcmll cy4gIFNURUtzIGFyZSBub3QgYSB0cmFwIGZvciB0aGUNCiAgICA+IHVud2VhcnkuICBMaWJyYXJp ZXMgdGhhdCBzdXBwb3J0IHN0YXRpYyBzZXNzaW9uIHRpY2tldHMgYnkgZGVmYXVsdCBjYW4gYmUN CiAgICA+IHZpZXdlZCBhcyBzdWNoIGEgdHJhcC4gIFNvIHRoZSBvbnVzIHRvIGZpeCB0aGlzIGlz IG9uIHVzIChPcGVuU1NMIHRlYW0pDQogICAgPiBub3QgdGhlIFRMUyBwcm90b2NvbC4NCiAgICAN CiAgICBBIGJpZyArMSB0byB0aGlzLg0KICAgIA0KICAgIEkgdGhpbmsgaXQgd291bGQgdGVycmli bGUgaWYgd2UgY291bGRuJ3QgaGF2ZSByZXN1bXB0aW9uIGF0IGFsbCBiZWNhdXNlDQogICAgb25l IGNvbW1vbiBpbXBsZW1lbnRhdGlvbiBtaXNoYW5kbGVzIG9sZCBrZXkgZGVsZXRpb24uDQogICAg DQogICAgTmljbw0KICAgIC0tIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgVExTIG1haWxpbmcgbGlzdA0KICAgIFRMU0BpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAg DQoNCg== From nobody Wed May 3 11:56:35 2017 Return-Path: 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 F404E129B75 for ; Wed, 3 May 2017 11:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 CkYGX6yWLITI for ; Wed, 3 May 2017 11:56:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E211294DC for ; Wed, 3 May 2017 11:54:51 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 02A907A32F1 for ; Wed, 3 May 2017 18:54:51 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <51724E2C-45A3-4A18-A5FE-0A6B33C23077@mobileiron.com> Date: Wed, 3 May 2017 14:54:50 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <51724E2C-45A3-4A18-A5FE-0A6B33C23077@mobileiron.com> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:56:34 -0000 > On May 3, 2017, at 2:33 PM, Timothy Jackson = wrote: >=20 > We could even go so far as to add a =E2=80=9CSHOULD NOT=E2=80=9D = around using STEKs that are long-lived? No specific objection there, motherhood and apple pie... so long as we = don't go too far and say "SHOULD NOT" to STEKs broadly. They are a sensible way to = handle session caching, in combination a sensibly implemented key rotation approach. = One also SHOULD NOT store long-term copies of sessions, deploy world-readable private = keys, ... So, if folks feel that it is necessary to give such advice, that's fine. --=20 Viktor. From nobody Wed May 3 12:21:37 2017 Return-Path: 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 387F01294F7 for ; Wed, 3 May 2017 12:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 JHbi1HXKBQPa for ; Wed, 3 May 2017 12:21:35 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A638E12953B for ; Wed, 3 May 2017 12:19:32 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id k11so90169399ywb.1 for ; Wed, 03 May 2017 12:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jmpjn/bAsPO74TpOqU3oBRCQiYo+OPTfOG/b3li21lM=; b=hiMF+4OoqW4nyd3JsURFjAYGQ5QlacApczRRN7YnVQozuuSnif0V4N3vSjuapQRzqN TkFJtB3XEKxxmw+TdadfjG+m7aDIdJOtGSUZF8GuFyOoeyRw0b532VFr9tG5ywKXbayk ltAkSOvR8UwcihCS8OCys7kQPmEaMZtSZtxcXHdvCYcIx+6HsLMm5wFO/u+fg++uKS+5 DbBSjTkrhTUGt9EQm5yB0p2/2we4y/Js07r7Yfh+iRBP0L/BAoBLePEGsmkdJzl6u/tn tsXV5I94IgWkgWq8fBc4oQcv4rP4cS7Z8VYAqm6NxWJQbiRFaDrAb2y6yeajxVukajI7 ghLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jmpjn/bAsPO74TpOqU3oBRCQiYo+OPTfOG/b3li21lM=; b=HmFXRAb5mmSIo6I2JQdRZM6PnZoXhdzsCu6KBzG0S6+t2HM4rK7xZ4IHAddAdG/uP+ tQxFaDNH8Jkzz0Q1dsf1hWI1FEJc4BbZKUH02JHohOOYB3WqlIGOAX06yPQ/VyTRw9UC SReOTHAeQX5DssJGlA5TZuZz+xorC/EAVxi4aSqAPi9Js5+KHLXPwTJTsrC9l33yeBmF Fq9RDO2O+EhKPciY5mqWLim/zlk16A8L1jHO7f+mWLAF/SYZIWNkJmKPOENzuPZznifD m9xyJ07HJXsAyJ/ru3/U/zF2LDKyKNJH/oS/GCg4btmIJFo+SVGxZWNSUpNZbr8MHBOn B4xQ== X-Gm-Message-State: AN3rC/6IgxvjJeNPzCo/rXQi8U945uuVfA1/Sjp6lNojDuPPmcLhlX8L hYo4nusMPRIDBL5g6dFo01kJyt9j1qcX X-Received: by 10.13.238.65 with SMTP id x62mr30068958ywe.122.1493839171816; Wed, 03 May 2017 12:19:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 12:19:30 -0700 (PDT) In-Reply-To: <20170503182955.GR10188@localhost> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 12:19:30 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary=94eb2c034d8c302b74054ea38933 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 19:21:37 -0000 --94eb2c034d8c302b74054ea38933 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 11:29 AM, Nico Williams wrote: > On Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote: > > > On May 3, 2017, at 12:01 PM, Salz, Rich wrote: > > > The protocol design should avoid setting traps for the unwary. > > > > No, that responsibility falls on libraries. STEKs are not a trap for the > > unweary. Libraries that support static session tickets by default can be > > viewed as such a trap. So the onus to fix this is on us (OpenSSL team) > > not the TLS protocol. > > A big +1 to this. > > I think it would terrible if we couldn't have resumption at all because > one common implementation mishandles old key deletion. > With the improvements in 1.3 all of this FS only pertains to 0-RTT data, not resumption in general. One solution would be to have two, or three sub-types of ticket exchanges: Type 1 - same as now, except remove the ticket age, generally intended for resumption. Can be used multiple times. Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (maybe not in the ticket itself, but somewhere in the handshake), can only be used once. Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to prevent self-encryption. Though honestly, I'm not even sure 2.2 is a great idea any more, maybe too much complexity, and we can just measure the size and enforce things that way. -- Colm --94eb2c034d8c302b74054ea38933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, May 3, 2017 at 11:2= 9 AM, Nico Williams <nico@cryptonector.com> wrote:
On= Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote:
> > On May 3, 2017, at 12:01 PM, Salz, Rich <rsalz@akamai.com> wrote:
> > The protocol design should avoid setting traps for the unwary. >
> No, that responsibility falls on libraries.=C2=A0 STEKs are not a trap= for the
> unweary.=C2=A0 Libraries that support static session tickets by defaul= t can be
> viewed as such a trap.=C2=A0 So the onus to fix this is on us (OpenSSL= team)
> not the TLS protocol.

A big +1 to this.

I think it would terrible if we couldn't have resumption at all because=
one common implementation mishandles old key deletion.

With the improvements in 1.3 all of this FS only pertains t= o 0-RTT data, not resumption in general. One solution would be to have two,= or three sub-types of ticket exchanges:

Type 1 - = same as now, except remove the ticket age, generally intended for resumptio= n. Can be used multiple times.

Type 2.1 - Ticket i= ntended for 0-RTT, does include the ticket age (maybe not in the ticket its= elf, but somewhere in the handshake), can only be used once.

=
Type 2.2 - Same as 2.1, but required to be smaller than RPSK in = size, to prevent self-encryption.=C2=A0

Though hon= estly, I'm not even sure 2.2 is a great idea any more, maybe too much c= omplexity, and we can just measure the size and enforce things that way.=C2= =A0
=C2=A0
--
Colm
--94eb2c034d8c302b74054ea38933-- From nobody Wed May 3 12:37:00 2017 Return-Path: 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 5239512946C for ; Wed, 3 May 2017 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 qm1Mgh0bA-F5 for ; Wed, 3 May 2017 12:36:57 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B67B1294E2 for ; Wed, 3 May 2017 12:35:21 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BDB3FA007632; Wed, 3 May 2017 12:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ob75OZFCXTwRGtBPwYtmrk5l/wk=; b=SuRVmyKMCUS 2YtrsMYOqA/t6Hvmid0aX32AO5H9ttSPBdFk8pminl9xNfQZa0ZDhZXER4D8fNdE Vk5fIkJ3zp7EufoFVwxHXjSxYAFaxZw6hskFHkQLfCvhHJrqdZDKKN4kLTRkM6Qp ALC21exRhad8IhOu7bh+xyt8PWJKXHp0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 5E673A007631; Wed, 3 May 2017 12:35:20 -0700 (PDT) Date: Wed, 3 May 2017 14:35:17 -0500 From: Nico Williams To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Cc: TLS WG Message-ID: <20170503193517.GS10188@localhost> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 19:36:58 -0000 On Wed, May 03, 2017 at 12:19:30PM -0700, Colm MacC=E1rthaigh wrote: > With the improvements in 1.3 all of this FS only pertains to 0-RTT data= , > not resumption in general. One solution would be to have two, or three > sub-types of ticket exchanges: >=20 > Type 1 - same as now, except remove the ticket age, generally intended = for > resumption. Can be used multiple times. No, please don't remove the obfuscated ticket age. Either make it encrypted or leave it as-is. > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (mayb= e > not in the ticket itself, but somewhere in the handshake), can only be = used > once. No. Give advice. Do not remove these features. > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, t= o > prevent self-encryption. I don't grok this. Nico --=20 From nobody Wed May 3 13:21:56 2017 Return-Path: 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 C0E1112783A for ; Wed, 3 May 2017 13:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 fT4WbVrT6CU4 for ; Wed, 3 May 2017 13:21:52 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2055129B30 for ; Wed, 3 May 2017 13:19:37 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 203so353115ywe.0 for ; Wed, 03 May 2017 13:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/l8rWadGJxc0E4yeDL9WErIN655dbshaZY/PN1mP4Mo=; b=QuwB+K6zssjW7eH8hcwKuE7cPv8yX3xx7aZ0r6F5IeCqSJkB4cugr+ZvEwOXJLF+Tk ms15OUA78gAQo5rA4jISKjLt9JcPRnBfhUY2KSpLUvYL85mtG7fpj/4AV6LxBNr96fnR tHoubCeu0btHeV5ZMRSMzQNkKlWwAi0f+d2jCRgZDmCgLs8puIQsAt5ZJopGkJLM1aN6 RVA/Zr94U16BSyIFFICF9Jpj6vxn66h0DmEJgrjaznAs7NQjU9jgcK5zpap2xRDXNcTG DxQJStAB4VcYCb6w/jzoGZ1jJNReg/H7Wb6CsuZg4euF84Q7fdT4L9+q0QEnn6D7Gc9p Gsag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/l8rWadGJxc0E4yeDL9WErIN655dbshaZY/PN1mP4Mo=; b=EoR9x97lQ6YF6zXf66STiPpqO+nFhfL569HmnLiVdJAmpp2OtTBK8rP44oPOxzgipf aQtf1rARAq1a0GA+IB73UngSoADhyitQCQtizGLs2mY76jDVWU87OETQA+NwJ7eCuITl koahizksOVVsTz+1MfpqPx0XD3aKtwOn0/qnmU0kJayHQUO1uHz44gKR9bul3nOgrHRm XmVILnWbnJQ43bo5um5jeBNhfk+SgOVzsMbvXomVjLj3gP6Us2znC3dnHf2sNOGjhRmi J3Ne//N4HarCjG72+iBS5W+Dygbkh/l7fbeoP4BTh1gZlvB73UMRL6uCgkDUrpflB9RI S3Ig== X-Gm-Message-State: AN3rC/45A4n4l7SN4tbXnlNqD2H5p/D0SmD8TofxiGcL2KMQ/HZ3P93S 4uKydD6yBf9p5TGcQ7Bq+gUqORVvjA== X-Received: by 10.129.157.142 with SMTP id u136mr2869175ywg.323.1493842776839; Wed, 03 May 2017 13:19:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 13:19:35 -0700 (PDT) In-Reply-To: <20170503193517.GS10188@localhost> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <20170503193517.GS10188@localhost> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 13:19:35 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary=94eb2c0b68aa109260054ea460dc Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:21:54 -0000 --94eb2c0b68aa109260054ea460dc Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 12:35 PM, Nico Williams wrote: > No, please don't remove the obfuscated ticket age. Either make it > encrypted or leave it as-is. > If it is to be encrypted, say AEAD'd, it needs to be encrypted under a key that the client and server share; because the client needs to modify the age before sending. Moving the age to its own message, post Client-Hello, could solve that - so it comes out of the ticket. That scheme is a bit weird and circular: the server would have to "use" the ticket to derive a key that decrypts the age, to then decide if it should "really use" the ticket for 0-RTT data. That seems pretty convoluted to me - could be a fairly complicated security proof. > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (maybe > > not in the ticket itself, but somewhere in the handshake), can only be > used > > once. > > No. Give advice. Do not remove these features. > I think the can only be used once for 0-RTT needs to be firm. Otherwise 0-RTT mode is insecure. > > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to > > prevent self-encryption. > > I don't grok this. > Self-encrypting tickets require STEKs and all of their problems. A client could say "Don't send me a STEK-based ticket", and this can be enforced by requiring those tickets to be smaller than the RPSK in size. The client at least knows that the ticket couldn't possibly have been self-encrypted. Though obviously it says nothing about how good a job the server is doing of keeping the keys secret. -- Colm --94eb2c0b68aa109260054ea460dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, May 3, 2017 at 12:3= 5 PM, Nico Williams <nico@cryptonector.com> wrote:
No, please don'= t remove the obfuscated ticket age.=C2=A0 Either make it
encrypted or leave it as-is.

If it is t= o be encrypted, say AEAD'd, it needs to be encrypted under a key that t= he client and server share; because the client needs to modify the age befo= re sending. Moving the age to its own message, post Client-Hello, could sol= ve that - so it comes out of the ticket.=C2=A0

Tha= t scheme is a bit weird and circular: the server would have to "use&qu= ot; the ticket to derive a key that decrypts the age, to then decide if it = should "really use" the ticket for 0-RTT data. That seems pretty = convoluted to me - could be a fairly complicated security proof. =C2=A0

> Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (may= be
> not in the ticket itself, but somewhere in the handshake), can only be= used
> once.

No.=C2=A0 Give advice.=C2=A0 Do not remove these features.

I think the can only be used once for 0-RTT need= s to be firm. Otherwise 0-RTT mode is insecure.=C2=A0
=C2=A0
> Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, = to
> prevent self-encryption.

I don't grok this.

Self-encr= ypting tickets require STEKs and all of their problems. A client could say = "Don't send me a STEK-based ticket", and this can be enforced= by requiring those tickets to be smaller than the RPSK in size.=C2=A0 The = client at least knows that the ticket couldn't possibly have been self-= encrypted.=C2=A0 Though obviously it says nothing about how good a job the = server is doing of keeping the keys secret.=C2=A0

--
C= olm
--94eb2c0b68aa109260054ea460dc-- From nobody Wed May 3 13:22:45 2017 Return-Path: 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 5AB2112E053 for ; Wed, 3 May 2017 13:22:44 -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] 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 7aprusV0R8c8 for ; Wed, 3 May 2017 13:22:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B27129BEF for ; Wed, 3 May 2017 13:20:13 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3332C7A32F1 for ; Wed, 3 May 2017 20:20:12 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 16:20:11 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:22:44 -0000 > On May 3, 2017, at 3:19 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, = to prevent self-encryption.=20 The kind of application whose security requirements preclude use of RFC = 5077 session tickets can and should likely also avoid both 0-RTT and session resumption entirely. Otherwise, allow the server to choose a sensible = session management approach. Second-guessing the server's design by looking at ticket sizes seems = rather contrived. --=20 Viktor. From nobody Wed May 3 13:29:14 2017 Return-Path: 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 B6861129C1B for ; Wed, 3 May 2017 13:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 Z2IG3_DNxFzf for ; Wed, 3 May 2017 13:29:11 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC333129C4C for ; Wed, 3 May 2017 13:27:13 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id s22so180366ybe.3 for ; Wed, 03 May 2017 13:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6VxQwlp6mQcA1tHmGqwyLjAiTuflIF8wUdM6z3RS/NE=; b=mVnqLIparJSLwhOtvfvImoPXVsufmL1TV2yiBQC9f1QSd6vDl6/7TPzLzEooFxN1J+ NaY4I9bPPqwJ5egz7OG7OlIB3msnTfwwWX6DlvnNq104WmH9YhHakTedNiZKW5E/oPGU h/dE0MD2xk+1kAakE4v9iUg1Jer5Sw7B4uULav7xRTYq2a6YCCOhG4iNx1VpAH5+iLEs yU7mkFj6oo8qKH5TdcJpDkN17KmQo0KL4DIFOjuP1Iy9/CJkuzhFAizjBBbDwwy4z3pm NL4S3URMOtgBPT293lEgWtssYmrJvI0A7o4x2KIdJynBdl2uJrXHBtV65dvYFD0fqFWQ oUZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6VxQwlp6mQcA1tHmGqwyLjAiTuflIF8wUdM6z3RS/NE=; b=McprKtlIWBjjuDECRqBEpvOrbYK1i3Nq3wAdC1TPGUzrsORRuvi9ASEeORtDV7R59k hm7GN3Yr2j7Y4uPSlto+x7UYntoeHT2uup+hFwzSdr2KRlXdf92OTCYN+L7/tGWzmQSD Gg3Moh5yAGKrW5UkHcR0O1XAs+WPIH2WbZFqcpw7Uy+ecWS2IaNB6U9H6NEMUTT1nnU8 UBn3uZlAOZnSn6em5WnxL6OxXdZBA06JbFG6/5fQ2j+7bde0iwap/8LPqy4R53YwEswm 61GgfUL1aNQdbMqh57grx6B5ASBmFHlyA9znddnneskLDTUq07jsK46JcvSVIicwiLPD sMQA== X-Gm-Message-State: AN3rC/6H3EKw2zXI197/SXnLoaLfo1UVapxojMAu5r78eA9LStoFfn3h p81B5GCWkZ36ErUSQMt77HtnlJCLsigv X-Received: by 10.37.15.213 with SMTP id 204mr5475406ybp.127.1493843232776; Wed, 03 May 2017 13:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 13:27:11 -0700 (PDT) In-Reply-To: <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 13:27:11 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a113f5ae63d87af054ea47b17 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:29:13 -0000 --001a113f5ae63d87af054ea47b17 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni wrote: > The kind of application whose security requirements preclude use of RFC > 5077 > session tickets can and should likely also avoid both 0-RTT and session > resumption entirely. I don't agree with this. Why should users of mobile devices, to pick one example, have to choose between speed and the extra risk of data disclosure for their requests and passwords? Second-guessing the server's design by looking at ticket sizes seems rather > contrived. > It's not a second guess. If the ticket size is smaller than the RPSK, then it provably can not have been self-encrypted. But I agree that it says nothing about the server-side security. They might be posting the keys to twitter. -- Colm --001a113f5ae63d87af054ea47b17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
The kind of = application whose security requirements preclude use of RFC 5077
session tickets can and should likely also avoid both 0-RTT and session
resumption entirely.=C2=A0

I don't agre= e with this. Why should users of mobile devices, to pick one example, have = to choose between speed and the extra risk of data disclosure for their req= uests and passwords?

Second-guessing the server's design by looking at ticket sizes seems ra= ther
contrived.

It's not a second guess.= If the ticket size is smaller than the RPSK, then it provably can not have= been self-encrypted. But I agree that it says nothing about the server-sid= e security. They might be posting the keys to twitter.=C2=A0

--
Colm
--001a113f5ae63d87af054ea47b17-- From nobody Wed May 3 14:22:38 2017 Return-Path: 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 F1012129B4C for ; Wed, 3 May 2017 14:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 CqBGyA7IGugA for ; Wed, 3 May 2017 14:22:35 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB101200C1 for ; Wed, 3 May 2017 14:20:51 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 06BADA004936; Wed, 3 May 2017 14:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=uexOx8p+1nScdqi7U5I+Hqi4GfE=; b=X8DmTEkpnkh aG5uDeAF+u8+nzLHrrT6VjZ1ZZpxmx3zOx7IinESbW4b5haStL3UQDK4t3BPOlxT NSUcpi78aQcFOvWV0IX4hLnbheBVoUi+c9RGseWIcLlnIPlrZ9ovB5LFG4DWS6A5 9nxx7bveMz1KBz77oKB8lAF2VEMu+Yow= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 971C5A004935; Wed, 3 May 2017 14:20:50 -0700 (PDT) Date: Wed, 3 May 2017 16:20:48 -0500 From: Nico Williams To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Cc: TLS WG Message-ID: <20170503212046.GT10188@localhost> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <20170503193517.GS10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:22:37 -0000 On Wed, May 03, 2017 at 01:19:35PM -0700, Colm MacC=E1rthaigh wrote: > On Wed, May 3, 2017 at 12:35 PM, Nico Williams > wrote: > > No, please don't remove the obfuscated ticket age. Either make it > > encrypted or leave it as-is. >=20 > If it is to be encrypted, say AEAD'd, it needs to be encrypted under a = key > that the client and server share; because the client needs to modify th= e > age before sending. Moving the age to its own message, post Client-Hell= o, > could solve that - so it comes out of the ticket. Naturally. That's why we have ticket session keys. > That scheme is a bit weird and circular: the server would have to "use"= the > ticket to derive a key that decrypts the age, to then decide if it shou= ld > "really use" the ticket for 0-RTT data. That seems pretty convoluted to= me > - could be a fairly complicated security proof. It's what Kerberos has been doing for decades. RFC4120 (before that RFC1510). > > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (ma= ybe > > > not in the ticket itself, but somewhere in the handshake), can only= be > > used > > > once. > > > > No. Give advice. Do not remove these features. >=20 > I think the can only be used once for 0-RTT needs to be firm. Otherwise > 0-RTT mode is insecure. I don't agree: the application may not care. > > > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in siz= e, to > > > prevent self-encryption. > > > > I don't grok this. > > >=20 > Self-encrypting tickets require STEKs and all of their problems. [...] Can you elaborate? (I don't follow TLS WG that closely. I'm from KITTEN WG.) Nico --=20 From nobody Wed May 3 14:28:40 2017 Return-Path: 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 67E7A129B9D for ; Wed, 3 May 2017 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 gtJ0_es6mF2J for ; Wed, 3 May 2017 14:28:36 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E83129BF8 for ; Wed, 3 May 2017 14:26:50 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id k11so1135927ywb.1 for ; Wed, 03 May 2017 14:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IWufT7w4aMCKdfjcEEeETqOtaxH/0/J2XY2SQm4gfe0=; b=prrM4cNCbJlyRrtFE+ichfsg70jZCxbNXw1rrIQJPALwTy7vRvo9HdHxWxgBsL+mrz 5D59mC8YzfyRE/7IrVH6AP7Ovyb5uf4NPtf2/mDBno9bQcyDz6o4aANzSu9Ye1NAYoE+ hSvrF1XfKLP+C1gP/V5SVh1ggLAbWUZ0yKtiL1KV7GgfFTW72Wgx7l0IVWwGskijn40y F35/5s5ir4X6YxV14+TXzAC50t4F3B6D2l6+fkZo530GIpQHy3zahgf571UyYzCgj5iD b5f3XzXzxqyCo/EVG43BBYzHEmMIjvvbPUWqcYVltm2TsFdXxu6ttJ07P1vX4JZjIjUp gx+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IWufT7w4aMCKdfjcEEeETqOtaxH/0/J2XY2SQm4gfe0=; b=ONRS+dwQg3yVy6BmVa76wPajAetFyuwDHmVOTxfTNYBjPb7dmBObjHK8Og1cuZuCaL qQK3+Qqhgp8OTKSw6geSV5BKHgMczFHJJAiDdDdMY9Ksx23vbwP4XyFzWgfB0TJfGuH+ bnaBPtY5k+//x0tKC9awDmdqAebkMEWq1leOvxNMOSnPk6vj4eVzyIUo0fiavEOevnrD oqqFXPtyY/v4caoYObGaVfGjcKGUaykrjAsNKS2ibXpSyGw0dFkHCkxFHFyhRc/MqrOJ NVqxYepIQsXJt6kVI9ELTJbb4rBViQM1wPZTQOkW3Gc5XHTNY/P0nT/J6f/gRJfSap/R QaVA== X-Gm-Message-State: AN3rC/6+2v4eKPW8cXikCpkapvJrnHg/nVhLvINsmgaB7iujBXtGP77z 6WhrRxykbz3h5o+oDBr97FVgDBlIcQ== X-Received: by 10.129.157.142 with SMTP id u136mr3130349ywg.323.1493846810021; Wed, 03 May 2017 14:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 14:26:49 -0700 (PDT) In-Reply-To: <20170503212046.GT10188@localhost> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <20170503193517.GS10188@localhost> <20170503212046.GT10188@localhost> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 14:26:49 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary=94eb2c0b68aa75eee3054ea550f7 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:28:38 -0000 --94eb2c0b68aa75eee3054ea550f7 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 2:20 PM, Nico Williams wrote: > It's what Kerberos has been doing for decades. RFC4120 (before that > RFC1510). > I'll take your word for it! > > > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age > (maybe > > > > not in the ticket itself, but somewhere in the handshake), can only > be > > > used > > > > once. > > > > > > No. Give advice. Do not remove these features. > > > > I think the can only be used once for 0-RTT needs to be firm. Otherwise > > 0-RTT mode is insecure. > > I don't agree: the application may not care. > No, it's still insecure ... because it may matter to the application, and worse still the application owner may not even realize that. The existence of some rare environments where one can truly, deeply, understand the idempotency and side-effect problems and fully reason about their implications does not invalidate that. For security, we must assume the worst, not hope for the best. Also: rejecting duplicates is safe in both environments. The main downside is the cost to operators, but I'm not sympathetic to an argument that costs should be cut by pushing significant risk downstream. > > > > > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in > size, to > > > > prevent self-encryption. > > > > > > I don't grok this. > > > > > > > Self-encrypting tickets require STEKs and all of their problems. [...] > > Can you elaborate? (I don't follow TLS WG that closely. I'm from > KITTEN WG.) > Sure ... https://www.ietf.org/mail-archive/web/tls/current/msg23100.html -- Colm --94eb2c0b68aa75eee3054ea550f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 2:20 PM, Nico Williams <nico@cryptonector.c= om> wrote:
It's what Kerberos has bee= n doing for decades.=C2=A0 RFC4120 (before that
RFC1510).
=C2=A0
I'll take your word for= it!
=C2=A0
> > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age= (maybe
> > > not in the ticket itself, but somewhere in the handshake), c= an only be
> > used
> > > once.
> >
> > No.=C2=A0 Give advice.=C2=A0 Do not remove these features.
>
> I think the can only be used once for 0-RTT needs to be firm. Otherwis= e
> 0-RTT mode is insecure.

I don't agree: the application may not care.

No, it's still insecure ... because it may matter to t= he application, and worse still the application owner may not even realize = that. The existence of some rare environments where one can truly, deeply, = understand the idempotency and side-effect problems and fully reason about = their implications does not invalidate that. For security, we must assume t= he worst, not hope for the best.=C2=A0

Also: rejec= ting duplicates is safe in both environments. The main downside is the cost= to operators, but I'm not sympathetic to an argument that costs should= be cut by pushing significant risk downstream.=C2=A0
=C2=A0

> > > Type 2.2 - Same as 2.1, but required to be smaller than RPSK= in size, to
> > > prevent self-encryption.
> >
> > I don't grok this.
> >
>
> Self-encrypting tickets require STEKs and all of their problems= . [...]

Can you elaborate?=C2=A0 (I don't follow TLS WG that closely.=C2=A0 I&#= 39;m from
KITTEN WG.)


--
Colm
--94eb2c0b68aa75eee3054ea550f7-- From nobody Wed May 3 15:06:01 2017 Return-Path: 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 54F27128D16 for ; Wed, 3 May 2017 15:06:00 -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] 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 X0d8KfK6uCa4 for ; Wed, 3 May 2017 15:05:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1EB1293E1 for ; Wed, 3 May 2017 15:04:46 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id F01557A32F1 for ; Wed, 3 May 2017 22:04:45 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 18:04:45 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:06:00 -0000 On May 3, 2017, at 4:27 PM, Colm MacC=C3=A1rthaigh = wrote: > On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni = wrote: >=20 >> The kind of application whose security requirements preclude use of = RFC 5077 >> session tickets can and should likely also avoid both 0-RTT and = session >> resumption entirely.=20 >=20 > I don't agree with this. Why should users of mobile devices, to pick = one example, > have to choose between speed and the extra risk of data disclosure for = their requests > and passwords? Their security requirements don't preclude use of RFC 5077 session = tickets, they've been using them all along, and will continue to do so for the = majority of destinations that will take quite some time to upgrade to TLS 1.3. As you might recall, I don't agree that STEKs are fundamentally less = secure than remote session caches, I rather suspect that sensibly implemented = STEKs are safer. [ I do concede that the current OpenSSL implementation leaves too much = of the responsibility of doing STEKs right to applications, and I will = endeavour to fix that. It is not especially difficult to implement a default-on key = rotation mechanism. ] >> Second-guessing the server's design by looking at ticket sizes seems = rather >> contrived. >=20 > It's not a second guess. If the ticket size is smaller than the RPSK, = then it > provably can not have been self-encrypted. But I agree that it says = nothing > about the server-side security. They might be posting the keys to = twitter. As you yourself concede it is not the size that matters. It is a very = marginal indication of the security of the remote session. The server may wish = to decorate the session id with additional data (say which data-centre issued the = session) and fail your test, and yet be doing the type of session caching you're = asking for. The client should either trust the server to cache sessions = correctly (this would be the default client behaviour in most cases), or it can choose = to forgo session re-use. Feel free to malign bad implementations of STEKs, but the basic = mechanism is sound. --=20 Viktor.= From nobody Wed May 3 15:30:56 2017 Return-Path: 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 C071E129441 for ; Wed, 3 May 2017 15:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 vhI5q_xgaTQW for ; Wed, 3 May 2017 15:30:52 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A195012025C for ; Wed, 3 May 2017 15:29:18 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id k11so1746444ywb.1 for ; Wed, 03 May 2017 15:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=G8/PPbhprRJ+83lBsBi2E9N6zUN8kGjRxXQQA+zpryk=; b=X/ldinedzpvlJ83IrHuphwlPj2Ns04+87jjjtyqoddhpYDE+RuOj6Vkcz4u9cm6z1T MVJS0r4pAlizmfjxJzv1XuLo2G0AcKVdssTvB/UMcIQU6AkV6oeHa+OhgLZD/e+TK6Xc WkTNcMuqqRjkXdj6BM48B/c8fyMQAUMMRJjPJaBtb6yq3tiSnyWycy2iEAm0zCsCmGU5 jyqxBMheSFT9TqoaHe09XhPNSVCXIloh+hFXw6FrTFD4hzDqq6Sy8bgWZ7j+C/W+AkVq rHpluYHNF9qhHCbE4X2VKUok2a1AV8vb/5XF4ifXXbvmM8utV3mXoBaNBXPrGDAQwSC9 Bipw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=G8/PPbhprRJ+83lBsBi2E9N6zUN8kGjRxXQQA+zpryk=; b=V4JBpI/AEGJX9xtDMU8+L09J+PnfGCg6JiVB+maohW8r7aP6q/cekcamqG1G5XvEdC 7Vw6FB+iWS1vLKdAWV8xQXpG9l00EG5tbkfwwzO2NyV6G2JN3kFM5ub9RiYOdO8EZe22 f4CdzQ2nqBp3mBFTnwLsiq639swXjQ+ome83IG4voVIrztcwJGDhyA2VcSOZQcYKpekY dapXZ0yYEjOuwOHC15RoPWPlrYywyjdCEkZaNEK6UWAGRRhOW7FNSRcYN+n0M/wMIh9r BeIWUcSGXvA/WogOcd3PBBV0iJl3JwwupQaAbYz03qjWt9+55ge080/lQw4c28hKeiw1 kOHw== X-Gm-Message-State: AN3rC/6aAqqeKFM/9Uvz+B6LBXCFULei2nBo1apttMoZBUwyIMQ/La78 0WtawqwCQ/OQPmFRUJftZuCgq49xf/vVqXs= X-Received: by 10.13.238.65 with SMTP id x62mr30765220ywe.122.1493850557553; Wed, 03 May 2017 15:29:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 15:29:16 -0700 (PDT) In-Reply-To: <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 15:29:16 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=94eb2c034d8cd51a7a054ea62f17 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:30:55 -0000 --94eb2c034d8cd51a7a054ea62f17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 3:04 PM, Viktor Dukhovni wrote: > > On May 3, 2017, at 4:27 PM, Colm MacC=C3=A1rthaigh wr= ote: > > > On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni > wrote: > > > >> The kind of application whose security requirements preclude use of RF= C > 5077 > >> session tickets can and should likely also avoid both 0-RTT and sessio= n > >> resumption entirely. > > > > I don't agree with this. Why should users of mobile devices, to pick on= e > example, > > have to choose between speed and the extra risk of data disclosure for > their requests > > and passwords? > > Their security requirements don't preclude use of RFC 5077 session ticket= s, > they've been using them all along, and will continue to do so for the > majority > of destinations that will take quite some time to upgrade to TLS 1.3. > > As you might recall, I don't agree that STEKs are fundamentally less secu= re > than remote session caches, I rather suspect that sensibly implemented > STEKs > are safer. > I'm not sure how any of that is relevant. Mobile users, like everyone else, appreciate speed; they'll want to use 0-RTT. I'm sure they also appreciate their data being less at risk, so forward secrecy is good for them too. I'm saying they should be able to get both. Again, you can combine the security properties of a STEK with a cache if you want, by encrypting the cache entries the same way you would use a STEK. > > [ I do concede that the current OpenSSL implementation leaves too much of > the > responsibility of doing STEKs right to applications, and I will endeavour > to > fix that. It is not especially difficult to implement a default-on key > rotation > mechanism. ] > Just an aside related to that; it can be useful to fuzz ticket lifetimes a bit so all of the tickets from a STEK don't expire at exactly the same time. That can lead to a lot of painful renegotiations happening at once. >> Second-guessing the server's design by looking at ticket sizes seems > rather > >> contrived. > > > > It's not a second guess. If the ticket size is smaller than the RPSK, > then it > > provably can not have been self-encrypted. But I agree that it says > nothing > > about the server-side security. They might be posting the keys to > twitter. > > As you yourself concede it is not the size that matters. It is a very > marginal indication of the security of the remote session. The server may > wish to decorate the session id with additional data (say which data-centre issued the > session) > and fail your test, and yet be doing the type of session caching you're > asking > for. The client should either trust the server to cache sessions > correctly (this > would be the default client behaviour in most cases), or it can choose to > forgo > session re-use. > True. > Feel free to malign bad implementations of STEKs, but the basic mechanism > is > sound. > "sound" goes too far. Pervasive forward secrecy is one of the central security goals of modern cryptography, some schemes go so far as to bake in very frequent key agreement and ratcheting. STEKs aren't compatible with this goal. They may be acceptable operationally today, but I think they must be borrowed time if the central goal is meaningful. --=20 Colm --94eb2c034d8cd51a7a054ea62f17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 3:04 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
On May 3, 2017, at 4:27 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:

> On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>
>> The kind of application whose security requirements preclude use o= f RFC 5077
>> session tickets can and should likely also avoid both 0-RTT and se= ssion
>> resumption entirely.
>
> I don't agree with this. Why should users of mobile devices, to pi= ck one example,
> have to choose between speed and the extra risk of data disclosure for= their requests
> and passwords?

Their security requirements don't preclude use of RFC 5077 sessi= on tickets,
they've been using them all along, and will continue to do so for the m= ajority
of destinations that will take quite some time to upgrade to TLS 1.3.

As you might recall, I don't agree that STEKs are fundamentally less se= cure
than remote session caches, I rather suspect that sensibly implemented STEK= s
are safer.

I'm not sure how any of = that is relevant. Mobile users, like everyone else, appreciate speed; they&= #39;ll want to use 0-RTT. I'm sure they also appreciate their data bein= g less at risk, so forward secrecy is good for them too. I'm saying the= y should be able to get both. Again, you can combine the security propertie= s of a STEK with a cache if you want, by encrypting the cache entries the s= ame way you would use a STEK.=C2=A0
=C2=A0

[ I do concede that the current OpenSSL implementation leaves too much of t= he
responsibility of doing STEKs right to applications, and I will endeavour t= o
fix that.=C2=A0 It is not especially difficult to implement a default-on ke= y rotation
mechanism. ]

Just an aside related to t= hat; it can be useful to fuzz ticket lifetimes a bit so all of the tickets = from a STEK don't expire at exactly the same time. That can lead to a l= ot of painful renegotiations happening at once.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex"> >> Second-guessing the server's design by looking at ticket sizes= seems rather
>> contrived.
>
> It's not a second guess. If the ticket size is smaller than the RP= SK, then it
> provably can not have been self-encrypted. But I agree that it says no= thing
> about the server-side security. They might be posting the keys to twit= ter.

As you yourself concede it is not the size that matters. It is a ver= y marginal=C2=A0indication of the security of the remote session. The serve= r may wish to decorate
the session id with additional data (say which data-centre issued the sessi= on)
and fail your test, and yet be doing the type of session caching you're= asking
for.=C2=A0 The client should either trust the server to cache sessions corr= ectly (this
would be the default client behaviour in most cases), or it can choose to f= orgo
session re-use.

True.
=C2=A0<= /div>
Feel free to malign bad implementations of STEKs, but the basic mechanism i= s
sound.

"sound" goes too far. = Pervasive forward secrecy is one of the central security goals of modern cr= yptography, some schemes go so far as to bake in very frequent key agreemen= t and ratcheting. STEKs aren't compatible with this goal. They may be a= cceptable operationally today, but I think they must be borrowed time if th= e central goal is meaningful.=C2=A0

--
Colm
--94eb2c034d8cd51a7a054ea62f17-- From nobody Wed May 3 15:49:05 2017 Return-Path: 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 6093B126D74 for ; Wed, 3 May 2017 15:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JT45xXn_JERa for ; Wed, 3 May 2017 15:49:02 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B869F126CD6 for ; Wed, 3 May 2017 15:49:01 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id t144so1889810lff.1 for ; Wed, 03 May 2017 15:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R3NQrmmQDwSrPnJdZ/nnx5dV87jG/2w/KTNx/FEFQ9Q=; b=b8sGut/Rh3pEFUS5TCg1w1JZVQCUodzwVkizeHjHE2zenrxo+TSavNc4ivWGPzuEtj H8WA6kMVJ0V+IE1Ecj6LOwwj70hu6jx/k04HYIC/L+nY/RR/3arxCt0cwgj+bra7PrgO 1AJysx+XKgqpGtj7bE+I2z/QWzOcj9lmd6NHM7uMCUaFQIHMLCkXFaq1go0jKgox6JiT U2J1iAMQqfpo+xUCnbqh9cV2apcYcEIojOF1yK8+a3u2I/weetSoRIPwdDIbsRNoVsRt w9IUx0SHCqX9/IkJ4OsfomuBrmdlK6TvDfZvRA3GTxSVltU90oMC4ER8Bx2OLBvg4A0P 6MvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R3NQrmmQDwSrPnJdZ/nnx5dV87jG/2w/KTNx/FEFQ9Q=; b=KewaxD6DMcGiQlRi/Q2MyU1kNNhCFPFlN4Gn8TuCq3ozH2onqlA23YA/8HQCpt0axL 3x1qQ+2yfDnVBpUS3G1NyVSG74Bpsqnalr+zo2QD87d14WYvuOcmWEsgDrCDD2YqPc6S LmY196Y4Ls0h4uRVwEwd4hZgcNXF+xRBl0mPfhgPCwFudQo1EwP+lxTQuyFRCiwFPttN F4JFi+CM1oqi9JY/0Wkatl60/Oojg19Z9kdmDQl1Xib65Vzrl0UhxxVfsf3YdN+GVHQn dJIBktpoAk0KqVkD9NdgwDijxFp8Ysmi5GSMpieJrt9AT4sWo556yPqHKv/ugGooyfx+ ZTVw== X-Gm-Message-State: AN3rC/7Kl77g9MLcAvluZKqZAavvaa1H11UBpSz4myNyOEW6FIW8RPgM n+qETbOWjVUY96EsDe7LbgeEKdBzfDjTJp8= X-Received: by 10.25.76.6 with SMTP id z6mr12600366lfa.172.1493851740057; Wed, 03 May 2017 15:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 15:48:59 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 May 2017 08:48:59 +1000 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] OpenSSL now at draft-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:49:03 -0000 On 4 May 2017 at 02:29, Matt Caswell wrote: > FYI, I have just made the necessary updates to bring the OpenSSL > master branch up to draft-20 compatibility. Please test!! That's timely. I just landed -20 support in NSS. It's on a branch because we're not switch-hitting and we don't want to upgrade Firefox just yet. See https://hg.mozilla.org/projects/nss/shortlog/NSS_TLS13_DRAFT19_BRANCH From nobody Wed May 3 15:56:11 2017 Return-Path: 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 DE6C9126D74 for ; Wed, 3 May 2017 15:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3MljCQLe_PTR for ; Wed, 3 May 2017 15:56:08 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FD612426E for ; Wed, 3 May 2017 15:56:08 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id j1so1011752lfh.2 for ; Wed, 03 May 2017 15:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DROH3iM9RTP92NFo52nQTWpZscqQdDXIdLr67mgRLiw=; b=LLv3W6NLQh5daxZXCGdXgnWcqrfreJji9FwAHjERRpUSpq+AL9SUecRIcqDJ9FYiG/ XYKLewwOTwk7993IoC7H/NTSmy2filPW9qjyCBQIMXpL7gOyTFI2jGV0SExB0woJFrKO 8NoqYQLnweWc/VHvxjhogMCfQmRIlghJlvJf/MdKMPZTh3234h9tMp9ifYbVofmZfHqo UphVeGcAxhoIDcXjWSIIR749OSowK1Z1R/DeqiKQNEB1QCM6KW0TBcsVnEtqkHePwLbd 5W4tNtqFR6mFEmimmktfi3gfYjHahbiXwTJn02g1W6LF5pO9pRydu9yRC7XA5r8JNv7m JKPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DROH3iM9RTP92NFo52nQTWpZscqQdDXIdLr67mgRLiw=; b=XzPuU1IL5gOCw53aQsqt/9Ubf4ebB4h6E5uE3F0ACFwS0575VyMn2o28m6unuZ5ZJB q6XJnWOO8EONMwQjl819mb1k8MPWiHyrqB2VAWd0iTYQVp9u2V8NpuTIBtMgLr20Tuzx WH3Ydysvre0AifwcKkxL79hgtJoI/bnjN5Tk3oMIcugDOfWkvOYRasD+55hdErd6yPC1 dWakeizH8AXGXR7lD3sFVfdTmGgy/OMWzUjGDa3sqs9uiP8ckPEdA5PUM84AEgbWn9VY ZooiOFenRVdKMrvFnX0E2l9y+A3BhzhqBOVPl6ayWdCGgEbvUYDiMqaZnZLIITEqzljs iGJA== X-Gm-Message-State: AN3rC/4wR+8uep7V+2gPgDGM7iVopFDMgVu04Yzs9rztVO9xW+GdwdfP VDBsdCIk4tG0nOs4SCxYONCJoUIBTvM9 X-Received: by 10.46.0.23 with SMTP id 23mr12605853lja.33.1493852166562; Wed, 03 May 2017 15:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 15:56:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 May 2017 08:56:05 +1000 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:56:10 -0000 On 3 May 2017 at 22:45, Colm MacC=C3=A1rthaigh wrote: > This is easy to say; the TLS layer is the right place. It is not practica= l > for applications to defend themselves, especially from timing attacks. If you care about these attacks as much as it appears, then you can't reasonably take this position. We've historically done a lot to secure applications at a single point, and we're almost at the end of what we can reasonably do for them at this layer. We need to think more hollistically and acknowledge that applications need to take some responsibility for their own security. From nobody Wed May 3 16:16:55 2017 Return-Path: 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 1C398127876 for ; Wed, 3 May 2017 16:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 ymgZPgij4LVc for ; Wed, 3 May 2017 16:16:51 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3989D12778E for ; Wed, 3 May 2017 16:16:51 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id k11so2131517ywb.1 for ; Wed, 03 May 2017 16:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+CKmUbc4qrobXqzCTbHyw0KC+1HMvAKv6hDzSj9pVs=; b=K7Bd8L02jXKGoF/zzAGEmPgtDmyzwzpvAnwdlv2X38XnoUyJNX5yfmZXW1s9Rqg/2d BGucdKey+Cgtge00NRD5V38l67uJR8+A+L0CmumEsKcKyk+JIy3ugaBjQvETUrEfi4R9 HZ2x0Zo7WShl0N4lXDK5f028i55lSbve2nTiXvShNCh+gaml8Fmxl925eV9P/J0jsFqL w4AoxR6ZF9L2Ib0nqyjZSWmTgCy5sauUwTRfZds+SvQvvdpwZqc2woZmWB3yW5gE6YDz pbNd18q/44l5UI/O4F9O/x4oBoeheQHKhv6KVifCNQbVhmqaIii7RZrB+QOjjmScb+j+ QX4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t+CKmUbc4qrobXqzCTbHyw0KC+1HMvAKv6hDzSj9pVs=; b=gkzyu5IjJ7XywlsZnrL7d8+iWAm0zXDV66/mB8ojzpdZyaJ4NKd3hsN8PpCgRA6ZTR NRQjEl4hPXvO/4Wh80TMSpzT8lrnDQy/yEmqMI60LfyoACCAuNAploR9XNAyiUiWI5Rr 3qsILwGC8EOSdBeFLg+TyC9wWZwwhZD1DHAVwTzH86ceFV3kgDbwhNdnZY4nR9yuwfJ2 AaoWRYKmmLtgEIXSDVH3ITSFUjMhatVIRImalPbo9KGHpFp15yxHiwGrxFdmOuriGTWZ fpZBo6mx5bDGMdZhvgNWHBz+ugwNXARrSNxNrxbkaA7kGlAy0R2h20iSTNGw2wD4lfOH /hFw== X-Gm-Message-State: AN3rC/7jWjc+3oYaIwr0AiZ9pDtKiZ7Av5hKwI5N9W73d8A1V2KvYIvF 5LCkQRz2TT0BzyVefCTNv5eS7Mlmbw== X-Received: by 10.129.157.142 with SMTP id u136mr3529194ywg.323.1493853410466; Wed, 03 May 2017 16:16:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 16:16:49 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 16:16:49 -0700 Message-ID: To: Martin Thomson Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b68aae0ee93054ea6d9c7 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:16:53 -0000 --94eb2c0b68aae0ee93054ea6d9c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 3:56 PM, Martin Thomson wrote: > On 3 May 2017 at 22:45, Colm MacC=C3=A1rthaigh wrote: > > This is easy to say; the TLS layer is the right place. It is not > practical > > for applications to defend themselves, especially from timing attacks. > > If you care about these attacks as much as it appears, then you can't > reasonably take this position. An analogy may help here. TLS has always offered anti-replay, it is one of our core security guarantees, and the assumption that it is there is subtly baked in to many applications. Suppose we wanted to remove a different security guarantee: integrity protection/tamper-proofing. Suppose we decided to offer a fast "No MAC" mode for streamed uploads, it is faster, more stream-y (no need to wait for each record to be complete), and TLS is really mostly about secrecy. But to be "safe" we decide that it's only on optionally and sometimes, and we always have to tell the application which data may have been tampered with. The application can use its own MACing, or FECing, or whatever, and really it should have been doing this from the days of plaintext HTTP, right!? It's all the application's responsibility - we say, they can deal with it [*] Except MACing is hard, and they run in to Lucky13 all over again, or just use MD5 because they don't know any better, and so on. Or worst of all: a middle box decides to enable it on the front-end, with no knowledge to the backend about what's happening. In my view, this arrangement would plainly be crazy. We wouldn't consider it. Instead, we provide protection for them using layering principles, and TLS provides protections that TLS experts are good at. And yet we do consider all of this for replay. I think it's because collectively we haven't seen just how hard a problem idempotency and application-level side-effects are and we are less familiar with the risks. In the review, I've included 5 real attacks to illustrate that problems are real. Several of them I can't see how to mitigate them at application level, and I've been checking with experts on distributed systems. How would you mitigate the throttling problem (attack 3) or the timing problem (attack 4) on say a JVM object cache? > We've historically done a lot to > secure applications at a single point, and we're almost at the end of > what we can reasonably do for them at this layer. We need to think > more hollistically and acknowledge that applications need to take some > responsibility for their own security. > No we don't. Servers can prevent replay. --=20 Colm --94eb2c0b68aae0ee93054ea6d9c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 3:56 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 3 May 2017 at 22:45, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
> This is easy to say; the TLS layer is the right place. It is not pract= ical
> for applications to defend themselves, especially from timing attacks.=

If you care about these attacks as much as it appears, then you can&= #39;t
reasonably take this position.=C2=A0

An an= alogy may help here. TLS has always offered anti-replay, it is one of our c= ore security guarantees, and the assumption that it is there is subtly bake= d in to many applications.=C2=A0

Suppose we wanted= to remove a different security guarantee: integrity protection/tamper-proo= fing. Suppose we decided to offer a fast "No MAC" mode for stream= ed uploads, it is faster, more stream-y (no need to wait for each record to= be complete), and TLS is really mostly about secrecy. But to be "safe= " we decide that it's only on optionally and sometimes, and we alw= ays have to tell the application which data may have been tampered with.=C2= =A0

The application can use its own MACing, or FEC= ing, or whatever, and really it should have been doing this from the days o= f plaintext HTTP, right!? It's all the application's responsibility= - we say, they can deal with it [*]

Except MACing= is hard, and they run in to Lucky13 all over again, or just use MD5 becaus= e they don't know any better, and so on.=C2=A0 Or worst of all: a middl= e box decides to enable it on the front-end, with no knowledge to the backe= nd about what's happening.=C2=A0

In my view, t= his arrangement would plainly be crazy. We wouldn't consider it. Instea= d, we provide protection for them using layering principles, and TLS provid= es protections that TLS experts are good at.=C2=A0

And yet we do consider all of this for replay. I think it's because co= llectively we haven't seen just how hard a problem idempotency and appl= ication-level side-effects are and we are less familiar with the risks. In = the review, I've included 5 real attacks to illustrate that problems ar= e real. Several of them I can't see how to mitigate them at application= level, and I've been checking with experts on distributed systems. How= would you mitigate the throttling problem (attack 3) or the timing problem= (attack 4) on say a JVM object cache?
=C2=A0
We've historically done a lot to
secure applications at a single point, and we're almost at the end of what we can reasonably do for them at this layer.=C2=A0 We need to think more hollistically and acknowledge that applications need to take some
responsibility for their own security.

= No we don't. Servers can prevent replay. =C2=A0

--
<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Colm
--94eb2c0b68aae0ee93054ea6d9c7-- From nobody Wed May 3 16:26:28 2017 Return-Path: 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 636A5127873 for ; Wed, 3 May 2017 16:26:27 -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] 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 7jCMN0xDWeBN for ; Wed, 3 May 2017 16:26:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB21D12778E for ; Wed, 3 May 2017 16:26:25 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D41557A32F1 for ; Wed, 3 May 2017 23:26:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 19:26:23 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <8EF519E7-BD1E-4449-A1DF-F89CD3C68760@dukhovni.org> References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:26:27 -0000 > On May 3, 2017, at 6:29 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > Just an aside related to that; it can be useful to fuzz ticket = lifetimes a > bit so all of the tickets from a STEK don't expire at exactly the same = time. > That can lead to a lot of painful renegotiations happening at once. More than "a bit". In Postfix session tickets have a constant lifetime = regardless of whether they were issued at the beginning of end of the current STEKs = duration is the STEK encryption key. This works, because each STEK is retained = as a decryption-only key for a second "lifetime" while the next key is = employed to encrypt (and decrypt) new sessions. There is no clustering of session expirations. The plan is to do the = same in the default-on key rotation for OpenSSL. --=20 Viktor. From nobody Wed May 3 17:19:48 2017 Return-Path: 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 0E439129407 for ; Wed, 3 May 2017 17:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ut_TUjw9kDFF for ; Wed, 3 May 2017 17:19:43 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDF1128D6F for ; Wed, 3 May 2017 17:19:43 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id s22so1310005ybe.3 for ; Wed, 03 May 2017 17:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SWKABWe0Dcm8JGFP+mAoB+Ym5a44uw0nORKYy8wOViI=; b=G8Bejpnn19r5LKJ+trUt7U78PCFi1OqUihFPNpMxSDTE9Yi/+ve5vc2MIx+XwNH009 ONWYnEhldJ7BlQR2VYTtMFxslzSLEHKI6asXAAMAfWyWb4WlIHe1NFexpm1NEd6OoTaP 0Mfhy5q0wzUPrhdKJlB7JGMrO062eqrQ0stzMN/b8DRzdfofz2JT+qXI7M2VTrimsjMx RUE8m26gxmms1pquxRCUeYcrY8jwIsC9wXsVrJy9v0F4Qmvdq4Hwvurn7Qd1r7hn8qD7 GJpBaCrc0SijHiY4pUW2EbtCKIpmaaHz0CWJp1qZH8PwN7bS0uMnEWPXUZ+PwYCQzDP/ sOog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SWKABWe0Dcm8JGFP+mAoB+Ym5a44uw0nORKYy8wOViI=; b=kChpTh+2J+n/bgSkL7bpv8AeWAdFjJypDHG8pesDH1vnZ85/PTH0wsJnp3m5Y6i2pK DKjz0U7YS2sOCVD1C/JQaruipTwcQde6Zxr08eI+taDMkJQDRORMQ0woawTVrOnJBpuM gU2+W9cxCWGDpATxCwiCX7YKVFMdycHlcwnJW5TCLD+9XLchuww//ZSEYyPrCdphs1ZK w7jmK/VnAidqpBjTostjfNUQlGCqlj1Co+5YSD/u6MAEGJzA9AydtclsONIwDDUIRXiG 32JnhEWvfaQqSRcl7GJ2w7FF0VvOdZD5RgKqtCAUkGkC7po+KItrrEGRHrVhInqAQv8S M88w== X-Gm-Message-State: AN3rC/6nEwTPutfhQtfllNUR7suMiZtrXXZrVwW0XT5wzXdABSDJYedd ZNr1szzqGiDYS5xaAIWuVu5s9fsIDOCI X-Received: by 10.37.117.134 with SMTP id q128mr31398427ybc.170.1493857182656; Wed, 03 May 2017 17:19:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.70 with HTTP; Wed, 3 May 2017 17:19:41 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Wed, 3 May 2017 17:19:41 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114bbbaeb81abe054ea7ba34 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:19:45 -0000 --001a114bbbaeb81abe054ea7ba34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 4:16 PM, Colm MacC=C3=A1rthaigh = wrote: > > No we don't. Servers can prevent replay. > Replay prevention looks straight forward with a server-side cache. This may not work well for the top 1,000 web sites, but I bet it will work well for the bottom 1 billion sites. Personally I think the important thing is for popular HTTP server software to implement replay protection for TLS 1.3 0-RTT by default. Admins at literally millions of small companies are going to want to enable this new 0-RTT hotness. That part should be made easy - say one line in a config. Enabling 0-RTT without replay protection should be harder. Bill --001a114bbbaeb81abe054ea7ba34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 3, 2017 at 4:16 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net&= gt; wrote:

<= /div>
No we don't. Servers can prevent replay.=C2=A0

Replay prevention looks st= raight forward with a server-side cache.=C2=A0 This may not work well for t= he top 1,000 web sites, but I bet it will work well for the bottom 1 billio= n sites.=C2=A0 Personally I think the important thing is for popular HTTP s= erver software to implement replay protection for TLS 1.3 0-RTT by default.= =C2=A0 Admins at literally millions of small companies are going to want to= enable this new 0-RTT hotness.=C2=A0 That part should be made easy - say o= ne line in a config.=C2=A0 Enabling 0-RTT without replay protection should = be harder.

Bill
--001a114bbbaeb81abe054ea7ba34-- From nobody Wed May 3 17:25:41 2017 Return-Path: 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 754FF129423 for ; Wed, 3 May 2017 17:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ycL-xpnw8Fks for ; Wed, 3 May 2017 17:25:39 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0309A129409 for ; Wed, 3 May 2017 17:25:39 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h4so2576667lfj.3 for ; Wed, 03 May 2017 17:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vynZ2gfOoB2Ip/tEb8SehS/1db2MGSXsK4fHalqWWw4=; b=rOkcK6gICVjfXMwIAqRmhYyav2IyZCenm27KmZ4KM0V5v6+qnhdWM3AI6wtL43QolR D1TUfYKjq5dDZ7+pmhT9FuMX+XtmwNiBu8a581rJ7BV2UonVc6y0qH4z4zxa9U8lKob4 r/CpcF/T0MjXfmDBrzI2ll5lnHb1PxQ4rUWneVGx3HyeAQTugRjO/Ndlyig38DrSgbjr Jvbk4loHk+KN6y90GWoEZCd0zpxnHTdhCqIPb8LeEfLTDoDGnIbShBYxr82xF95+REZO iW1DrKoGcCva+k/LpLgQeofM1Xsd8gC1VtC5MmlaKBAhhUsbTSQtlCBMCQHMDV/NV7WI RmQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vynZ2gfOoB2Ip/tEb8SehS/1db2MGSXsK4fHalqWWw4=; b=iPN/XZustecCdPdvEFwhpmNk33rY3gmgcHDgz2dQwy1IMtKUiksi8b7au7kZXR2+qB N0QJ1HTZs5J8pZ/uOdbXgC6pzjHQ89a7o3LS41RVpDzLTgrXAkd89e/amohuzo1vT62T OgqnGzID18+gGBC4V8ZRev3CTXFUjjSAPIcMesTTYr3Tgd3Y1GiI0/sIlQoqJTSzx3pm THCcFRPBdbR5jW5NlwBULpKBPzEnOWXc8mTi2wzioenbqu5pQJqi/LTlAa0fLhrTMhys vJuxdBm+i9vdf1jM/pJ2qJCgWOFqxBfh5YT2tRA5RzIfNl23dPFZFHZtVuc9Lx9sWNDF oMEQ== X-Gm-Message-State: AN3rC/65knP5PoKlUpiCcTFt5LIIu389Injwxd7EK/vj7HPljkjkiVrv 3Selmy/XREOhaFrAHm/8Kppgy3fryw== X-Received: by 10.25.158.147 with SMTP id h141mr13555646lfe.130.1493857537297; Wed, 03 May 2017 17:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 17:25:35 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 May 2017 10:25:35 +1000 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:25:40 -0000 On 4 May 2017 at 09:16, Colm MacC=C3=A1rthaigh wrote: >> We've historically done a lot to >> secure applications at a single point, and we're almost at the end of >> what we can reasonably do for them at this layer. We need to think >> more hollistically and acknowledge that applications need to take some >> responsibility for their own security. > > No we don't. Servers can prevent replay. I was responding to an overly broad statement you made. In the discussion you also talk about timing side-channels and other ways in which information can leak. Nothing we do at the TLS layer will prevent those from being created in applications. Also, it might pay to remember that this is part of a larger context. Applications routinely retry and replay; if they didn't, users would. From nobody Wed May 3 17:50:39 2017 Return-Path: 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 B453B129465 for ; Wed, 3 May 2017 17:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 UpAZV_rXc5FU for ; Wed, 3 May 2017 17:50:36 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECD21250B8 for ; Wed, 3 May 2017 17:50:36 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id 203so2824422ywe.0 for ; Wed, 03 May 2017 17:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JVOz+fn6bu9u2DtljW9mpZJFMrXhUtVCtERmztvSf9I=; b=UPHU+B6GXwNwsubt3lUZ26vfPc43m4n2BHxDR10KHQOdqznctrqOgmV3UADBhv8UEr L/8hOCAJTd3KP6HN17NsE8bY0Eg5t7y4AT7KYZgNfd3NlxFPncoZbM2+rvWUsAXRMlgC WvoBcUvyK/Rds298uVqeNNXgjLFVkqydwftEyX3MXjs8XE72AzFOkpj+iOycpsLmWIda 4eGlEOG7aEULFhkYZHk6d1F8uT5cX0V4/dY5vNN2Z+A3TNaHy+n7OW0Cw3RvhKWYG/vU iuWmZxxpCuM7A2ExCcVBRZlHvPKnUHsDo/3za9sKSCvEXIh5ur3zgWWUCjw8m7CGBUIq Sqyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JVOz+fn6bu9u2DtljW9mpZJFMrXhUtVCtERmztvSf9I=; b=Huxds2hvuZa+bpnMBCJDA72LfKJb8EcLOGypmQdugQpRxZrLvHQ/rbauoMjStIxPnM 2KFnp6/yz5Ebjm9Bna2POWQ/DemtdP8JfH8FVJciW0BbgLSFlmA3wsHIU50m1p3mD9yS vaLxgFSkLCZblaBkhU7P6qBHoSDnqNuqbSIewqD29bCHetUJHZGWD+Iqba91wwJo1TZm n6xOWpe/aDH3iri+yRCg1B4+n5UEjgMfob4W4F2+U4fcd4Qzgb2M3wcskQr1MlT3Spdu b+DUupt+TQ2sziGASzNWgblc9wc2bi+NRHh7EvthzsnuyoXIQxqtSaImTNQw6EW45Lw5 P0Vw== X-Gm-Message-State: AN3rC/4DjmWdc+Nwr9MAztFCKARHCIGdBjGsupn254emrV1GWPzamwOi TLl8chuYMGZNIcGwaXMbfB0FRuqnIA== X-Received: by 10.129.53.207 with SMTP id c198mr34771903ywa.14.1493859035572; Wed, 03 May 2017 17:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 17:50:34 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 17:50:34 -0700 Message-ID: To: Martin Thomson Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1142e7ec2908ee054ea82956 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:50:38 -0000 --001a1142e7ec2908ee054ea82956 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 5:25 PM, Martin Thomson wrote: > I was responding to an overly broad statement you made. In the > discussion you also talk about timing side-channels and other ways in > which information can leak. Nothing we do at the TLS layer will > prevent those from being created in applications. > Sure, but things we're doing at the TLS layer can make it much worse, as in this case. I don't think we can make attacks easier. > Also, it might pay to remember that this is part of a larger context. > Applications routinely retry and replay; if they didn't, users would. > In the larger context, not all HTTP calls are coming from user actions, or from clients that retry in that way. Some clients need to be careful, precisely to achieve idempotency or safety. The review details the reasons why, and also why it is impractical for actors to separate out these cases and simple "not use" 0-RTT, due to how layers work and systems interoperate. -- Colm --001a1142e7ec2908ee054ea82956 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 5:25 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
I was re= sponding to an overly broad statement you made.=C2=A0 In the
discussion you also talk about timing side-channels and other ways in
which information can leak.=C2=A0 Nothing we do at the TLS layer will
prevent those from being created in applications.

=
Sure, but things we're doing at the TLS layer can make it = =C2=A0much worse, as in this case. I don't think we can make attacks ea= sier.=C2=A0
=C2=A0
Also, it might pay to remember that this is part of a larger context.
Applications routinely retry and replay; if they didn't, users would.

In the larger context, not all HTTP call= s are coming from user actions, or from clients that retry in that way. Som= e clients need to be careful, precisely to achieve idempotency or safety. T= he review details the reasons why, and also why it is impractical for actor= s to separate out these cases and simple "not use" 0-RTT, due to = how layers work and systems interoperate.=C2=A0

--
Colm
--001a1142e7ec2908ee054ea82956-- From nobody Wed May 3 17:51:43 2017 Return-Path: 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 1A5431250B8 for ; Wed, 3 May 2017 17:51:41 -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] 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 wsnODS5Gmn3E for ; Wed, 3 May 2017 17:51:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519DB129477 for ; Wed, 3 May 2017 17:51:39 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9C2177A32F1 for ; Thu, 4 May 2017 00:51:38 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 20:51:37 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:51:41 -0000 > On May 3, 2017, at 6:29 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > Pervasive forward secrecy is one of the central security goals of = modern > cryptography, Sure, given a sensible definition of forward-secrecy. And near = instanenous deletion of session keys is not part of such a definition. > STEKs aren't compatible with this goal. They may be acceptable = operationally > today, but I think they must be borrowed time if the central goal is = meaningful. We need to recall what thread-model is behind the desire for = forward-secrecy. It is I think not controversial to say that forward is concerned with = limiting the damage from end-point (especially server end-point) compromise, in = which confidentiality of long-term keys (still held on the endpoint) is lost. Consider the fact that such compromise is unlikely to be detected and = remediated instantaneously. Indeed not only will the adversary have access for = some time to sessions initiated post-compromise, he will also be able to = impersonate the real server after the server is "secured" because certificate revocation = will take days (or until the certificate expires) to take effect and more = sessions can be compromised via MiTM attacks after the keys stolen. The incremental exposure of some fraction of a hour of sessions shortly = before compromise pales in comparison with the much longer post-compromise = exposure before the service is again secure. STEKs are simpler to design and secure than a complex session cache. = This simplicity has security benefits. Properly implemented STEKS have a = lifetime that is much shorter than any plausible compromise exposure time window. = Given this, it makes sense to not consider potential STEK compromise as loss = of forward secrecy. Forward secrecy guards against disclosure of truly long-term key = material, with a lifetime of weeks to years. Once we get down to hours or minutes, it = is quite sensible to take a coarser view of time, with similar exposure for = sessions "just before" and "just after" compromise. Maximally sensitive traffic can take the penalty of avoiding session = caching of any kind. --=20 Viktor.= From nobody Wed May 3 18:03:34 2017 Return-Path: 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 19B58129481 for ; Wed, 3 May 2017 18:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 j2rO2YzuotSY for ; Wed, 3 May 2017 18:03:30 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D1012949E for ; Wed, 3 May 2017 18:03:25 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id j17so1506998ybj.0 for ; Wed, 03 May 2017 18:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=44kaQbixVvo7/LtpJsZPQcc7VO3Zv+kWi1pdc7KUrYg=; b=mTmKZyhxsJnNuMtN61/CnSpmmcN3EtDYISc8n6/XZ7BZrpV7UGscFWDNKES0yD/WHi 5Gha/r6VdpnElLCh3dZpoq19cQlTJICjATn2d4VAAIC1gafHhG7/GLiFijOrmYUfvDj6 CYF25S46Yx3nmSBLfNt19ucHElrhXvg/8Dc7j8OOAJFMRwd0W6ZkRuYausWbhCIbXejh ZBgWDheicMIpXzzT/RQnt6ezc+ESib9lh0HR/hP89PJ3t0oUuIvz2u59Co3hKtewc6dc NA5c2vp0YwNW6dM8qh6f/AWIV7hW+uTV5tkbeqwnZ2TgLHJFvSqGmVkhNoxzxyoKkrog z1eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=44kaQbixVvo7/LtpJsZPQcc7VO3Zv+kWi1pdc7KUrYg=; b=ePNlfqXOw06D1Ko5onfIc45lVKp6SFAEB0eDllD49NEAcJi5MM96ekHBXnsIVGgbR4 yNT+pqBUcv1y2RLq7YNrcYKM5u+feRq/7tFnWH+9L9HcVXd/dFK1coEyVEuAF3xeqth9 lyUhOP6YIzipNr0DDkBAQqjr++4K5LI6qgwwzPjMF1Z581oXD6/BWr4Vih+oJL1et7Av X5SvUwXWdxLMb/9ayhGoXPr0qNJKhY7FZl8OuSRF8IvAdnUIBlVSTOAzrmBFSk9wZHUC XnB9bZLpEU89tGg3rpUMi1txjc1yyei9C926lRw7FQVrGNrgOJhVeMyh9/ITBqW/Eklu w9nQ== X-Gm-Message-State: AN3rC/6WkpEdw0/cYwVBtYnk5oo26eTJUKQdbYuwcZizj/JaidaTBDo8 7RT1dOsEr2vF1r7SKAGmjfv+0C05yh1I X-Received: by 10.37.16.212 with SMTP id 203mr18835545ybq.90.1493859804794; Wed, 03 May 2017 18:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 18:03:23 -0700 (PDT) In-Reply-To: References: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 18:03:23 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a11c0ff04027045054ea857c0 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:03:32 -0000 --001a11c0ff04027045054ea857c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 5:51 PM, Viktor Dukhovni wrote: > > > On May 3, 2017, at 6:29 PM, Colm MacC=C3=A1rthaigh = wrote: > > > > Pervasive forward secrecy is one of the central security goals of moder= n > > cryptography, > > Sure, given a sensible definition of forward-secrecy. And near instaneno= us > deletion of session keys is not part of such a definition. > I want to re-run DH for every bit transferred! of course I'm kidding, and take your point. There's a balance to strike. > > STEKs aren't compatible with this goal. They may be acceptable > operationally > > today, but I think they must be borrowed time if the central goal is > meaningful. > > We need to recall what thread-model is behind the desire for > forward-secrecy. > It is I think not controversial to say that forward is concerned with > limiting > the damage from end-point (especially server end-point) compromise, in > which > confidentiality of long-term keys (still held on the endpoint) is lost. > In the case of STEKs, the key may also be compromised without compromising the endpoint. With multiple endpoints, there is usually some kind of central STEK distribution system to synchronize the keys. And they key may also be compromised due to weak crypto on the tickets themselves. So we have to add those too to the threat model. But caches have similar challenges, which might even be harder. > Consider the fact that such compromise is unlikely to be detected and > remediated > instantaneously. Indeed not only will the adversary have access for some > time > to sessions initiated post-compromise, he will also be able to impersonat= e > the > real server after the server is "secured" because certificate revocation > will > take days (or until the certificate expires) to take effect and more > sessions > can be compromised via MiTM attacks after the keys stolen. > > The incremental exposure of some fraction of a hour of sessions shortly > before > compromise pales in comparison with the much longer post-compromise > exposure > before the service is again secure. > > STEKs are simpler to design and secure than a complex session cache. This > simplicity has security benefits. Properly implemented STEKS have a > lifetime > that is much shorter than any plausible compromise exposure time window. > Given > this, it makes sense to not consider potential STEK compromise as loss of > forward > secrecy. > > Forward secrecy guards against disclosure of truly long-term key material= , > with > a lifetime of weeks to years. Once we get down to hours or minutes, it i= s > quite > sensible to take a coarser view of time, with similar exposure for sessio= ns > "just before" and "just after" compromise. > > Maximally sensitive traffic can take the penalty of avoiding session > caching > of any kind. > That does all makes sense, it just hasn't really been how TLS is deployed. --=20 Colm --001a11c0ff04027045054ea857c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 5:51 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
> On May 3, 2017, at 6:29 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
>
> Pervasive forward secrecy is one of the central security goals of mode= rn
> cryptography,

Sure, given a sensible definition of forward-secrecy.=C2=A0 And near= instanenous
deletion of session keys is not part of such a definition.
=

I want to re-run DH for every bit transferred! of cours= e I'm kidding, and take your point. There's a balance to strike.
=C2=A0
> STEKs aren't compatible with this goal. They may be acceptable ope= rationally
> today, but I think they must be borrowed time if the central goal is m= eaningful.

We need to recall what thread-model is behind the desire for forward= -secrecy.
It is I think not controversial to say that forward is concerned with limit= ing
the damage from end-point (especially server end-point) compromise, in whic= h
confidentiality of long-term keys (still held on the endpoint) is lost.
=

In the case of STEKs, the key may also be = compromised without compromising the endpoint. With multiple endpoints, the= re is usually some kind of central STEK distribution system to synchronize = the keys. And they key may also be compromised due to weak crypto on the ti= ckets themselves. So we have to add those too to the threat model. But cach= es have similar challenges, which might even be harder.=C2=A0
=C2= =A0
Consider the fact that such compromise is unlikely to be detected and remed= iated
instantaneously.=C2=A0 Indeed not only will the adversary have access for s= ome time
to sessions initiated post-compromise, he will also be able to impersonate = the
real server after the server is "secured" because certificate rev= ocation will
take days (or until the certificate expires) to take effect and more sessio= ns
can be compromised via MiTM attacks after the keys stolen.

The incremental exposure of some fraction of a hour of sessions shortly bef= ore
compromise pales in comparison with the much longer post-compromise exposur= e
before the service is again secure.

STEKs are simpler to design and secure than a complex session cache. This simplicity has security benefits.=C2=A0 Properly implemented STEKS have a l= ifetime
that is much shorter than any plausible compromise exposure time window.=C2= =A0 Given
this, it makes sense to not consider potential STEK compromise as loss of f= orward
secrecy.

Forward secrecy guards against disclosure of truly long-term key material, = with
a lifetime of weeks to years.=C2=A0 Once we get down to hours or minutes, i= t is quite
sensible to take a coarser view of time, with similar exposure for sessions=
"just before" and "just after" compromise.

Maximally sensitive traffic can take the penalty of avoiding session cachin= g
of any kind.

That does all makes sense,= it just hasn't really been how TLS is deployed. =C2=A0

<= /div>
--
Colm
--001a11c0ff04027045054ea857c0-- From nobody Wed May 3 18:11:41 2017 Return-Path: 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 A30A01294F8 for ; Wed, 3 May 2017 18:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o00c8rqKYEpQ for ; Wed, 3 May 2017 18:11:38 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F591294C4 for ; Wed, 3 May 2017 18:11:38 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q20so2875617pfg.0 for ; Wed, 03 May 2017 18:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=172l4BVhi6E+KERDjj9RszMquwWgTkDbE6FEo60wqNA=; b=Zjgbz1XLGii2GszHlTUX1aUyfIfEmFr+gfhG5I4MetWSRGSmEjGzTJchDGo0XlhUMQ seI0pHLZI2kqCmAc3pCEdgfgL1o3f5I+FtEvE7jZH7MvPcwq053FOZBDWdBNlZgAelLp nArr53Ljr3Y6fOjXfGx3Z2wXLD3scErsL1C/ndfpObn1crCGUKw9h5kolpdAmIvXWxM1 cYzBpSFDnrqQVy+W1c0Uk+k0CdGUW1U0dbqYD/oREmZeF0DeE/eeCeKg29bYCdUoxBtd jv1UrTi36XuwSf7ZIGI7rBm3WL9LgQm29zqPC2Ug0gBVNAv2kwEaXHmoZmFlBfjfB0i7 IHrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=172l4BVhi6E+KERDjj9RszMquwWgTkDbE6FEo60wqNA=; b=ql258vS567nk74k/qy1OsBn2NW2YiBcZulWOtHsTZR5SAzWwdmLPwMqGpWGwVRa2xG 9o6DxrZPn4YAGDU00zOh22r/Z80vYzXUa9VVuAb4iSu7lh62phvdm82l6+3iUo50uWwH 0nTLdz3w4OATa6tvDHaTfKLoWx+BV5ZCy7ZMh/e9nGGmHQwzclapnDgO2RyGpFOjew3q UI3LHZorkOccy6NQadGAuXI/EW/dM2B6JGA40Y9VGc3JaeK42XKj5226gpOoVi9UUZ12 yR5vzPKMj0ehJHn/zbF1d8Z9wldtUoF8KT3fr5BZWSsESTMtF3XvRlowwd8JcRS8yclR C1eQ== X-Gm-Message-State: AN3rC/7T+eW8xhvVCBOwRujJjBRQ9TLu/vCkWSCyiBrdH2Si9ZMwJmaf jj0zDv+CGNOgA64KjnN+a8ITWM5+fQ== X-Received: by 10.84.137.1 with SMTP id 1mr52980746plm.68.1493860297624; Wed, 03 May 2017 18:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.12 with HTTP; Wed, 3 May 2017 18:11:36 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Wed, 3 May 2017 18:11:36 -0700 Message-ID: To: Martin Thomson Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:11:40 -0000 On Wed, May 3, 2017 at 3:56 PM, Martin Thomson w= rote: > On 3 May 2017 at 22:45, Colm MacC=C3=A1rthaigh wrote: >> This is easy to say; the TLS layer is the right place. It is not practic= al >> for applications to defend themselves, especially from timing attacks. > > If you care about these attacks as much as it appears, then you can't > reasonably take this position. We've historically done a lot to > secure applications at a single point, and we're almost at the end of > what we can reasonably do for them at this layer. We need to think > more hollistically and acknowledge that applications need to take some > responsibility for their own security. Historically TLS protected against replay attacks. Now it doesn't. An application that relies on this property which TLS used to guarantee is now broken. Clearly we could have provided it, we just chose not to. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed May 3 18:15:22 2017 Return-Path: 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 EE8421294C4 for ; Wed, 3 May 2017 18:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jV1GYfa_GGnQ for ; Wed, 3 May 2017 18:15:19 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C0C1294F8 for ; Wed, 3 May 2017 18:15:19 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id j1so2010977lfh.2 for ; Wed, 03 May 2017 18:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5/1ZPz4QRUO/qR4avIcKS9T94CjuqBqu/FTsuMTUF+k=; b=fXNcQQ98pCZkTeulNrootFNu+e6tQjCAyFOeWA0dRKF8TqU3UsFHkTOuYXkQFvxIz8 edtTwtCu+NwmtpNEW8SkfmwP1m1AvWe7S2u/qbwwmSQh3Wvrmr2fNPI0Bc+cg4mAymAC 8x7mv6nvoC5effghK3bwFfSsE86HMr9bGQs7Dvz9yEjCyigSbOOS9KwrmmDiLVgltj5k tI3ZVeDM3eXmNWtHCCe81Q5iFj48esMt2hfP4mUSyx+tKXR2AExmuKF5VOxFTNVOmUSz igRyXorxLt9Cpy4rg+bUq0CYIhRhtluQKfssET8XXodi+N/8JaRTyX34hJTXUPrSloQN TEng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5/1ZPz4QRUO/qR4avIcKS9T94CjuqBqu/FTsuMTUF+k=; b=p8vUJwuF8oLWCmG+MGNCV4YC9vpPuPKOhq8iPATyEb8RVCRebJkXORn2B9T5+RTPk/ 9cxsPcSvXyz+saFxMXNCYW9prwdUIGWMHG+ReCK25pd4B05aLk70jbfODnIctgg1kbAs TUZqDHQL1S4qHaPS1z3F8h9uowNimI405aaf7R59F5sg/rhInTMK0XZS7NnryCLrYd+O i4mJAmjsT/kdr5zk3i5YwC/MsW2v+yf5oDoIjoNeCcTTFZWLrYihotJmVFF84PbIUdSu jVWjUzA2qtaQ3jHAdAtR8iaUfVe4PezLpA0HyXlBsHfPM+91lHcocjJ9IcDyBVMic2Hb voQQ== X-Gm-Message-State: AN3rC/6W+5kVcfHOB/bg9h/jBCZRsFSFIAU5/yF8I1/ncvCwYYWkU5My GA3x/D5ZQlaeJg4fUV+q1hn7fYet2g== X-Received: by 10.25.31.14 with SMTP id f14mr11521326lff.43.1493860517833; Wed, 03 May 2017 18:15:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 18:15:16 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 May 2017 11:15:16 +1000 Message-ID: To: Watson Ladd Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:15:21 -0000 On 4 May 2017 at 11:11, Watson Ladd wrote: > Historically TLS protected against replay attacks. Now it doesn't. An > application that relies on this property which TLS used to guarantee > is now broken. Clearly we could have provided it, we just chose not > to. Let's get the fallacy out of the way. TLS 1.3 provides protection against replay attacks, just not if you decide to use 0-RTT. I realize that there is a real risk that this distinction will be lost on some, but I can fairly confidently say that it isn't lost on those who are considering its use in various protocols. For instance, I've spoken to someone who is looking at XMPP seriously and the advice there is pretty close to *don't* use 0-RTT. From nobody Wed May 3 18:19:25 2017 Return-Path: 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 9890C127058 for ; Wed, 3 May 2017 18:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 hw86UwOqieBM for ; Wed, 3 May 2017 18:19:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4B8126E3A for ; Wed, 3 May 2017 18:19:22 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 691407A32F1 for ; Thu, 4 May 2017 01:19:21 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 21:19:20 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <032A35F4-006D-4AE0-8C30-A5D0912A7EC9@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:19:23 -0000 > On May 3, 2017, at 9:15 PM, Martin Thomson = wrote: >=20 > Let's get the fallacy out of the way. TLS 1.3 provides protection > against replay attacks, just not if you decide to use 0-RTT. Amen. > I realize that there is a real risk that this distinction will be lost > on some, but I can fairly confidently say that it isn't lost on those > who are considering its use in various protocols. For instance, I've > spoken to someone who is looking at XMPP seriously and the advice > there is pretty close to *don't* use 0-RTT. One obvious use case for 0-RTT is DNS queries. The query protocol is idempotent, and latency matters. So for DNS over TLS, 0-RTT would be a good fit. TLS session caches are not attractive on the DNS server given the enormous query volumes, but STEKs would be a good fit. --=20 Viktor. From nobody Wed May 3 18:31:12 2017 Return-Path: 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 DECC01294FA for ; Wed, 3 May 2017 18:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 31EDIWP0VO_E for ; Wed, 3 May 2017 18:31:09 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D631294EE for ; Wed, 3 May 2017 18:31:09 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v441RFRF004981; Thu, 4 May 2017 02:31:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dKrxw8qwaP6NSXFuuuz9wMGOJ+2CLpYPRtZOwf28GZk=; b=ZPaAYOgUtlSr1u2Z+VP9IFSrCm++ZKKZOa7bBMHEXvxXgWYyxPlsXAfFFWxML4u7Tv7n saLIfnD8kE0UtysmbTbsDv5Bf9lUT+eiLnPnQVUgHC0lUwwDcRfyNq/s6TGsmRb3wJmz Vp16WEhxRew45IWE2f1tBjDP7kKxogk/Ay5nPoJpXUlDK3zyW/Y9ENK+UAnak7z4OqJg 6DONv0oLyOtwTbzYTblT4LkaHY7kesUn5Wcm14tEyJsKcc8OQQ7MbeJDfxWC1kGTm5fF nb6VTmHo2CSI1AjWCToyIryhssLiljSFiAATbrrUuFQiR4qjH8tJAXJIXGlbpOr4hAVe uw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2a72my6nsj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 02:31:04 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v441UpJF008270; Wed, 3 May 2017 21:31:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a72mb39gg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 21:31:03 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 20:31:03 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 20:31:03 -0500 From: "Salz, Rich" To: Martin Thomson , Watson Ladd CC: "tls@ietf.org" Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NICDv1l4S8FUWU9Zh5nPuktKHiqKmAgAA6vACAAKqpgIAAJd0AgAABBgD//6+mgA== Date: Thu, 4 May 2017 01:31:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.153] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040022 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:31:11 -0000 > Let's get the fallacy out of the way. TLS 1.3 provides protection agains= t replay > attacks, just not if you decide to use 0-RTT. >=20 > I realize that there is a real risk that this distinction will be lost on= some, but I > can fairly confidently say that it isn't lost on those who are considerin= g its use > in various protocols. Well, for example, Chrome/boringSSL should arguably know better but are tre= ating it all as one equivalent stream. Is FF/NSS doing the same thing? Why? From nobody Wed May 3 18:36:09 2017 Return-Path: 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 21796127058 for ; Wed, 3 May 2017 18:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5RsyFv_zuuOE for ; Wed, 3 May 2017 18:36:01 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E78E129515 for ; Wed, 3 May 2017 18:35:59 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t144so63874lff.1 for ; Wed, 03 May 2017 18:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tST7UE1EqomTincaZf5jGawFEn5bXkOfnrdATho+AGo=; b=JzpM1Q8wSB0SkQAT9gArMUnQmrrCCEC80xa8dLX+uNv2SW4xlup1sOsAQHAIzemcrC wL0fDrFNbFKJhB1cmQAihRv59jVXDjP2rEAH2KzGmMNtok24dOWNX5lUiquSC8QbJldz owEG5EYiPGr4FiangiV3Vx3EIpimKnUTXwOQE4K8b4MjM0cEmSdLFyT6k3ef+oUgYAZc 7N+AKISdyEbyU0uzXhI3Z+o7PkvKWk7S4LDaqzsWGCD3bxiOIyeIAePhIo/MkyWTtrNw DWboP8EkI3S6ZJlYXqXOKlP52OnxlpnDNvaC3HDeJXdmtazm/eRHumkNOzmf9owT6ul3 0YiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tST7UE1EqomTincaZf5jGawFEn5bXkOfnrdATho+AGo=; b=gCRXs1mjo+rcEryCZSSIWmHH3wQd1frHgrrkGaTpSzaq/OoZRi5IbR1B881MnnBuuL ZkkIclgDUXy8oAWKL1QOLZyptr7J1pWqt2AE1loApsdcPNtHNTP7Go4bsjzT5K0OCMMN +Q2weo4TG5Efhp9AP5VtK5zeIc0iMvEnOzwWThVFMZSeDn1QN9T0UGgeT14G1R9LTkyx cWAo3cZtKPIJOERs9+qff7TaxopBIV9E/DBjndbHCzngkwJWhwVNzhbejGeo2zhJ7z3x N/ht5DBG/JaWAQML+bMO+it4/6KSrtKgMuNWHw56Tj5ZTDhEcYwbSdGyvX71I6dUxZAi Qy7g== X-Gm-Message-State: AN3rC/7hdBJ2l0OzI56GHzpNYtIKaQ3PR6quzk8xLb9bcxazNyAYBOV7 Kbq0RoEVj6quOUcRdi09q/1fNLGRFg== X-Received: by 10.46.19.18 with SMTP id 18mr14617067ljt.103.1493861757504; Wed, 03 May 2017 18:35:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 18:35:56 -0700 (PDT) From: Martin Thomson Date: Thu, 4 May 2017 11:35:56 +1000 Message-ID: To: "Salz, Rich" Cc: Watson Ladd , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:36:07 -0000 On 4 May 2017 at 11:31, Salz, Rich wrote: > Well, for example, Chrome/boringSSL should arguably know better but are treating it all as one equivalent stream. > > Is FF/NSS doing the same thing? Yes. > Why? Because doing anything else makes it a lot harder for the application. I realize that you *want* that, but clearly we disagree about the utility of API hurdles. Given that the application already took extraordinary steps to enable 0-RTT, we don't think that adding artificial hurdles is going to change things. From nobody Wed May 3 18:39:18 2017 Return-Path: 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 16774129481 for ; Wed, 3 May 2017 18:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 mkM4AMjxmETU for ; Wed, 3 May 2017 18:39:15 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87E11294C4 for ; Wed, 3 May 2017 18:39:15 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l18so62147ywh.3 for ; Wed, 03 May 2017 18:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wflEnuMrzE8Rux+k4dNlQquzcpcaTv+dFG59oz+INJo=; b=C7gwIOJ6UL/vZAPGuQaD8nd7zIKxL4vxkkyeGnv5k1esTHRYIVYlgd8wiLxSaOiKQi /mc6VFp7KNuU+OSN/hCv0uwJmyv0yv8ao/VHgFzO92VOWMbHUzxtJr1VU8ljNpDacrey /MxtUbXNqmUTY0j7zQaudCpAaIU+SBUBSz+Rk5Eyusb9tTtomvdeE9W1F4FQ73qYOlhL GQDfB2jID5wK98grmQ3SQBwmpIEYL36fNYniaqg8rr4QuT6Uxicc9LgYaoSDET7TgD8v 0oXQijHPyhByU0Lz8NMhbVm4k/Qns2jbMvRI2F0k4BCIqaCcy4bJNfuTMZ3acSF0ygo0 S2Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wflEnuMrzE8Rux+k4dNlQquzcpcaTv+dFG59oz+INJo=; b=umud9PH3GjOWgiX3bNPiloh+jjBd2RdTp19ZIXcet1AHqS2+dweIU33OgE3YZhmKOJ hrqMPlC/i1aOo4KAe/dI1VPj3meTJcf5mf8VuLvrn8HXUwHdCXHeQDCEnVN6EcIg1FaP q8UhChOMp8fqWtf65skf/N01eA6bn6cBgoszSDqB8Bv0WOhh104qJEAfS/Q9/MuwWaxQ cTN2qiB76hSGYgnbMGiLk4wReH5xDqGALUwIPJJOJyMzhvBuSQFbExwkwF5xVjYD6NOB gdnVpaB40pY0PAnJewixFxz9jUW6CXNwfPWlFztWs/eLhzxxkM9eRrpuWcG4Tlcy/jWY U1dg== X-Gm-Message-State: AN3rC/6B/O8Onwq5Os3h1rn39BsvkH+1OygN7qN0XxY0YYEEK7dO/zi3 sfPM4mNevTT7Xfty4P9y83tkRGdiOYqh X-Received: by 10.129.104.69 with SMTP id d66mr2141540ywc.74.1493861954600; Wed, 03 May 2017 18:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 18:39:13 -0700 (PDT) In-Reply-To: <032A35F4-006D-4AE0-8C30-A5D0912A7EC9@dukhovni.org> References: <032A35F4-006D-4AE0-8C30-A5D0912A7EC9@dukhovni.org> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 18:39:13 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a11490b9a25e481054ea8d7b4 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:39:17 -0000 --001a11490b9a25e481054ea8d7b4 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 6:19 PM, Viktor Dukhovni wrote: > One obvious use case for 0-RTT is DNS queries. The query protocol is > idempotent, and latency matters. So for DNS over TLS, 0-RTT would be > a good fit. TLS session caches are not attractive on the DNS server > given the enormous query volumes, but STEKs would be a good fit. > As it happens, DNS queries are not idempotent. Queries have side-effects, for example Bind9 will rotate an RRset by one increment on each query. Many providers charge by the DNS query. Many providers throttle DNS queries (and TLS is intended as a mechanism to help prevent the ordinary spoof ability of DNS queries). -- Colm --001a11490b9a25e481054ea8d7b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 6:19 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
One obvious = use case for 0-RTT is DNS queries.=C2=A0 The query protocol is
idempotent, and latency matters.=C2=A0 So for DNS over TLS, 0-RTT would be<= br> a good fit.=C2=A0 =C2=A0TLS session caches are not attractive on the DNS se= rver
given the enormous query volumes, but STEKs would be a good fit.

As it happens, DNS queries are not idempotent.=C2= =A0 Queries have side-effects, for example Bind9 will rotate an RRset by on= e increment on each query.=C2=A0 Many providers charge by the DNS query. Ma= ny providers throttle DNS queries (and TLS is intended as a mechanism to he= lp prevent the ordinary spoof ability of DNS queries).=C2=A0

--
Colm
--001a11490b9a25e481054ea8d7b4-- From nobody Wed May 3 18:41:11 2017 Return-Path: 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 7A67B12953F for ; Wed, 3 May 2017 18:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 7dZMP92Rwnhq for ; Wed, 3 May 2017 18:41:08 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2B1129530 for ; Wed, 3 May 2017 18:41:07 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id k11so100308ywb.1 for ; Wed, 03 May 2017 18:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hEbV45wtjVSY9Q2kJEpUGljnEK5tLZh+L0hmnc4ntPI=; b=zzKEGYVYRrnrIjb0LbSR8YfG8G+pZwI9tbPtmNzEllGlPont/qa0D+j3udvaTp/3y7 yNBxtBoUIYUpcaxs2lgQ91R1wHg7szrbGu483iDV1qqCP6VajXJHCUN6ZqyFXuSyG8It 9Z9SWNViCBT9yrQsOpMfR45N2jTgrad21KX1qtdC/eaOYds6jJOw3h8RF+GzBUU2SHOf oNf53rbk4ZoWeCF/WJhUof6zqgcLSwuAwuOY8qaG7fip8Q/XUHhEJohkYQbXvUe08w/g hh7+jG5O4/Te2s9v86pg3/oUyDNWWDEdJ4UQpyF5qLFFFH7yFwCQ867WU29OXzHoY7pJ Bxjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hEbV45wtjVSY9Q2kJEpUGljnEK5tLZh+L0hmnc4ntPI=; b=YNDUPG0Q1SaF0DoKb7CjrEhTB9ZM6zPWBKTDeATczipG/Fuc1OVHIYNy89VlFKYsAv S8eB8X6bunoaNK0PxSq7eKjm3R1nc1ceVP9T6r0wQ9Df02D/HcjeroX8Al8sXqXWgK+K o+pbzxG/TlFUXuxuCqvd0iinACmU77elTib6E0K7gL/GvO6TfE1ChT2YICqUw2Gt5r6c Z83FrvzEb1iyJw1izq2LOcLWpltYj0YnwA2X6yWffbPhXRSENZO+6mW8kiCKbPvZn3/q rECwZZOpaYjez5oB002n3VJkDd/0J4vGMcERqJFMpW/UvlYipnyA2XAFwUQ3ob6LzyY4 vpmA== X-Gm-Message-State: AN3rC/5V792ViHMOHWzgem1dN0LytvtYxH8NsOBKnFTiyg3AQcBs/zu+ Lh8FBcmJZMP7mjyUx1ktS6kOiH4lcQ== X-Received: by 10.129.105.198 with SMTP id e189mr31851804ywc.296.1493862066704; Wed, 03 May 2017 18:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 18:41:05 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 18:41:05 -0700 Message-ID: To: Watson Ladd Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11471256d49be0054ea8ddac Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:41:09 -0000 --001a11471256d49be0054ea8ddac Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 6:11 PM, Watson Ladd wrote: > > Historically TLS protected against replay attacks. Now it doesn't. An > application that relies on this property which TLS used to guarantee > is now broken. Clearly we could have provided it, we just chose not > to. > And that choice is insecure. If it's to be kept, I'd suggest renaming the protocol. -- Colm --001a11471256d49be0054ea8ddac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 6:11 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
Historically TLS prote= cted against replay attacks. Now it doesn't. An
application that relies on this property which TLS used to guarantee
is now broken. Clearly we could have provided it, we just chose not
to.

And that choice is insecure. If it&= #39;s to be kept, I'd suggest renaming the protocol.=C2=A0
<= div>
--
Colm
--001a11471256d49be0054ea8ddac-- From nobody Wed May 3 18:41:49 2017 Return-Path: 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 050A3129530 for ; Wed, 3 May 2017 18:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Xrf-BNY6krmY for ; Wed, 3 May 2017 18:41:45 -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 5D6D5129576 for ; Wed, 3 May 2017 18:41:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9A013496C2E; Thu, 4 May 2017 01:41:41 +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 84841496C2C; Thu, 4 May 2017 01:41:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493862101; bh=sTV73IfJC68KMjqSFm4oiKshOftpTaD6OHdguWuOO0w=; l=3000; h=To:References:Cc:From:Date:In-Reply-To:From; b=TGFTk6mc3YGMsd8qmZk6N3qeJwrTsgZ9TC5BA8LcZkESkhr5eSJ8yBhrPDpdCT76U 4BV6GKiNnwsg3t21yb7nLK3h4tuwXL9RXkFae5tafPUiU02I4wUh7Cnjkql9PdpOgC mgZViUInPVgMeDtNU245KPcAX42+sG7ihMiu9UHc= 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 118E41E0BC; Thu, 4 May 2017 01:41:40 +0000 (GMT) To: Martin Thomson , "Salz, Rich" References: Cc: "tls@ietf.org" From: Benjamin Kaduk Message-ID: <19b9d223-14b1-87d4-1790-891cc9166e12@akamai.com> Date: Wed, 3 May 2017 20:41:40 -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: Content-Type: multipart/alternative; boundary="------------85809A1A98C40F6A718D37EF" Archived-At: Subject: Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:41:47 -0000 This is a multi-part message in MIME format. --------------85809A1A98C40F6A718D37EF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/03/2017 08:35 PM, Martin Thomson wrote: > On 4 May 2017 at 11:31, Salz, Rich wrote: >> Well, for example, Chrome/boringSSL should arguably know better but are treating it all as one equivalent stream. >> >> Is FF/NSS doing the same thing? > Yes. > >> Why? > Because doing anything else makes it a lot harder for the application. > > I realize that you *want* that, but clearly we disagree about the > utility of API hurdles. Given that the application already took > extraordinary steps to enable 0-RTT, we don't think that adding > artificial hurdles is going to change things. > A related question is whether NSS wants to be a general-purpose TLS library, or an HTTP-specific TLS library. I have mostly come to terms with the HTTP application profile for 0-RTT saying "combine the streams" (but still want to see it written down with a proper security analysis before it gets widespread), but other application profiles might do different things! Are you painting yourself into a corner? -Ben --------------85809A1A98C40F6A718D37EF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 05/03/2017 08:35 PM, Martin Thomson wrote:
On 4 May 2017 at 11:31, Salz, Rich <rsalz@akamai.com> wrote:

Well, for example, Chrome/boringSSL should arguably know better but are treating it all as one equivalent stream.

Is FF/NSS doing the same thing?

Yes.


Why?

Because doing anything else makes it a lot harder for the application.

I realize that you *want* that, but clearly we disagree about the
utility of API hurdles.  Given that the application already took
extraordinary steps to enable 0-RTT, we don't think that adding
artificial hurdles is going to change things.

A related question is whether NSS wants to be a general-purpose TLS library, or an HTTP-specific TLS library.  I have mostly come to terms with the HTTP application profile for 0-RTT saying "combine the streams" (but still want to see it written down with a proper security analysis before it gets widespread), but other application profiles might do different things!  Are you painting yourself into a corner?

-Ben
--------------85809A1A98C40F6A718D37EF-- From nobody Wed May 3 18:52:07 2017 Return-Path: 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 E6EF012785F for ; Wed, 3 May 2017 18:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cwoARu_z2Xso for ; Wed, 3 May 2017 18:52:03 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11BF129486 for ; Wed, 3 May 2017 18:51:59 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m36so309657qtb.0 for ; Wed, 03 May 2017 18:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KOPyhFu7GtR/hBlHCZHyQnR0TfMupE7wz4pO5RuBZ/o=; b=PXCj4kV7muLkHz61EDR9kcWzrHRiVt1jE32LNM5BdEO7qUrRwKxTlBvoQRVfc4J3Tn kedW4jLl8yd/HZ6MYUAJ4+iu+53hvONtLVkfff0u2EGxxecG0yqSo/8c3TdpDX6teX35 bSvf3QKMQ/d7obcn0Ga84vlrRtj37gNtzi6+UL+CK7bx6rwxgjbyAxv3BxC9oREpsx8c 6sI3CljnTN1/soWsqDW9txtyAmj8q2uoTAF2EU7LNsKrHnqJ5BlipZfTpmU3YoHdRtks Lse2RwCfYMJx8HJk4b3BUEebWcnC+GqWd1c7rxYDsk5khPpyw/Et/+fUuduNBPwn4Yh5 cgWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KOPyhFu7GtR/hBlHCZHyQnR0TfMupE7wz4pO5RuBZ/o=; b=cLjgTB6rKyyZTp1bB5EcwXIkpilsPdJ9Xysl12Jg2eDzy3/05e6DWpeM0GWp79YOfE uM+lvRk2cCBxNAQASgmxo1G7RwMA2A1IsS5/+YUxZPYW/mF+4mkBYmmFfFoC4cGbp9jg m3v3P9X9gX0cQLWNN+ToImJ4GoWV/RuNwB2V51pt1FZXXkWGnYRWQ7E+AGFCwGpZ17EC 9+JAWf1LtMk2im1p8/gr4M1xin3b2Oo4iMy/e7Yw7N1YeME3eeoHuKRT6WkbsXBvsXOj 2GhPT60rVRswUovha8kwHxFlGlnWGTV4lahU7h8tO12PePL4ZMiSspv+R1M2YlABAzk7 eTbg== X-Gm-Message-State: AN3rC/5fGWUeyBK8/IthGN4yhxs2CmnuPvX6qm/UciQjh0GW1I/+4Dyg J4BLWUza28MDMYM4qV2ypdt/aO2vlw== X-Received: by 10.200.54.2 with SMTP id m2mr32817898qtb.176.1493862718937; Wed, 03 May 2017 18:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.168.137 with HTTP; Wed, 3 May 2017 18:51:58 -0700 (PDT) In-Reply-To: <19b9d223-14b1-87d4-1790-891cc9166e12@akamai.com> References: <19b9d223-14b1-87d4-1790-891cc9166e12@akamai.com> From: Martin Thomson Date: Thu, 4 May 2017 11:51:58 +1000 Message-ID: To: Benjamin Kaduk Cc: "Salz, Rich" , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:52:05 -0000 On 4 May 2017 at 11:41, Benjamin Kaduk wrote: > A related question is whether NSS wants to be a general-purpose TLS library, > or an HTTP-specific TLS library. I have mostly come to terms with the HTTP > application profile for 0-RTT saying "combine the streams" (but still want > to see it written down with a proper security analysis before it gets > widespread), but other application profiles might do different things! Are > you painting yourself into a corner? Sure, in a multi-dimensional space, corners can appear in the strangest places. But given that TLS is streams on both sides, I can't think of a way that an alternative model would make sense. It's definitely the case that an application protocol could be designed to deal with 0-RTT as a separate stream, but when all they wanted was a stream abstraction, the idea that there might be an antechamber stream they have to deal with separately is hard to reason about. It's harder still when you consider data limits on 0-RTT and the need to complete the handshake in a timely fashion. A separate thing could mean that sending 0-RTT would block handshake completion because the sender might want to ensure that a complete "thing" was sent in 0-RTT. Either that or you have to deal with truncation. If we need another API, it's not impossible to build one, with options to cause 0-RTT to be routed to it. I just don't see us needing one any time soon. From nobody Wed May 3 18:59:53 2017 Return-Path: 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 4AB041294EE for ; Wed, 3 May 2017 18:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 DIxu8dAsIECl for ; Wed, 3 May 2017 18:59:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB10A129486 for ; Wed, 3 May 2017 18:59:49 -0700 (PDT) Received: from [10.74.89.181] (unknown [38.86.167.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id BD0A07A32F1 for ; Thu, 4 May 2017 01:59:48 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 May 2017 21:59:47 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <3F4F90F1-5446-4183-A972-1074FED7E899@dukhovni.org> References: <032A35F4-006D-4AE0-8C30-A5D0912A7EC9@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:59:51 -0000 > On May 3, 2017, at 9:39 PM, Colm MacC=C3=A1rthaigh = wrote: >=20 > As it happens, DNS queries are not idempotent. Queries have = side-effects, This is sufficiently misleading to be false. > for example Bind9 will rotate an RRset by one increment on each query. Regardless of who the client is, the "attacker" can rotate the RRset order by making his own query, no need to impersonate some other client. And of course randomization of RRs in an RRset is normal. Some clients further randomize or re-order the results. > Many providers charge by the DNS query. They don't charge the client, which remains unauthenticated. Hosted DNS domains may be charged by query volume, but again the attacker can make his own queries without replaying traffic from some other client. > Many providers throttle DNS queries (and TLS is intended as a = mechanism > to help prevent the ordinary spoof ability of DNS queries). Again the client is unauthenticated, throttling is by IP address, = there's no need to repeat the same payload, indeed that's less effective since throttling is biased towards queries for non-existent names, ... Throttling is mostly for UDP, for lack of BCP-38 implementation. DNS over TLS *is* a good candidate for 0-RTT. [ I would have chosen a more simple protocol for DNS security than TLS, but given that DNS over TLS seems to be moving forward, 0-RTT makes sense. ] --=20 Viktor. From nobody Wed May 3 19:15:59 2017 Return-Path: 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 C015C1296D2 for ; Wed, 3 May 2017 19:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 dfAxN_iE4Fop for ; Wed, 3 May 2017 19:15:56 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB7712957A for ; Wed, 3 May 2017 19:15:55 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id k11so347429ywb.1 for ; Wed, 03 May 2017 19:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xinJljJMz//JmTIGPAhN1rzicU9fW97mdG+i2IFKZ7c=; b=1o6CnvsvTGLX8Xg6SqwZNgMcaR27GkLbNSLi3da2zSiApIeLF5ycipDnHpxJ8Z72F6 n7JViek481o8tnYg8Gwhucf4Fg5qlLJQ9T0nLKbqSqsgw115DVJ1tnleYfPcXfFJjHLn aZ4i7W4yW4mJWcI7/aYcIqOEQCR6Yis6+YgB8fBsm5lIKNg1qmiaBhXZHl4zf6qllz2Q ILAn1uzl3tVGPOTCrGZehoh+vpgiM3rl3oY5cxIdkDOneKlxvo+hqB+YA8WEXWljQakv 9xnW2lMKHowLtOHklP/+AggLQBs0UwqcrbHW4xgO2lplV+RqUCNxVVyNoAfcvpCeQ/jA 9NhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xinJljJMz//JmTIGPAhN1rzicU9fW97mdG+i2IFKZ7c=; b=jP5mCi5x6jERx7A/EMN4OqcIjrIwuEfuQKtAToXgo1NDshRBvPn3Ho9+B8Fo4y63wj RQAuXLS3LhpaFzlc1s3hFRgcfRYUXedMO3ocsdefA275KsJ0uCAqcZPVpUd2f+p2DzUd b+ooeJ0/yZ/A2GT2TWqDRdjzFyUEosWU70X4Qx0bmoRu6M3SS/qdGrimXDomSN+vJn7B aEetk8BhJ4ExKkktxrZdsjSs+JtMMmU4egOEkw0HUrQIXufZN4mVkUyKJbGfL9iUzxdJ zEz2GLsFF1nuOuyKu308ebNQ8shNDTIAEQPv5dgPaDe9eZoQvSWy7uP70bySobRBGGOH 7v/w== X-Gm-Message-State: AN3rC/6kWZ/qcS72vYOGC7FtaNT4pE+oW27Mn99i4yA9OdoyyBBgSfWn mpmIbUKTkWehfXpqSo94cSauS2Mbs/F5 X-Received: by 10.129.152.4 with SMTP id p4mr31852753ywg.1.1493864154174; Wed, 03 May 2017 19:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 19:15:52 -0700 (PDT) In-Reply-To: <3F4F90F1-5446-4183-A972-1074FED7E899@dukhovni.org> References: <032A35F4-006D-4AE0-8C30-A5D0912A7EC9@dukhovni.org> <3F4F90F1-5446-4183-A972-1074FED7E899@dukhovni.org> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 19:15:52 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=94eb2c0bd9ee40d7ee054ea95a32 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:15:58 -0000 --94eb2c0bd9ee40d7ee054ea95a32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 6:59 PM, Viktor Dukhovni wrote: > > > On May 3, 2017, at 9:39 PM, Colm MacC=C3=A1rthaigh = wrote: > > > > As it happens, DNS queries are not idempotent. Queries have > side-effects, > > This is sufficiently misleading to be false. What I'm trying to get at is that idempotency is hard. Even the simplest things that seem idempotent often are not. It's really really hard to do a deep review. And that's if people even know to perform the review. , > Many providers throttle DNS queries (and TLS is intended as a mechanism > > to help prevent the ordinary spoof ability of DNS queries). > > Again the client is unauthenticated, throttling is by IP address, there's > no need to repeat the same payload, indeed that's less effective since > throttling is biased towards queries for non-existent names, ... > It's not always by IP address. Anti-DDOS is much more nuanced in my experience, often take the QNAME into account. > > Throttling is mostly for UDP, for lack of BCP-38 implementation. DNS > over TLS *is* a good candidate for 0-RTT. [ I would have chosen a more > simple protocol for DNS security than TLS, but given that DNS over TLS > seems to be moving forward, 0-RTT makes sense. ] > +1 to that too! --=20 Colm --94eb2c0bd9ee40d7ee054ea95a32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 6:59 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:

> On May 3, 2017, at 9:39 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
>
> As it happens, DNS queries are not idempotent.=C2=A0 Queries have side= -effects,

This is sufficiently misleading to be false.

What I'm trying to get at is that idempotency is hard. Even th= e simplest things that seem idempotent often are not. It's really reall= y hard to do a deep review. And that's if people even know to perform t= he review.=C2=A0
=C2=A0
,<Your next two points are g= ood, just cut for length>

> Many providers throttle DNS queries (and TLS is intended as a mechanis= m
> to help prevent the ordinary spoof ability of DNS queries).

Again the client is unauthenticated, throttling is by IP address, th= ere's
no need to repeat the same payload, indeed that's less effective since<= br> throttling is biased towards queries for non-existent names, ...

It's not always by IP address. Anti-DDOS is m= uch more nuanced in my experience, often take the QNAME into account.=C2=A0=

Throttling is mostly for UDP, for lack of BCP-38 implementation.=C2=A0 DNS<= br> over TLS *is* a good candidate for 0-RTT.=C2=A0 [ I would have chosen a mor= e
simple protocol for DNS security than TLS, but given that DNS over TLS
seems to be moving forward, 0-RTT makes sense. ]

<= /div>
+1 to that too!=C2=A0

--
Colm
--94eb2c0bd9ee40d7ee054ea95a32-- From nobody Wed May 3 19:29:14 2017 Return-Path: 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 2CB57128C84 for ; Wed, 3 May 2017 19:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 W_evbcgXkO61 for ; Wed, 3 May 2017 19:29:09 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D9C126C3D for ; Wed, 3 May 2017 19:29:09 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v442QSQN018692; Thu, 4 May 2017 03:29:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=FTQ6x+5QZl97yzHJtOo/UeuayKCnhDpZKJ8dLCn4DGw=; b=KyfASnVpT7QO8TXSemcSwnr5jUY5bd+vGNFNWbeX8vc35XTnJ7YKEhVnyD/bKAlcG3NZ FbNyEsV6VsV4hjUWgkeU95R9HLiLM/y//u6LxdGVYFp6Tv3LgkGmIza/PA+q+PKoMDgc N/dWI5C0YTZdr88hM9JAbBSwj5Jx05y8AG0RzR3fbuWlbipq0USaxVC3badwn3Gzfzmm hkvtbSfG+E6cQxrwwsnCjthrtxVt5rPcuw77KV5gj6vw/hucc5v53UjgaZIksAaMqv9c lQzDkBUhlH+6WEw8hZvbqGD25+x0dP3VGUENVSIObseO1puogE/4qG9S1f9jYn2fiGIB 1w== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2a72n97k0d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 03:29:05 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v442Qa5t004730; Wed, 3 May 2017 22:29:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2a72mb3d9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 22:29:04 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 21:29:03 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 21:29:03 -0500 From: "Salz, Rich" To: Martin Thomson , "tls@ietf.org" Thread-Topic: One stream to rule them all (was Re: [TLS] Security review of TLS1.3 0-RTT) Thread-Index: AQHSxHbYw7JncmGtmkWF7ddamAiDoKHjZPGwgAAOTuA= Date: Thu, 4 May 2017 02:29:02 +0000 Message-ID: <5242af630cb14f29847455c2de6ceb81@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <74c5b8f9c44149dda3b26ed833588eed@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <74c5b8f9c44149dda3b26ed833588eed@ustx2ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040039 Archived-At: Subject: Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:29:10 -0000 ID4gQmVjYXVzZSBkb2luZyBhbnl0aGluZyBlbHNlIG1ha2VzIGl0IGEgbG90IGhhcmRlciBmb3Ig dGhlIGFwcGxpY2F0aW9uLg0KID4NCiA+IEkgcmVhbGl6ZSB0aGF0IHlvdSAqd2FudCogdGhhdCwg YnV0IGNsZWFybHkgd2UgZGlzYWdyZWUgYWJvdXQgdGhlDQogPiB1dGlsaXR5IG9mIEFQSSBodXJk bGVzLiAgR2l2ZW4gdGhhdCB0aGUgYXBwbGljYXRpb24gYWxyZWFkeSB0b29rDQogPiBleHRyYW9y ZGluYXJ5IHN0ZXBzIHRvIGVuYWJsZSAwLVJUVCwgd2UgZG9uJ3QgdGhpbmsgdGhhdCBhZGRpbmcN CiA+IGFydGlmaWNpYWwgaHVyZGxlcyBpcyBnb2luZyB0byBjaGFuZ2UgdGhpbmdzLg0KIA0KIFRo YXQncyBraW5kIG9mIGluZmxhbW1hdG9yeS4gIEFwb2xvZ3kgYWNjZXB0ZWQgOikNCiANCiBJIGRv bid0IHdhbnQgdG8gbWFrZSB0aGluZ3MgaGFyZC4gIEkgd2FudCB0byBtYWtlIHRoZW0gY2xlYXIg YW5kIG1lcmdpbmcNCiB0d28gc2V0cyBvZiBkYXRhIHdpdGggZGlmZmVyZW50IHNlY3VyaXR5IHBy b3BlcnRpZXMgZG9lcyBub3Qgc2VlbSBsaWtlIGl0J3MNCiBoZWxwZnVsLg0KDQo= From nobody Wed May 3 19:32:04 2017 Return-Path: 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 E0271128C84 for ; Wed, 3 May 2017 19:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L_sVkNMs-5R9 for ; Wed, 3 May 2017 19:32:01 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EECB129443 for ; Wed, 3 May 2017 19:32:01 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id h4so435978lfj.3 for ; Wed, 03 May 2017 19:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lOAe5EVvMpNjl/VLLWwG0O1LnAppSW2bMDbX0cPJQdw=; b=UE0Rt+sPOyL2GXTnr0YiJLaIgIqbLz3j/lukREyaul9j1AxOJFkIZjK2CkDf7836HQ McWCaunsCJGCAvncy0EoAZTnrRmZ73MRy37XfIlAiyolGptp9W6Oc7Urf2GrT0a9woL3 8tcXhToPRy0oU+a26IZbjuNiRDxH0dW3Iltcv/MDf0Cey1IQV7sMD5ZCjzFPHiVPXTC7 rmN5mEGhnQAD2kAj3oxYmaQXevyNGc+3KXDJKUHFmSFx8kLxgVYIICaIqSmCHqx9W3WC xlg6oVEeUDJdsA69AdGc/VElGmQYEWh9aDvPF8qdYfYwKgFAs01P3Z6l6lMEP+ZTrLBU 1aAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lOAe5EVvMpNjl/VLLWwG0O1LnAppSW2bMDbX0cPJQdw=; b=m0AmT1U6inyf8wyAK5rFdgpluqRTG8pU3dSWyRL9W5Ld79S3Br6lGa7thWFL4GINS8 gI9s11rGrFBFTxvLJL+b1QKWYRtmlnSgiwBcV4C+96xe0o4pGbNfh3D6rYNkQ6f6LSBR CaYFJDz7pUWNwAlmuo0W7//pYoxKeBV2332oMKMyHkY/kG7QzRFSzzRotBTFtq0bseqv FUxhzGV4Zerdw8+RteQ92yjbNC1FYvjQLqIyejlgLouL7/liDMWBDF28CRNsAsu5++nE RrUPsBRAtNPn35CQzkV42ne1by5PUQGPiw+TeQAlucMbG3tKReVi7yAUz9HjvGotKDI1 xVFg== X-Gm-Message-State: AN3rC/4fowXVopPh0kEf0lDhwJbT5bxR4EyQy1HtF0+c9QjhFqMXHME6 QzHEWGCB2zc7/X4KYXChS0DklSuVQg== X-Received: by 10.25.76.6 with SMTP id z6mr12890412lfa.172.1493865119559; Wed, 03 May 2017 19:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 19:31:58 -0700 (PDT) In-Reply-To: <5242af630cb14f29847455c2de6ceb81@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <74c5b8f9c44149dda3b26ed833588eed@ustx2ex-dag1mb1.msg.corp.akamai.com> <5242af630cb14f29847455c2de6ceb81@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 4 May 2017 12:31:58 +1000 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:32:03 -0000 On 4 May 2017 at 12:29, Salz, Rich wrote: > That's kind of inflammatory. Apology accepted :) Yep, a bit stronger than ideal, sorry. > I don't want to make things hard. I want to make them clear and merging > two sets of data with different security properties does not seem like it's > helpful. A clear delineation of security properties exists, if the handshake is done, then you are in the clear. Otherwise, beware. The separation of the streams doesn't help if you consider the possibility that 0-RTT data can be retroactively blessed. I agree that it's complicated and we'll need to learn more. I fully appreciate that you want to be conservative in how to implement this feature. As a predominantly client stack with far fewer consumers, I guess we are taking a few more liberties. Are we not both entitled to our own approaches in this regard? From nobody Wed May 3 19:33:16 2017 Return-Path: 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 1E94B128C84 for ; Wed, 3 May 2017 19:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 5CnCSRwpXoFN for ; Wed, 3 May 2017 19:33:13 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 022CA129A90 for ; Wed, 3 May 2017 19:33:05 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v442X34U030351; Wed, 3 May 2017 22:33:03 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Watson Ladd CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "tls@ietf.org" Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NiXcHbVvPnEkesiQuNcCSyO6Hil+WAgAA6vACAAKqpgIAAJd0AgAAIPYCAAA6EAA== Date: Thu, 4 May 2017 02:33:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-E992D020-D956-491A-BB2F-2E513EF0EC57"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040039 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:33:15 -0000 --Apple-Mail-E992D020-D956-491A-BB2F-2E513EF0EC57 Content-Type: multipart/alternative; boundary=Apple-Mail-8DD54393-47B1-4796-9E7A-125D8A3A6218 Content-Transfer-Encoding: 7bit --Apple-Mail-8DD54393-47B1-4796-9E7A-125D8A3A6218 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Q2hvc2Ugbm90IHRvIHByb3ZpZGUgcmVwbGF5IHByb3RlY3Rpb24/ISBJIGhhdmUgdG8gYWdyZWUg d2l0aCBDb2xtIC0gaXQgZG9lc24ndCBzb3VuZCBnb29kLiANCg0KQ2FyZSB0byBqdXN0aWZ5Pw0K DQpQLlMuIENhcmUgdG8gbmFtZSAoYW5vdGhlciA6KSBvbmUgc2VjdXJpdHktcmVsYXRlZCBwcm90 b2NvbCB0aGF0IGRvZXNuJ3QgcHJvdmlkZSByZXBsYXkgcHJvdGVjdGlvbj8NCg0KUmVnYXJkcywN ClVyaQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24gTWF5IDMsIDIwMTcsIGF0IDIxOjQy LCBDb2xtIE1hY0PDoXJ0aGFpZ2ggPGNvbG1AYWxsY29zdHMubmV0PiB3cm90ZToNCj4gDQo+IA0K PiANCj4+IE9uIFdlZCwgTWF5IDMsIDIwMTcgYXQgNjoxMSBQTSwgV2F0c29uIExhZGQgPHdhdHNv bmJsYWRkQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiBIaXN0b3JpY2FsbHkgVExTIHByb3RlY3RlZCBh Z2FpbnN0IHJlcGxheSBhdHRhY2tzLiBOb3cgaXQgZG9lc24ndC4gQW4NCj4+IGFwcGxpY2F0aW9u IHRoYXQgcmVsaWVzIG9uIHRoaXMgcHJvcGVydHkgd2hpY2ggVExTIHVzZWQgdG8gZ3VhcmFudGVl DQo+PiBpcyBub3cgYnJva2VuLiBDbGVhcmx5IHdlIGNvdWxkIGhhdmUgcHJvdmlkZWQgaXQsIHdl IGp1c3QgY2hvc2Ugbm90DQo+PiB0by4NCj4gDQo+IEFuZCB0aGF0IGNob2ljZSBpcyBpbnNlY3Vy ZS4gSWYgaXQncyB0byBiZSBrZXB0LCBJJ2Qgc3VnZ2VzdCByZW5hbWluZyB0aGUgcHJvdG9jb2wu IA0KPiANCj4gLS0gDQo+IENvbG0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== --Apple-Mail-8DD54393-47B1-4796-9E7A-125D8A3A6218 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+Q2hvc2Ug bm90IHRvIHByb3ZpZGUgcmVwbGF5IHByb3RlY3Rpb24/ISBJIGhhdmUgdG8gYWdyZWUgd2l0aCBD b2xtIC0gaXQgZG9lc24ndCBzb3VuZCBnb29kLiZuYnNwOzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFp bFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+Q2FyZSB0 byBqdXN0aWZ5PzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2Pjxk aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+UC5TLiBDYXJlIHRvIG5hbWUgKGFub3RoZXIgOikg b25lIHNlY3VyaXR5LXJlbGF0ZWQgcHJvdG9jb2wgdGhhdCBkb2Vzbid0IHByb3ZpZGUgcmVwbGF5 IHByb3RlY3Rpb24/PGJyPjxicj5SZWdhcmRzLDxkaXY+VXJpPC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PC9kaXY+PGRpdj48YnI+T24gTWF5IDMsIDIw MTcsIGF0IDIxOjQyLCBDb2xtIE1hY0PDoXJ0aGFpZ2ggJmx0OzxhIGhyZWY9Im1haWx0bzpjb2xt QGFsbGNvc3RzLm5ldCI+Y29sbUBhbGxjb3N0cy5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwv ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXYgZGlyPSJsdHIi Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij5PbiBXZWQsIE1heSAzLCAyMDE3IGF0IDY6MTEgUE0sIFdhdHNvbiBMYWRkIDxzcGFuIGRpcj0i bHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOndhdHNvbmJsYWRkQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPndhdHNvbmJsYWRkQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5IaXN0b3JpY2FsbHkgVExTIHBy b3RlY3RlZCBhZ2FpbnN0IHJlcGxheSBhdHRhY2tzLiBOb3cgaXQgZG9lc24ndC4gQW48YnI+DQph cHBsaWNhdGlvbiB0aGF0IHJlbGllcyBvbiB0aGlzIHByb3BlcnR5IHdoaWNoIFRMUyB1c2VkIHRv IGd1YXJhbnRlZTxicj4NCmlzIG5vdyBicm9rZW4uIENsZWFybHkgd2UgY291bGQgaGF2ZSBwcm92 aWRlZCBpdCwgd2UganVzdCBjaG9zZSBub3Q8YnI+DQp0by48YnI+PC9ibG9ja3F1b3RlPjxkaXY+ PGJyPjwvZGl2PjxkaXY+QW5kIHRoYXQgY2hvaWNlIGlzIGluc2VjdXJlLiBJZiBpdCdzIHRvIGJl IGtlcHQsIEknZCBzdWdnZXN0IHJlbmFtaW5nIHRoZSBwcm90b2NvbC4mbmJzcDs8L2Rpdj48L2Rp dj48ZGl2Pjxicj48L2Rpdj4tLSA8YnI+PGRpdiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIiBkYXRh LXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj5Db2xtPC9kaXY+DQo8L2Rpdj48L2Rpdj4NCjwv ZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bh bj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86VExTQGll dGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9i b2R5PjwvaHRtbD4= --Apple-Mail-8DD54393-47B1-4796-9E7A-125D8A3A6218-- --Apple-Mail-E992D020-D956-491A-BB2F-2E513EF0EC57 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4 MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd 8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg 1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4 HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK +4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8 F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01 Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+ BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s 6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p 6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2 oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1 RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G /HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9 Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwNTA0MDIzMzAyWjAjBgkqhkiG9w0BCQQxFgQUzlPxtkhXOYGO WxlMM6vsy/5D9PYwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBACbBosUImZ75MnII1O+o5vQGEOJsOVrI/yquiej9 IrPMHzsatNfMHbte9LDpoXe6+s7oSUs4/objlPm2QPZNFMBx9SOSNfKX+4yuMTozHXlxTShX4xOG YHPvzhgB04w3MB2Qrni+b5YvJq3hfqDAb2tWtviSd4oA4WZ8t/yrvW3TZdGDDOrcWSw7FJA/kW43 oFBGt9BUbMguZ6AKX30q/i11bRxAzlJoHVCgPKeMD9kImQKJf2+vduRqfu0lGim9RXb6DePIY/G0 HyOAH3moj5inQ4OVYBwaDOeQciDOwCGZJxkSd2NWz2zFo210ogIG7dXeEX+6mSNm8Cy+lEhUKwIA AAAAAAA= --Apple-Mail-E992D020-D956-491A-BB2F-2E513EF0EC57-- From nobody Wed May 3 20:14:06 2017 Return-Path: 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 19C45129AD0 for ; Wed, 3 May 2017 20:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 L7c8_Ax-c5Yi for ; Wed, 3 May 2017 20:14:02 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC4412957A for ; Wed, 3 May 2017 20:14:02 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id s22so366154ybe.3 for ; Wed, 03 May 2017 20:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vn3o0v18ecwI5+ze5Yz2dBaJ3/57+Ku6idXxEk1x9Nk=; b=cQcBK/09tAsfz9b2F3UfjZvLIG3HCmL6bySyF5NAdKqA52rKLqH32M3Tv1sM2oSGvd Ci6V32fJriA5vAOQepj13mtEI7kw59fpzYJVDmcGg3f1G260KvpvVsW+qRZAS/q19emt h4Z5BWE3VZdtlyQeACF+iE2InWG1dyp0FfW1Y8wOL6aH4JQFu7nWcXWTfaONpbQL1yXm L+T5oO36M96oJVuW5HKiwTy4OQSqrSYbvmkaWdsVcyIPLzfg0VHW7N2S/eTwUaemCXm5 d7j1CgDZEeIG5OrqUME0+C7oT8KaNfECU/Je6JSywaBi8wJzomsiNXMu7FGFLR3ynKjP bP/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vn3o0v18ecwI5+ze5Yz2dBaJ3/57+Ku6idXxEk1x9Nk=; b=KaV9tVQK1mCwnNlyVM6kZmCten91o0cfevE1+Fy+xOnYI+QspKNDuqkwAS2WlxDMJm L45wblneymvG5xMwB6ZR1wXdifxM1/IukuNNBoZQ5lMWXxcgSNfXq4UQ3Ji5Ls4LGj9l OBjh5Tk92U6SdqYjJebwljiOb5TlR2GoRBpvCbn7MDCvJfbo9yWeK9+AhcbmrNVDgLxX 7vwbAphBxSHW1U6YVFJ3qfhEaEr+NZ+jejcy8UCcfM9p5NseLKuYmXQ7sNWDW3uw3b3s oUdCPYTlqw7NIOgeMUQCivv8/JSNLP3jnOfycsr8N3YWRLdmB6uC32aTs2dyGSQrYoYS vjNQ== X-Gm-Message-State: AN3rC/7quo4E5KROFjsLdUYQDWuAIa7F8/UPja4mm40Y7RiXGO+R1BDO NQ5FaXqS8e/HsdAFf1y94zjlAPNDXbIyKSE= X-Received: by 10.37.174.24 with SMTP id a24mr32678532ybj.50.1493867641771; Wed, 03 May 2017 20:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 3 May 2017 20:13:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 May 2017 20:13:20 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045da3582136b7054eaa2ae9 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 03:14:05 -0000 --f403045da3582136b7054eaa2ae9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Deliberately responding to the OP rather than to anyone in particular] Hi folks, I'm seeing a lot of back and forth about general philosophy and the wisdom of 0-RTT but I think it would be useful if we focused on what changes, if any, we need to make to the draft. I made some proposals yesterday (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). Specifically: 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both session-cache and strike register styles and the merits of each. 2. Document 0-RTT greasing in draft-ietf-tls-grease 3. Adopt PR#448 (or some variant) so that session-id style implementations provide PFS. 4. I would add to this that we recommend that proxy/CDN implementations signal which data is 0-RTT and which is 1-RTT to the back-end (this was in Colm's original message). Based on Colm's response, I think these largely hits the points he made in his original message. There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow. What would be most helpful to me as Editor would be if people could review these PRs and/or suggest other specific changes that we should make to the document. Thanks, -Ekr On Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh = wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2= n. > Thanks to feedback in the room I've now tightened up the findings from th= e > review and posted them as an issue on the draft GitHub repo: > > https://github.com/tlswg/tls13-spec/issues/1001 > > I'll summarize the summary: Naturally the focus was on forward secrecy an= d > replay. On forward secrecy the main finding was that it's not necessary t= o > trade off Forward Secrecy and 0-RTT. A single-use session cache can provi= de > it, and with the modification that ekr has created in > https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for > both pre-auth and post-auth tickets, and it allows clients to build up > pools of meaningfully distinct tickets. > > There's also an observation there that it should really be that clients > "MUST" use tickets only once. Any re-use likely discloses the obfuscated > ticket age, which is intended to be secret. Right now it's a "SHOULD". > > On replay, the main finding is that what's in the draft is not workably > secure, and the review includes 5 different attacks against 0-RTT data to > illustrate that. Attacks 1 and 2 show that the kind of replay permitted b= y > the draft is very different from the kind of replay permitted by dkg's > existing downgrade-and-retry attack. I also go over why it very very > difficult to many applications to achieve that idempotency, and why one > idempotency pattern actually relies on non-replayable messages. > > Attack 3 shows that idempotency is not sufficient, applications must also > be free of measurable side-effects, which is not practical. Attack 4 sho= ws > that 0-RTT breaks a common security mechanism: spoofing-resistant > throttles. Attack 5 shows that 0-RTT replay-ability enables an additional > form of traffic analysis. > > The recommendation in the review is that implementations "MUST" prevent > replays of 0-RTT section, with some additional discussion about why the > existing advice is unlikely to be followed, and why consistent > interoperability matters here. > > Unfortunately, I wasn't aware until Friday that this review would be > coming so late in the TLD1.3 draft process, and my apologies for that. I = am > now planning to attend the future WG in-person meetings and look forward = to > seeing many of you there. > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403045da3582136b7054eaa2ae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Deliberately responding to the OP rather than to anyone i= n particular]

Hi folks,

I'm= seeing a lot of back and forth about general philosophy and the
= wisdom of 0-RTT but I think it would be useful if we focused on what
<= div>changes, if any, we need to make to the draft.=C2=A0

I made some proposals yesterday=C2=A0

Specifically:
1. A SHOULD-level requirement for server-side 0-R= TT defense, explaining
both session-cache and strike register sty= les and the merits of each.

2. Document 0-RTT grea= sing in draft-ietf-tls-grease

3. Adopt PR#448 = (or some variant) so that session-id style implementations
provid= e PFS.

4. I would add to this that we recommend th= at proxy/CDN implementations
signal which data is 0-RTT and which= is 1-RTT to the back-end (this was in
Colm's original messag= e).

Based on Colm's response, I think these la= rgely hits the points he made
in his original message.
=
There's already a PR for #3 and I'll have PRs for #1= and #4 tomorrow.
What would be most helpful to me as Editor = would be if people could review
these PRs and/or suggest other sp= ecific changes that we should make
to the document.
Thanks,
-Ekr


=

O= n Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh <= ;colm@allcosts.net> wrote:
I'll summarize the summary: Naturally the focus was = on forward secrecy and replay. On forward secrecy the main finding was that= it's not necessary to trade off Forward Secrecy and 0-RTT. A single-us= e session cache can provide it, and with the modification that ekr has crea= ted in=C2=A0https://github.com/tlswg/tls13-spec/pull/998 , such a = cache works for both pre-auth and post-auth tickets, and it allows clients = to build up pools of meaningfully distinct tickets.

There's also an observation there that it should really be that clien= ts "MUST" use tickets only once. Any re-use likely discloses the = obfuscated ticket age, which is intended to be secret. Right now it's a= "SHOULD".=C2=A0

On replay, the main fin= ding is that what's in the draft is not workably secure, and the review= includes 5 different attacks against 0-RTT data to illustrate that. Attack= s 1 and 2 show that the kind of replay permitted by the draft is very diffe= rent from the kind of replay permitted by dkg's existing downgrade-and-= retry attack. I also go over why it very very difficult to many application= s to achieve that idempotency, and why one idempotency pattern actually rel= ies on non-replayable messages.=C2=A0

Attack 3 sho= ws that idempotency is not sufficient, applications must also be free of me= asurable side-effects, which is not practical.=C2=A0 Attack 4 shows that 0-= RTT breaks a common security mechanism: spoofing-resistant throttles. Attac= k 5 shows that 0-RTT replay-ability enables an additional form of traffic a= nalysis.=C2=A0

The recommendation in the review is= that implementations "MUST" prevent replays of 0-RTT section, wi= th some additional discussion about why the existing advice is unlikely to = be followed, and why consistent interoperability matters here.=C2=A0
<= div>
Unfortunately, I wasn't aware until Friday that this= review would be coming so late in the TLD1.3 draft process, and my apologi= es for that. I am now planning to attend the future WG in-person meetings a= nd look forward to seeing many of you there.=C2=A0

--
Colm

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--f403045da3582136b7054eaa2ae9-- From nobody Wed May 3 20:15:35 2017 Return-Path: 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 AC23212957A for ; Wed, 3 May 2017 20:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 xMs7BRnwVDBq for ; Wed, 3 May 2017 20:15:31 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47072129AB6 for ; Wed, 3 May 2017 20:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1493867731; x=1525403731; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jRQ2DZdVnCWZFemllj8OeWZ6TlZef8O5xXjHxqmZH1I=; b=cSvUIU3/6ni4N6/Ehn3db11ShX6G3j8QxUmkgIpinrmdO/znhFG9xZP3 c/to/2U4AX1eUOfyQ4h+nhIzGp248se7yH4VBfE2xfmKNRAwG9lwFaIQ4 hSyrXtUU59P9TL5z1dgygs2GQMfQdg05pVQZGYXOD0BXLYd+6ylA0GNv6 uQhhRqyxhwYJFp9kfNLlywvo2NptUTPrA0WNdt6mFYbjnu7FdbfTEa7Pq 3emTFTE1aB55EaAWt9PoQpQMBirB5ofU3yRctGM/7Fdqkurh6QYjN0Esb xuSTkm+lEBrRrqHyx38PZa5rkmYx2YOwGg8CfVw9BE5ddlQI+eECaAPo6 A==; X-IronPort-AV: E=Sophos;i="5.38,286,1491220800"; d="scan'208";a="152801708" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 May 2017 15:15:19 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 15:15:18 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Thu, 4 May 2017 15:15:18 +1200 From: Peter Gutmann To: Nico Williams CC: Benjamin Kaduk , TLS WG Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NPTAGYfwrCc0yRmMInbVKyjKHghKSAgAABiQCAAAKfgIAAA3MAgAAEtgCAAAIuAIAABAyAgAEfkNP//4MDgIACSLpH Date: Thu, 4 May 2017 03:15:18 +0000 Message-ID: <1493867699216.865@cs.auckland.ac.nz> References: <20170502173905.GC10188@localhost> <20170502180049.GE10188@localhost> <20170502182529.GG10188@localhost> <1493768953994.69753@cs.auckland.ac.nz>,<20170503042150.GM10188@localhost> In-Reply-To: <20170503042150.GM10188@localhost> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 03:15:34 -0000 Nico Williams writes:=0A= =0A= >Yeah, but a non-persistent clock is fine if the client can learn time from= =0A= >the server (and keep a different offset from system time to every server i= f=0A= >need be, learning system time from one of them, or from NTP, or whatever).= =0A= =0A= In many cases neither the server nor the client have clocks. They also don= 't=0A= have much provision for keeping track of persistent state across devices.= =0A= =0A= Overall though it's a bit of a moot point because it's unlikely these devic= es=0A= will ever do TLS 1.3 (it's going to be enough of a pain eventually moving t= hem=0A= to 1.2), I was just pointing out that you can't assume the presence of a=0A= clock. It may be perfectly OK to assume that anything that'll ever do 1.3= =0A= also has an accurate(ish) time source available.=0A= =0A= Peter.=0A= From nobody Wed May 3 20:20:13 2017 Return-Path: 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 BFC89129B35 for ; Wed, 3 May 2017 20:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 oZKQByRIo_Qz for ; Wed, 3 May 2017 20:20:07 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA33129B49 for ; Wed, 3 May 2017 20:20:04 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l135so757450ywb.2 for ; Wed, 03 May 2017 20:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oiUGpUVhN9wNUXuC/QjBPphv0odOOLgsOthkPcXelm8=; b=n/fYSEbaljIa9l/QL3CpT692qbSgi7ydaeiQYj2WixVmdEhkOXMBQqEZnqU4kx5RrH 3s3UuBemNxmvaQMyt0+oKjUGJkEcP8JuGc7lg+LNWGW5ic1qLlK2vEu/NcadMZnmkmJw KCVbF6z1IvmGFIa/Cf0bHYKXkU+ZeCDmuasSipBf0gtxX5o0Sc1aqB1t9VKCR6HWuDde XfIjpvwbUM2/oo5Vb6LPSERAn4AqwhyHBKTxuTX4W8ElrfwMvvUWOg6m884FpjfVjgQ8 HgucwHeMVB6Ague5dWbaa2OUjRXjIP43uSxcgUR5AAsPPm5adM/ki8PiVF9FWitCFVOJ pang== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oiUGpUVhN9wNUXuC/QjBPphv0odOOLgsOthkPcXelm8=; b=jP2Pk4uGh2pAc5JvHz1COHTq4gbj/CVIvVP/vHKKo3W8XASjqwM+A+wT8eSmWW85Wf U7OCFAIRfq4lKBSOtoLFM18Zik0wAEBdNhvt3PeB6OI24tEPwyeoOTVQwXfGAIk4ZwI+ 5hvY/Eu0AbvqPneVISS6qmFTo3DcCcXzXwBKd+rrS+MMH6bqKAKXG5XVvd5k0v1fxTQh p/gI5Alkt/lgjg9pMf2MQiDRyqMRosWxbuyMM9IikAuCfOjwl2MwqrXMYVfBAZtiwdhz WpRmg16RBHxrJJ7vKwBdI21N2REej8jtV2oKbEMfI4iI0o8aqonxFWts3K4qvyWNkW7E cq+g== X-Gm-Message-State: AN3rC/5R/b1/MjyBcZvgZie5/puCQcZ8UjSOE6sSTbJjyrcK/OM0Dacf ISoZ9U1oUSxnPWvSey//CyT+XJn+U7NbFsc= X-Received: by 10.129.56.11 with SMTP id f11mr35154964ywa.241.1493868003328; Wed, 03 May 2017 20:20:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 20:20:02 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 20:20:02 -0700 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11483b10ae33ad054eaa3f63 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 03:20:12 -0000 --001a11483b10ae33ad054eaa3f63 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla wrote: > I made some proposals yesterday > (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). > > Specifically: > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > both session-cache and strike register styles and the merits of each. > > 2. Document 0-RTT greasing in draft-ietf-tls-grease > > 3. Adopt PR#448 (or some variant) so that session-id style implementations > provide PFS. > > 4. I would add to this that we recommend that proxy/CDN implementations > signal which data is 0-RTT and which is 1-RTT to the back-end (this was in > Colm's original message). > This all sounds great to me. I'm not sure that we need (4.) if we have (1.). I think with (1.) - recombobulating to a single stream might even be best overall, to reduce application complexity, and it seems to be what most implementors are actually doing. I know that leaves the DKG attack, but from a client and servers perspective that attack is basically identical to a server timeout, and it's something that systems likely have some fault tolerance around. It's not /new/ broken-ness. > Based on Colm's response, I think these largely hits the points he made > in his original message. > > There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow. > What would be most helpful to me as Editor would be if people could review > these PRs and/or suggest other specific changes that we should make > to the document. > Will do! Many thanks. -- Colm --001a11483b10ae33ad054eaa3f63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla <ekr@rtfm.com> = wrote:
I made some proposals yesterday= =C2=A0

Specifical= ly:
1. A SHOULD-level requirement for server-side 0-RTT defense, = explaining
both session-cache and strike register styles and the = merits of each.

2. Document 0-RTT greasing in draf= t-ietf-tls-grease

3. Adopt PR#448 (or some var= iant) so that session-id style implementations
provide PFS.
=

4. I would add to this that we recommend that proxy/CDN= implementations
signal which data is 0-RTT and which is 1-RTT to= the back-end (this was in
Colm's original message).

This all sounds great to me. I'm no= t sure that we need (4.) if we have (1.).=C2=A0 I think with (1.) - recombo= bulating to a single stream might even be best overall, to reduce applicati= on complexity, and it seems to be what most implementors are actually doing= . =C2=A0

I know that leaves the DKG attack, but fr= om a client and servers perspective that attack is basically identical to a= server timeout, and it's something that systems likely have some fault= tolerance around. It's not /new/ broken-ness.=C2=A0
=C2=A0
Based on Colm's response, I = think these largely hits the points he made
in his original messa= ge.

There's already a PR for #3 and I'll h= ave PRs for #1 and #4 tomorrow.
What would be most helpful to= me as Editor would be if people could review
these PRs and/or su= ggest other specific changes that we should make
to the document.=

Will do! Many thanks.=C2=A0

--
Colm
--001a11483b10ae33ad054eaa3f63-- From nobody Wed May 3 20:22:21 2017 Return-Path: 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 383E9129B4B for ; Wed, 3 May 2017 20:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 uxGYfEaDLzSb for ; Wed, 3 May 2017 20:22:17 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39B1129B3A for ; Wed, 3 May 2017 20:22:14 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id k11so784353ywb.1 for ; Wed, 03 May 2017 20:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIkMMAvNFCA/GPP9zstjWOY0dV1zV7VRS+Utw2Gzmw8=; b=DKYFLPf6U9qZ7eUhRylWyAiN8DjdVGHYGmQtsDtyJxUYS7XaAetmnVbqf21pPsuOf5 LBK4gwbeKEb2yrBfQbre3i2G4niDnO5BtOhPP3rYfft3VJxy23K+xSBAzuMTtpBKgt4l 8/cdGC3gulNdbp7Eka1okHzbxu8MRWDSM+LOKhsfr0AjigE15k1n4Bbx0clNUD+8iO7M B6Va2eX03c4dGOPYycd4NPeX8tXgA/ol6rKtlAZKYJ7iTnBkoxPj0ncdW0WstV4DqF1C Go2GmXlz3e4o+BGcclLeHZpCRSRx4LdKzr9uNn/NkXo4FkOaCRdhSoEW6Wd7UAFP6znZ w2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIkMMAvNFCA/GPP9zstjWOY0dV1zV7VRS+Utw2Gzmw8=; b=KBB9QE+fmUPL54Jj64m+4e+DFf2/3uiZ0hwl8EGktTWHlzf21BeldQEzRDJM4VIb60 xjtJ9irv5ZiPxtwV/pbppe8onuC1WhKkMr8+9aOD2HFYPKVAFiETN+HdAbwLy+NYHRJh FGfEfNpyxMtjKV/IZCUk1UkmPA4YARUj6PR7fx/A6SYoYXQ+3QPiXJ28mF+DNRNbiPZm DBjLCpn+b9qQV2jDchaNZ+mvOQKFMKwcZxvX72P2bg1YZipjXHyeBVtl9hyOqWrB0NOs oyuJ/MSAXlrXAOLTC7gA7jdvpIfzzIcPjwBhqn4t2TCTmqfTF1/FBpsZp6OR3afNFpud 3s1A== X-Gm-Message-State: AN3rC/4xjHoEhYEZQM7h2OZK2dVQYRB7qOrDYKOYoxETa8oWORVPzO60 rrEVOvid4CLX1u2OpYqNpbjmg14wuzvV X-Received: by 10.129.146.78 with SMTP id j75mr5283078ywg.3.1493868134193; Wed, 03 May 2017 20:22:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 3 May 2017 20:21:33 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 May 2017 20:21:33 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0935047af524054eaa471f Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 03:22:19 -0000 --94eb2c0935047af524054eaa471f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2017 at 8:20 PM, Colm MacC=C3=A1rthaigh = wrote: > > > On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla wrote: > >> I made some proposals yesterday >> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). >> >> Specifically: >> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >> both session-cache and strike register styles and the merits of each. >> >> 2. Document 0-RTT greasing in draft-ietf-tls-grease >> >> 3. Adopt PR#448 (or some variant) so that session-id style implementatio= ns >> provide PFS. >> >> 4. I would add to this that we recommend that proxy/CDN implementations >> signal which data is 0-RTT and which is 1-RTT to the back-end (this was = in >> Colm's original message). >> > > This all sounds great to me. I'm not sure that we need (4.) if we have > (1.). I think with (1.) - recombobulating to a single stream might even = be > best overall, to reduce application complexity, and it seems to be what > most implementors are actually doing. > > I know that leaves the DKG attack, but from a client and servers > perspective that attack is basically identical to a server timeout, and > it's something that systems likely have some fault tolerance around. It's > not /new/ broken-ness. > Heh. Always happy to do less writing. Thanks, -Ekr > > >> Based on Colm's response, I think these largely hits the points he made >> in his original message. >> >> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow. >> What would be most helpful to me as Editor would be if people could revi= ew >> these PRs and/or suggest other specific changes that we should make >> to the document. >> > > Will do! Many thanks. > > -- > Colm > --94eb2c0935047af524054eaa471f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 8:20 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.= net> wrote:


On We= d, May 3, 2017 at 8:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I made some proposals yesterday=C2=A0

Specifically:
=
1. A SHOULD-level requirement for server-side 0-RTT defense, explainin= g
both session-cache and strike register styles and the merits of= each.

2. Document 0-RTT greasing in draft-ietf-tl= s-grease

3. Adopt PR#448 (or some variant) so = that session-id style implementations
provide PFS.

=
4. I would add to this that we recommend that proxy/CDN implemen= tations
signal which data is 0-RTT and which is 1-RTT to the back= -end (this was in
Colm's original message).

This all sounds great to me. I'm not = sure that we need (4.) if we have (1.).=C2=A0 I think with (1.) - recombobu= lating to a single stream might even be best overall, to reduce application= complexity, and it seems to be what most implementors are actually doing. = =C2=A0

I know that leaves the DKG attack, but from= a client and servers perspective that attack is basically identical to a s= erver timeout, and it's something that systems likely have some fault t= olerance around. It's not /new/ broken-ness.=C2=A0

Heh. Always happy to do less writing.

Thanks,
-Ekr
=C2=A0
=C2=A0
Based on Colm's response, I think these largely hits the points= he made
in his original message.

There&= #39;s already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
=
What would be most helpful to me as Editor would be if people co= uld review
these PRs and/or suggest other specific changes that w= e should make
to the document.

<= /div>
Will do! Many thanks.=C2=A0

--
Col= m

--94eb2c0935047af524054eaa471f-- From nobody Wed May 3 21:00:08 2017 Return-Path: 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 990FB129B43 for ; Wed, 3 May 2017 21:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 WEX66cfB2C9T for ; Wed, 3 May 2017 21:00:05 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879DE129B49 for ; Wed, 3 May 2017 21:00:04 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id j17so531264ybj.0 for ; Wed, 03 May 2017 21:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K+wVRFo4enygCnauWyVnN7ZlriT3ogmd9XfpyjKBqKY=; b=iWbNQ0imCgPrTGCQ7YpOWv4OBN+a0x+s3mCJcuSOiaFn8PvLiHGO28UZQ/WW5Hkm3z fkuC6nXLVJ4ZY4byPiz3MG2hOhoIwQrXk8zVT3KIApDavrmLS10FJUk8EwV8RRMeP5Q9 zOBP46InFlNql733zBh0kiJcyHCqHGS0fFmp1GXILT8lq9mXXHnBSBEoTsbvioWdWHxR IEwCYjUW0IQROPwsPAQIkxgXPlnxcOu0wUosUUr5D89emvmxEVP7jpoL7gCTn+UOxNY9 pfT1CvgWUyYzimSt1t7uaqNT95xS7yz7tijKPqz0ig/AlFXQZwPC0CDyxP+q7S4s0XJh Z0SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K+wVRFo4enygCnauWyVnN7ZlriT3ogmd9XfpyjKBqKY=; b=O8JbNByCKjsiOnvc2U3Btz6bu/sGDkRqN8cnVP96tKshwB74Cp9PCx19T90EeAmQQj fpT0Io8nzYzI0Avv4hqQr8DzIbOUYsDqW8lz/TTDiMrx/o18iAEpj4cCWSX9Wdeewx1v 92vupxlrAkkePzJiTenwb9Pg8z3EoNdCWQfz3/YTIgtDIgpgkLptxqJinFP3ImviyLA4 dS8y6LszKSkq0CslEEnviBjNjTy2swbfLMemFfuYSj9FGYwVN+i+ojo7POnSDpSRSxst dfCoAfXCjD8AJqkvZ+4diKsvs2itI8OIfAHhcvInB2HEjR3tL7ZdINGn4qTmbRmwoLiF Ym8Q== X-Gm-Message-State: AN3rC/5F2DwHAOnrtWyd87NvkaqAchWz/2Zbuc40zcw7EuEOMW1sx0Qm 5cDCCtpzzwTCgT55t9SV7Rlf4PfMgg== X-Received: by 10.37.163.195 with SMTP id e61mr17541221ybi.13.1493870403582; Wed, 03 May 2017 21:00:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 21:00:03 -0700 (PDT) In-Reply-To: References: <74c5b8f9c44149dda3b26ed833588eed@ustx2ex-dag1mb1.msg.corp.akamai.com> <5242af630cb14f29847455c2de6ceb81@ustx2ex-dag1mb1.msg.corp.akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 21:00:03 -0700 Message-ID: To: Martin Thomson Cc: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045c05f8bf315a054eaaced7 Archived-At: Subject: Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 04:00:08 -0000 --f403045c05f8bf315a054eaaced7 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 7:31 PM, Martin Thomson wrote: > A clear delineation of security properties exists, if the handshake is > done, then you are in the clear. Otherwise, beware. The separation > of the streams doesn't help if you consider the possibility that 0-RTT > data can be retroactively blessed. > > I agree that it's complicated and we'll need to learn more. I fully > appreciate that you want to be conservative in how to implement this > feature. As a predominantly client stack with far fewer consumers, I > guess we are taking a few more liberties. Are we not both entitled to > our own approaches in this regard? > I just wanted to chime in on this thread too and this: I think that single-stream is the way to go .. if servers prevent 0-RTT replays. That does leave the DKG attack, but I think that's ok. That might seem like a contradictory view from me, so here's my nuanced take: * The DKG attack is real and does cause the client to repeat a request. * It's basically impossible for the server to do anything about it. The ticket isn't re-used, so clever tricks like CloudFlare's X- header don't work here. I thought for a while that the server could maybe fingerprint the plaintext, but even that doesn't work, because a client might repeat it intentionally. * Thankfully this doesn't have to be a show-stopper. The failure mode is, I think, identical to existing time outs. The client knows that the request may have succeeded, or may have failed. At that point it's up to the client what to do. Browsers retry, makes sense for them. Other clients don't, good for them. But they get to choose; and it's compatible with today's behavior. From the server's perspective, the same is true - the server knows that the original client may not have received any response, because that connection fails. * So in broad terms, existing client and server behavior should cover us here; all of this happens when connections time out today - and an attacker can already cause that to happen. It's not a big ecosystem change to the layering we have already. * If the above logic holds; then the whole "needs a profile" stuff and signaling early data and application data to applications separately is needless complexity IMO. Probably more harm than good, and seems to be getting ignored anyway. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Colm --f403045c05f8bf315a054eaaced7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, May 3, 2017 at 7:31= PM, Martin Thomson <martin.thomson@gmail.com> wrote:=
A clear delin= eation of security properties exists, if the handshake is
done, then you are in the clear.=C2=A0 Otherwise, beware.=C2=A0 The separat= ion
of the streams doesn't help if you consider the possibility that 0-RTT<= br> data can be retroactively blessed.

I agree that it's complicated and we'll need to learn more.=C2=A0 I= fully
appreciate that you want to be conservative in how to implement this
feature.=C2=A0 As a predominantly client stack with far fewer consumers, I<= br> guess we are taking a few more liberties.=C2=A0 Are we not both entitled to=
our own approaches in this regard?

I ju= st wanted to chime in on this thread too and this:

I think that single-stream is the way to go .. if servers prevent 0-RTT re= plays.=C2=A0 That does leave the DKG attack, but I think that's ok. Tha= t might seem like a contradictory view from me, so here's my nuanced ta= ke:

* The DKG attack is real and does cause the cl= ient to repeat a request.

* It's basically imp= ossible for the server to do anything about it. The ticket isn't re-use= d, so clever tricks like CloudFlare's X- header don't work here. I = thought for a while that the server could maybe fingerprint the plaintext, = but even that doesn't work, because a client might repeat it intentiona= lly.

* Thankfully this doesn't have to be a sh= ow-stopper. The failure mode is, I think, identical to =C2=A0existing time = outs.=C2=A0 The client knows that the request may have succeeded, or may ha= ve failed. At that point it's up to the client what to do. Browsers ret= ry, makes sense for them. Other clients don't, good for them. But they = get to choose; and it's compatible with today's behavior.=C2=A0 Fro= m the server's perspective, the same is true - the server knows that th= e original client may not have received any response, because that connecti= on fails.=C2=A0

* So in broad terms, existing clie= nt and server behavior should cover us here; all of this happens when conne= ctions time out today - and an attacker can already cause that to happen. I= t's not a big ecosystem change to the layering we have already.=C2=A0

* If the above logic holds; then the whole "ne= eds a profile" stuff and signaling early data and application data to = applications separately is needless complexity IMO. Probably more harm than= good, and seems to be getting ignored anyway.=C2=A0


=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--
=
Colm
--f403045c05f8bf315a054eaaced7-- From nobody Thu May 4 02:34:38 2017 Return-Path: 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 5A2A5129329 for ; Thu, 4 May 2017 02:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 VuZVjZUQDWkp for ; Thu, 4 May 2017 02:34:35 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C5129549 for ; Thu, 4 May 2017 02:34:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id ADBB06010E; Thu, 4 May 2017 12:34:31 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Uz8V2FTmWJ5y; Thu, 4 May 2017 12:34:31 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 35A3527B; Thu, 4 May 2017 12:34:31 +0300 (EEST) Date: Thu, 4 May 2017 12:34:30 +0300 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Message-ID: <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 09:34:37 -0000 On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. > Thanks to feedback in the room I've now tightened up the findings from the > review and posted them as an issue on the draft GitHub repo: > > https://github.com/tlswg/tls13-spec/issues/1001 What I didn't see in the summary, but I think might be relevant in relation to 0-RTT: There is a thing called 0-RTT exporter, which are exporter values available during 0-RTT transmission. If the server uses 0-RTT exporter and doesn't enforce non-replay, the value grossly fails to be "nonce", which means it is likely unsafe to use for authentication. Unfortunately, there are protocols that are already discussing the use of TLS 1.3 0-RTT exporter, and switching to "full" exporter. Unfortunately, the easiest way is not to switch, which means the possibly weak 0-RTT exporter will be used for authenticating even non-replayable data. -Ilari From nobody Thu May 4 05:35:47 2017 Return-Path: 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 9DF73129406 for ; Thu, 4 May 2017 05:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 554h37L2zdDw for ; Thu, 4 May 2017 05:35:43 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE71120727 for ; Thu, 4 May 2017 05:35:41 -0700 (PDT) X-AuditID: c618062d-481ff70000000cf0-e5-590b331609ed Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.BE.03312.6133B095; Thu, 4 May 2017 15:56:41 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Thu, 4 May 2017 08:35:37 -0400 From: Daniel Migault To: Kathleen Moriarty CC: "" Thread-Topic: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02 Thread-Index: AQHSwqifdV6hw9ZNAEegoZnX4YzRJKHgiZKAgACnaQCAAu6ScA== Date: Thu, 4 May 2017 12:35:36 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BD82E2@eusaamb107.ericsson.se> References: <05FBCFBA-93BE-4314-830D-65528F6BAED9@gmail.com> In-Reply-To: <05FBCFBA-93BE-4314-830D-65528F6BAED9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD82E2eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonSlfSmDvSYNEtC4uGnfkWn853MTow eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGf8uPWEr+JVX0XtiHmsD44/sLkZODgkBE4kZ W9+ydTFycQgJHGWUuHaskxnCWcYo8XTHKWaQKjYBI4m2Q/3sILaIgIXEmuZvbCA2s4CyxOR/ d8DiwgIOEjev7GOCqHGUWHf1GFS9k8Syxg+sIDaLgIrE+68zwWp4BXwlVu27zAqx7BSjxNfG J2ANnAK2Eh8Ov2YBsRkFxCS+n1rDBLFMXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuErSTx8fd8 doj6fIneW0dZIJYJSpyc+YRlAqPILCSjZiEpm4WkbBYjB1BcU2L9Ln2IEkWJKd0P2SFsDYnW OXPZkcUXMLKvYuQoLS7IyU03MtjECIyeYxJsujsY70/3PMQowMGoxMO7QIorUog1say4MvcQ owQHs5IIr780d6QQb0piZVVqUX58UWlOavEhRmkOFiVx3gnnL0QICaQnlqRmp6YWpBbBZJk4 OKUaGI+9eW4/YTvz3M7a27lXSxrPKN0tPZ9p1tei4CxwZ1685S+dCYqFh52XW271Svx5qtWT 6/fKqbE3zS/cnHkxvH8171Xl9lVFWTW3zEobu0Sbdj10XG308hUj1+XE0KSXM9o/vE92zDK+ VNi+9d7mrTyd2w4GblqxncvixKG5LaW8J/4tkTllwazEUpyRaKjFXFScCAAQc/2NmgIAAA== Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 12:35:45 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD82E2eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk9vcHMsIEkgbWlzc2VkIHlvdXIgZW1haWwuIHRoZSB2ZXJzaW9uIDAzIGhhcyBiZWVu IHN1Ym1pdHRlZC4gRm9yIHNvbWUgcmVhc29uIG15IGVtYWlsIGFkZHJlc3MgaXMgbm90IGluIHRo ZSBkYXRhYmFzZSwgc28gaXQgaGFzIHRvIGJlIGNvbmZpcm1lZCBieSBzb21lb25lIGVsc2Ugb3Ig dGhlIHNlY3JldGFyaWF0Lg0KDQpZb3VycywNCkRhbmllbA0KDQpGcm9tOiBLYXRobGVlbiBNb3Jp YXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KU2VudDogVHVl c2RheSwgTWF5IDAyLCAyMDE3IDc6NDYgQU0NClRvOiBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1p Z2F1bHRAZXJpY3Nzb24uY29tPg0KQ2M6IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1RMU10gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1h ZWFkLTAyDQoNCkhpIERhbmllbCwNCg0KVGhhbmsgeW91LCBwbGVhc2UgcHVibGlzaCB2ZXJzaW9u IDMgYW5kIEknbGwga2ljayBvZmYgbGFzdCBjYWxsLiAgWW91IGNvdWxkIHVwZGF0ZSB0aGUgVExT IHZlcnNpb24gdG8gMjAgYXMgd2VsbCwgYnV0IHRoYXQncyBzb21ldGhpbmcgdGhhdCB3aWxsIGdl dCBmaXhlZCB3aXRoIHRoZSBSRkMgbnVtYmVyIHdoaWxlIGluIHRoZSBSRkMgZWRpdG9yIHF1ZXVl Lg0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9u IE1heSAxLCAyMDE3LCBhdCA5OjQ2IFBNLCBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRA ZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+PiB3cm90ZToN CkhpIEthdGhsZWVuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIEkgaGF2ZSBwcm9jZWVk ZWQgdG8gdGhlIHVwZGF0ZSBvZiBteSBsb2NhbCBjb3B5LiBUaGUgdGV4dCBpczoNCg0KIiIiDQpU aGUgY2lwaGVyIHN1aXRlIG51bWJlcnMgbGlzdGVkIGluIHRoZSBsYXN0IGNvbHVtbiBhcmUgbnVt YmVycyB1c2VkDQpmb3IgY2lwaGVyIHN1aXRlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhbmQg aXQncyBzdWdnZXN0ZWQgdGhhdCBJQU5BDQp1c2UgdGhlc2UgdmFsdWVzIGZvciBhc3NpZ25tZW50 Lg0KIiIiDQpPdGhlciBuaXRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgYXMgd2VsbC4NCklmIHRoYXQg aXMgZmluZSwgSSBjYW4gcHVibGlzaCB0aGUgdmVyc2lvbiAwMy4NCllvdXJzLA0KRGFuaWVsDQoN Cg0KT24gTW9uLCBNYXkgMSwgMjAxNyBhdCAyOjIzIFBNLCBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0 aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5Lmll dGZAZ21haWwuY29tPj4gd3JvdGU6DQpIZWxsbywNCg0KVGhhbmtzIGZvciB5b3VyIHdvcmsgb24g dGhlIGRyYWZ0IGRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLTAyLg0KDQpJbiB0aGUgSUFO QSBzZWN0aW9uLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgYml0IG1vcmUgY2xlYXIgdG8gc2F5IGlu DQp0aGUgbGFzdCBjb2x1bW4gcmF0aGVyIHRoYW4gc2Vjb25kIGNvbHVtbiB3aW5jZSBvbmUgbWln aHQgaW50ZXJwcmV0DQp0aGlzIGxpc3RpbmcgYXMgaGF2aW5nIDMgY29sdW1ucy4NCg0KICAgVGhl IGNpcGhlciBzdWl0ZSBudW1iZXJzIGxpc3RlZCBpbiB0aGUgc2Vjb25kIGNvbHVtbiBhcmUgbnVt YmVycyB1c2VkDQogICBmb3IgY2lwaGVyIHN1aXRlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBh bmQgaXQncyBzdWdnZXN0ZWQgdGhhdA0KICAgSUFOQSB1c2UgdGhlc2UgdmFsdWVzIGZvciBhc3Np Z25tZW50Lg0KDQpUaGUgcmVnaXN0cnkgaGFzIHRoaXMgcmV2ZXJzZWQgd2l0aCB0aGUgZGVzY3Jp cHRpb24gYXMgdGhlIHNlY29uZA0KY29sdW1uLCB3aGljaCBpcyBmaW5lLiAgSSdtIGp1c3QgcG9p bnRpbmcgdGhhdCBvdXQgYXMgaXQgZG9lc24ndA0KY2xhcmlmeSB0aGUgY29sdW1uIGZvciB5b3Uu DQoNCk5pdHM6DQoNClNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb246DQoNCiAgIFVzZSBv ZiBQcmUtU2hhcmVkIEtleXMgb2YgbGltaXRlZCBlbnRyb3B5IG1heSBhbGxvdyBhbiBhY3RpdmUN CiAgIGF0dGFja2VyIGF0dGVtcHRzIHRvIGNvbm5lY3QgdG8gdGhlIHNlcnZlciBhbmQgdHJpZXMg ZGlmZmVyZW50IGtleXMuDQpzL3RyaWVzL3RyeS8NCg0KICAgT3RoZXINCiAgIGV4YW1wbGUgaW5j bHVkZXMgdGhlIHVzZSBvZiBhIFBTSyBjaG9zZW4gYnkgYSBodW1hbiBhbmQgdGh1cyBtYXkgYmUN CiAgIGV4cG9zZWQgdG8gZGljdGlvbmFyeSBhdHRhY2tzLg0Kcy9PdGhlci9Bbm90aGVyLw0KDQoN Ci0tDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8 bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQoNCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD82E2eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPk9vcHMsIEkgbWlzc2VkIHlvdXIgZW1haWwuIHRoZSB2ZXJzaW9uIDAzIGhhcyBi ZWVuIHN1Ym1pdHRlZC4gRm9yIHNvbWUgcmVhc29uIG15IGVtYWlsIGFkZHJlc3MgaXMgbm90IGlu IHRoZSBkYXRhYmFzZSwgc28gaXQgaGFzIHRvIGJlIGNvbmZpcm1lZCBieSBzb21lb25lIGVsc2Ug b3IgdGhlIHNlY3JldGFyaWF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Zb3VycywNCjxicj4NCkRhbmllbCAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFp bHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIE1heSAwMiwgMjAxNyA3OjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBEYW5pZWwgTWln YXVsdCAmbHQ7ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g Jmx0O3Rsc0BpZXRmLm9yZyZndDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtUTFNdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVh ZC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBEYW5pZWwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rIHlvdSwgcGxlYXNlIHB1Ymxpc2ggdmVyc2lvbiAzIGFuZCBJJ2xsIGtpY2sgb2ZmIGxh c3QgY2FsbC4gJm5ic3A7WW91IGNvdWxkIHVwZGF0ZSB0aGUgVExTIHZlcnNpb24gdG8gMjAgYXMg d2VsbCwgYnV0IHRoYXQncyBzb21ldGhpbmcgdGhhdCB3aWxsIGdldCBmaXhlZCB3aXRoIHRoZSBS RkMgbnVtYmVyIHdoaWxlIGluIHRoZSBSRkMgZWRpdG9yIHF1ZXVlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5LYXRobGVlbiZuYnNwOzxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDEsIDIwMTcsIGF0IDk6NDYgUE0sIERhbmll bCBNaWdhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29t Ij5kYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIEthdGhs ZWVuLCA8YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIEkgaGF2ZSBwcm9jZWVk ZWQgdG8gdGhlIHVwZGF0ZSBvZiBteSBsb2NhbCBjb3B5LiBUaGUgdGV4dCBpczo8YnI+DQo8YnI+ DQomcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQpUaGUgY2lwaGVyIHN1aXRlIG51bWJlcnMgbGlzdGVk IGluIHRoZSBsYXN0IGNvbHVtbiBhcmUgbnVtYmVycyB1c2VkPGJyPg0KZm9yIGNpcGhlciBzdWl0 ZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgYW5kIGl0J3Mgc3VnZ2VzdGVkIHRoYXQgSUFOQTxi cj4NCnVzZSB0aGVzZSB2YWx1ZXMgZm9yIGFzc2lnbm1lbnQuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1 b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+T3RoZXIgbml0cyBoYXZlIGJlZW4gYWRkcmVzc2VkIGFzIHdl bGwuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JZiB0aGF0IGlzIGZpbmUsIEkgY2FuIHB1Ymxpc2ggdGhl IHZlcnNpb24gMDMuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WW91cnMsIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E YW5pZWw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkgMSwgMjAxNyBhdCAyOjIzIFBN LCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5 LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIgd29yayBv biB0aGUgZHJhZnQgZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQtMDIuPGJyPg0KPGJyPg0K SW4gdGhlIElBTkEgc2VjdGlvbiwgSSB0aGluayBpdCB3b3VsZCBiZSBhIGJpdCBtb3JlIGNsZWFy IHRvIHNheSBpbjxicj4NCnRoZSBsYXN0IGNvbHVtbiByYXRoZXIgdGhhbiBzZWNvbmQgY29sdW1u IHdpbmNlIG9uZSBtaWdodCBpbnRlcnByZXQ8YnI+DQp0aGlzIGxpc3RpbmcgYXMgaGF2aW5nIDMg Y29sdW1ucy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIGNpcGhlciBzdWl0ZSBudW1iZXJz IGxpc3RlZCBpbiB0aGUgc2Vjb25kIGNvbHVtbiBhcmUgbnVtYmVycyB1c2VkPGJyPg0KJm5ic3A7 ICZuYnNwO2ZvciBjaXBoZXIgc3VpdGUgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIGFuZCBpdCdz IHN1Z2dlc3RlZCB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwO0lBTkEgdXNlIHRoZXNlIHZhbHVlcyBm b3IgYXNzaWdubWVudC48YnI+DQo8YnI+DQpUaGUgcmVnaXN0cnkgaGFzIHRoaXMgcmV2ZXJzZWQg d2l0aCB0aGUgZGVzY3JpcHRpb24gYXMgdGhlIHNlY29uZDxicj4NCmNvbHVtbiwgd2hpY2ggaXMg ZmluZS4mbmJzcDsgSSdtIGp1c3QgcG9pbnRpbmcgdGhhdCBvdXQgYXMgaXQgZG9lc24ndDxicj4N CmNsYXJpZnkgdGhlIGNvbHVtbiBmb3IgeW91Ljxicj4NCjxicj4NCk5pdHM6PGJyPg0KPGJyPg0K U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbjo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 VXNlIG9mIFByZS1TaGFyZWQgS2V5cyBvZiBsaW1pdGVkIGVudHJvcHkgbWF5IGFsbG93IGFuIGFj dGl2ZTxicj4NCiZuYnNwOyAmbmJzcDthdHRhY2tlciBhdHRlbXB0cyB0byBjb25uZWN0IHRvIHRo ZSBzZXJ2ZXIgYW5kIHRyaWVzIGRpZmZlcmVudCBrZXlzLjxicj4NCnMvdHJpZXMvdHJ5Lzxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtPdGhlcjxicj4NCiZuYnNwOyAmbmJzcDtleGFtcGxlIGluY2x1 ZGVzIHRoZSB1c2Ugb2YgYSBQU0sgY2hvc2VuIGJ5IGEgaHVtYW4gYW5kIHRodXMgbWF5IGJlPGJy Pg0KJm5ic3A7ICZuYnNwO2V4cG9zZWQgdG8gZGljdGlvbmFyeSBhdHRhY2tzLjxicj4NCnMvT3Ro ZXIvQW5vdGhlci88YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0K PHNwYW4gY2xhc3M9ImhvZW56YiI+LS08L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9Imhv ZW56YiI+QmVzdCByZWdhcmRzLDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5LYXRo bGVlbjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFz cz0iaG9lbnpiIj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2Vu emIiPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BD82E2eusaamb107erics_-- From nobody Thu May 4 05:41:34 2017 Return-Path: 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 B6EEC120727 for ; Thu, 4 May 2017 05:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 6u7MS4fLFZ6C for ; Thu, 4 May 2017 05:41:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B165E126BF6 for ; Thu, 4 May 2017 05:41:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5062DBDD4 for ; Thu, 4 May 2017 12:41:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5062DBDD4 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5062DBDD4 Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1613C7E2C0 for ; Thu, 4 May 2017 12:41:29 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Thu, 04 May 2017 14:41:22 +0200 Message-ID: <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6763987.6lAOXSEbUL"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 04 May 2017 12:41:29 +0000 (UTC) Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 12:41:32 -0000 --nextPart6763987.6lAOXSEbUL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote: > All, >=20 > draft-ietf-tls-rfc4492bis has been revised since it left the WG and we ag= ree > with Yoav=E2=80=99s statement at the mic in Chicago that the WG should re= view the > changes before we ask Kathleen (our newly appointed AD) to continue > progressing the draft. Please review the differences from the -12 version > that went through WGLC and the latest version [0] and let us know by > 20170426 whether there is anything that would stop progression of the > draft. I know I am late with the review, but I'd like to ask two questions: 1. In table 2, the "key authorised for use in digital signatures" was=20 removed. Does that mean that key usage extension in X.509 certificates should be= =20 ignored? 2. Given that RFC7919 is already accepted, standards track document,=20 shouldn't "NamedCurve" references be renamed to "NamedGroup" (e.g. in=20 Section 5.5.1.) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart6763987.6lAOXSEbUL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZCyFyAAoJEJKo0bgB0vX18XMP/0Hhy+rRxjHSf6Sj3YJOneT4 Yqmnj01Z6e/O+qyQgKBc2eCagFi22wp2Pv8SnKZsOeRwOyAGnt1D3AqKBwSQi2e2 OheNvb8JlsKezuJ2NuQFrmLYlwwVBhME73CdnbbBNAnFK+kcv5luK+KnGawo8UXx nIWBQ8uBmH8rMVjfPXJd3O9peaSmaLeV9jDPtAs8QZx47RyxSmHcAkP20iYtOC9J Fgs7wOw8XW8emD3kSzZjVFWbC3M3AMfIpuqy3tcYSSx40Cgj6+bHECo9UNbTe/5k 4fFEMT2kGTWYFpDps9GSbISHPCa7ACwqPZSmCcBSzx39VnTXdV5IvJINUWDjtdOH PAxEq3ZQWtc8WMmt0NlCioDHgg5QzC4mw760GQdr++vhAUDgshaXgj+F2JbzS53k 5EKm/3syD4typ/FVlrdCdzFk18mI1XFbw/ttgcivu2lD5lAlK4O4mVJBfTTAj15I HZinVz2q9zwFX39MWl+VhBbsUQRnmDFBN66NRvkzv0iHnmbyHypK3tfcN5Hobzkx sk37zPFfZ4qi8tnXAzX7Ce81io04GPg9wePg6rbePsg9TZdQOW6JySUWK6W+g6x2 4HoKi4qIdZp41YXuFPdElpmZfB+C4EQ5epOpizwiCFR4hjpnz4SUj4ElAKH3REYY 9rEfpijqBE5941qwgg6A =5M/x -----END PGP SIGNATURE----- --nextPart6763987.6lAOXSEbUL-- From nobody Thu May 4 06:09:16 2017 Return-Path: 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 4711C12762F for ; Thu, 4 May 2017 06:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hw1eT5TnLlgz for ; Thu, 4 May 2017 06:09:13 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD2112711E for ; Thu, 4 May 2017 06:09:11 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id m36so9419955qtb.0 for ; Thu, 04 May 2017 06:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QjvsJam5eznxkA9bSB8wN4kQa6DAi+FFkipANMx3HGc=; b=c/S88EHQTX0hdRr3gqmpj7DqMxd+Rs7CvSyTUpPx2Hm9UIe1AzDb96ChBdX5nB3KYU gDeCievOSi4Ih77BOa1L3voxScQu0klsOKPi0iLXqBeeFHthLCKM7Lz2Lr7GeNlYX/K4 RZDEi7/JjQstfqBWTO6ZzJajYdrhieBEM/yLkf0ktU+7fBRwapsmTvtv76vrEKiv6vVm nRMGS05E9aQdAL9tIKCvtmVr+NO0Yyy9xKcwSKFNB/RnbmTMFhOJan1qC2lfEzmoFt2L U63WMaQSw8RcqIDr/VnEKokF0+rF8y+B0WWxasR8bb0dZQvf7wPDxOXl7tpHhVU5liKD EFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QjvsJam5eznxkA9bSB8wN4kQa6DAi+FFkipANMx3HGc=; b=aglxvjrTBH3les3Gy2BXcFNF51zLCkifNafkg5TxrbP0LaXRq4I3dIBUTWStbbUo/G rzyl8ajqmasiuq+hLfWK1ppLj4IaA0qGgzGI1Rn+qVX3kZxqP5Gz4CXqIZrRw9WkJ6cj WrNJdC3fHXFLKZWBu3WeZD9stXbDsHYJWI9x/MbWoMqUpB7PDCDt1qwzFxsUNnsLqrZY 2Gt8TsldvuhG4ylEgvM9RSEkSh/nfL9A1CAfwZEZ7ZHLbg5/7uZ2GofezYsOu14oJf2u aIw1KPzmZbH6YBqhQe6mC/wuikf2M9YHPiFFtCUy3Ge3HFj/8QFOOTpzn0prnpJZjD3V oLdw== X-Gm-Message-State: AN3rC/601rG2Oh2GoaM0bBKiAFAAUrrt4Esy57vyWKWQ8Ia8l5noyPDw TK/wJjDR8xDrOw== X-Received: by 10.200.53.54 with SMTP id y51mr40820515qtb.45.1493903350541; Thu, 04 May 2017 06:09:10 -0700 (PDT) Received: from [192.168.1.13] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id c64sm1403923qka.63.2017.05.04.06.09.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 06:09:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14D27) In-Reply-To: <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> Date: Thu, 4 May 2017 09:09:09 -0400 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> References: <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> To: Hubert Kario Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:09:15 -0000 I haven't approved it yet as I noticed there was no response (that I saw) to= Alexey's comment and no change in the draft as a result of his comments. I'll wait in responses for these 2 items. Thank you, Kathleen=20 Sent from my iPhone > On May 4, 2017, at 8:41 AM, Hubert Kario wrote: >=20 >> On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote: >> All, >>=20 >> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we ag= ree >> with Yoav=E2=80=99s statement at the mic in Chicago that the WG should re= view the >> changes before we ask Kathleen (our newly appointed AD) to continue >> progressing the draft. Please review the differences from the -12 versio= n >> that went through WGLC and the latest version [0] and let us know by >> 20170426 whether there is anything that would stop progression of the >> draft. >=20 > I know I am late with the review, but I'd like to ask two questions: >=20 > 1. In table 2, the "key authorised for use in digital signatures" was=20 > removed. > Does that mean that key usage extension in X.509 certificates should be= =20 > ignored? > 2. Given that RFC7919 is already accepted, standards track document,=20 > shouldn't "NamedCurve" references be renamed to "NamedGroup" (e.g. in=20= > Section 5.5.1.) >=20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 4 06:26:16 2017 Return-Path: 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 66E9D129406 for ; Thu, 4 May 2017 06:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=gsmasso.onmicrosoft.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 SVUb55OgTqNS for ; Thu, 4 May 2017 06:26:13 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10050.outbound.protection.outlook.com [40.107.1.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EBC128B4E for ; Thu, 4 May 2017 06:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gSFFg3Iibkp2HeeFXPitT21gVGB6cjTpj7OE7Mn2UUA=; b=sTvU8lRlVsi5frSTWUPDPvrH6yGyTSVzFt/UBp2LA6Ljy0ZPDUD8ylxht1avj53EvT84haQmrr39Lbjgfl6ydviUtbdUPe3d+Yfz0ZK/fcKfUVdir4Uy/MCFTLWBPXI1x1wKrw2dHFyXdcLbe5ONIXqpBru7DWKH9vhr3QgcdEM= Received: from AM2PR04MB0802.eurprd04.prod.outlook.com (10.160.56.28) by AM3PR04MB1362.eurprd04.prod.outlook.com (10.163.185.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 13:26:02 +0000 Received: from AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::c094:3686:6937:5c6a]) by AM2PR04MB0802.eurprd04.prod.outlook.com ([fe80::c094:3686:6937:5c6a%15]) with mapi id 15.01.1075.010; Thu, 4 May 2017 13:26:02 +0000 From: Natasha Rooney To: "tls@ietf.org" Thread-Topic: trusted_ca_keys Thread-Index: AQHSwDDGEZlexoCE1UeM9rJfM1WBYQ== Date: Thu, 4 May 2017 13:26:02 +0000 Message-ID: References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-originating-ip: [62.189.0.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR04MB1362; 7:Bm4/A9cdSuCgzInY/P3YTv77KlyNA2xmJj3+ZRUQmDPPMKOqAS/DX56x39YshI8dv6wpkgrbbpZhY/9QVBwSW1le/VjUn2U238+oAyzULbhv4CJFbt3zT/WAllKRya96ghAKbws88pfnopYtthTW8VKEff4Z49vWS5xGoicryRxrzWfdG68B73LNK+i8iXqjFUAywWzLQ5asaqOACoY/kOUTxYjsQP5UeermaGVkib6Wv07gOO3McDWanCLhj4VJdxrjYr89dCqoavEpVsmtzoVc/S6ZJlEoT+ztqwAkIlrTugnC6RKbEIDC//5/9aZAp/usO1o2gQAWJ4B9hSs+MA== x-ms-office365-filtering-correlation-id: 54f95a52-4a78-43e5-6571-08d492f11c5b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR04MB1362; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR04MB1362; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB1362; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39850400002)(39840400002)(53754006)(3846002)(33656002)(6116002)(102836003)(50226002)(8936002)(53936002)(305945005)(99286003)(82746002)(5660300001)(1730700003)(7116003)(81166006)(5640700003)(8676002)(38730400002)(2501003)(110136004)(3280700002)(83716003)(5890100001)(6512007)(478600001)(86362001)(2906002)(5250100002)(36756003)(6436002)(76176999)(66066001)(50986999)(6486002)(25786009)(2351001)(6916009)(3660700001)(6506006)(189998001)(7736002)(2900100001)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR04MB1362; H:AM2PR04MB0802.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 13:26:02.3975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR04MB1362 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM2PR04MB0802.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-TransportTrafficSubType: X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: "Ajay S. Rambocus" X-MS-Exchange-CrossPremises-originalclientipaddress: 62.189.0.100 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: AM3PR04MB1362.eurprd04.prod.outlook.com Archived-At: Subject: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:26:15 -0000 SGkgYWxsIQ0KDQpBcG9sb2dpZXMgZm9yIHRoZSBvZGQgYW5kIHBvdGVudGlhbGx5IHNpbGx5IHF1 ZXN0aW9uLiBHU01BIGFyZSB3b3JraW5nIG9uIGZ1dHVyZSBTSU0gc3BlY2lmaWNhdGlvbnMgd2hp Y2ggdXNlIFRMUyBhbmQgcHJldmlvdXNseSBpbmNsdWRlZCB0aGUgdHJ1c3RlZF9jYV9rZXlzIHRv IGFsbG93IGEgY2xpZW50IHRvIGluZm9ybSBhIHNlcnZlciB3aGljaCBwYXJ0aWN1bGFyIGtleShz KSBmcm9tIGEgQ0EgaXQgaXMgc3VwcG9ydGluZy4gSW4gVExTIDEuMyB0aGUg4oCYdHJ1c3RlZF9j YV9rZXlz4oCZIGV4dGVuc2lvbiBpcyBubyBsb25nZXIgdXNlZC4gSXQgZG9lcyBoYXZlIHRoZSDi gJxjZXJ0aWZpY2F0ZV9hdXRob3JpdHnigJ0gZXh0ZW5zaW9uIGhvd2V2ZXIsIGJ1dCBpdCBzZWVt cyB0byBvbmx5IGlkZW50aWZ5IHRoZSBDQSBvcmdhbmlzYXRpb24gYnkgaXRzIERpc3Rpbmd1aXNo ZWROYW1lLiBJZiB0aGUgQ0Egc3VwcG9ydHMgbXVsdGlwbGUga2V5cyDigJMgaG93IGNhbiBhIGNs aWVudCBwb2ludCBhIHBhcnRpY3VsYXIgY2VydC9rZXkgb2YgdGhhdCBDQT8qDQoNClRoYW5rcyBh bmQgc29ycnkgZm9yIHBvc3RpbmcgdG8gdGhlIGdyb3VwIQ0KDQpOYXRhc2hhDQoNClRoaXMgZW1h aWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBv bmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4g ZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91 IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwg b3IgY2FsbCArNDQgMjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K From nobody Thu May 4 06:43:34 2017 Return-Path: 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 B3D651294F5 for ; Thu, 4 May 2017 06:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 e9xtrA5xHeCJ for ; Thu, 4 May 2017 06:43:30 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AA1A51294A3 for ; Thu, 4 May 2017 06:43:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B4BE621344; Thu, 4 May 2017 16:43:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id wU0zOE_-fkLq; Thu, 4 May 2017 16:43:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7C475C4; Thu, 4 May 2017 16:43:29 +0300 (EEST) Date: Thu, 4 May 2017 16:43:28 +0300 From: Ilari Liusvaara To: Natasha Rooney Cc: "tls@ietf.org" Message-ID: <20170504134328.GA32403@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:43:33 -0000 On Thu, May 04, 2017 at 01:26:02PM +0000, Natasha Rooney wrote: > > GSMA are working on future SIM specifications which use TLS and > previously included the trusted_ca_keys to allow a client to > inform a server which particular key(s) from a CA it is > supporting. In TLS 1.3 the ‘trusted_ca_keys’ extension is no > longer used. It does have the “certificate_authority†extension > however, but it seems to only identify the CA organisation by its > DistinguishedName. If the CA supports multiple keys – how can a > client point a particular cert/key of that CA?* The certificate should have its own DN, use that. This doesn't fully solve designating by key, as multiple issuing CAs can share a key. -Ilari From nobody Thu May 4 06:45:31 2017 Return-Path: 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 AA71E12954D for ; Thu, 4 May 2017 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 AlW3tFipQPXW for ; Thu, 4 May 2017 06:45:28 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8AE1294F5 for ; Thu, 4 May 2017 06:45:28 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v44Dfwen004416; Thu, 4 May 2017 14:45:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=uV1a8RAH1VJeXdWBbuGvZc86GdiPx+/6SKg0SbCeack=; b=CcqomGnHfoW//DLHi+lIOm1DJgBNN5aEZU+/8Rt5oSOXEHcwiHAoqZFBlhEtiA9QjMbc Rw6JnYK3gclT6JQPmxtb70dcFCjkR4HDtVBRFkH4Dy19B5hqoCLWVClEmYzMFHgOwFvF Tt9wHjVCJBY+lh/jfra7O4LULLla3burj0WEUNj8/hUWofZlo5/6EG9cMsRovI54nqd3 eNuVLN5ZW/hl7DJ/SXcUYHQMX3EHjegzN7+etSru0OvG5lJY+jPaeCRf0xvCF5gvOvgz CXpjLBmRrq8AB9Yks5ugPW7Mycs2NXHnYfo5GpORlEC6S6/6ImzMqizPc/ZSjvQzu6Pa Mg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2a7v2s2n6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 14:45:22 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v44DfVEN005515; Thu, 4 May 2017 09:45:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a72m93c2s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 09:45:21 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 08:45:20 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Thu, 4 May 2017 08:45:20 -0500 From: "Salz, Rich" To: Ilari Liusvaara , Natasha Rooney CC: "tls@ietf.org" Thread-Topic: [TLS] trusted_ca_keys Thread-Index: AQHSwDDGEZlexoCE1UeM9rJfM1WBYaHkjEIA//+sgoA= Date: Thu, 4 May 2017 13:45:20 +0000 Message-ID: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <20170504134328.GA32403@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170504134328.GA32403@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040217 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040217 Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:45:29 -0000 PiBUaGUgY2VydGlmaWNhdGUgc2hvdWxkIGhhdmUgaXRzIG93biBETiwgdXNlIHRoYXQuDQoNClNo ZSdzIHNheWluZyB0aGF0IGl0ICpkb2Vzbid0LioNCg0KU3ViamVjdEROIGlzIG5vdCB1bmlxdWUu ICBJc3N1ZXJETi9TZXJpYWwgaXMgdW5pcXVlLCBidXQgdGhpcyBleHRlbnNpb24gdXNlIHRoYXQu DQo= From nobody Thu May 4 07:20:50 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 250EA129B09; Thu, 4 May 2017 07:20:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149390764711.4760.11317435926109130055@ietfa.amsl.com> Date: Thu, 04 May 2017 07:20:47 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2017 14:20:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Authors : John Mattsson Daniel Migault Filename : draft-ietf-tls-ecdhe-psk-aead-03.txt Pages : 7 Date : 2017-05-04 Abstract: This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 4 07:50:55 2017 Return-Path: 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 42C3C129B66 for ; Thu, 4 May 2017 07:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 OTqvHrdXKDy9 for ; Thu, 4 May 2017 07:50:51 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619E9129B26 for ; Thu, 4 May 2017 07:50:50 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wJdHr2Kzxz26RW; Thu, 4 May 2017 16:50:48 +0200 (CEST) X-purgate-ID: 152705::1493909448-00003836-71BDAEA0/0/0 X-purgate-size: 1271 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wJdHq5pC9zGp3K; Thu, 4 May 2017 16:50:47 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BC07B1A69D; Thu, 4 May 2017 16:50:47 +0200 (CEST) In-Reply-To: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Date: Thu, 4 May 2017 16:50:47 +0200 (CEST) CC: Ilari Liusvaara , Natasha Rooney , "tls@ietf.org" Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:50:53 -0000 Salz, Rich wrote: > >> The certificate should have its own DN, use that. > > She's saying that it *doesn't.* > > SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use that. SubjectDN of a *Certificate Authority* **MUST** be unique. There is some wording in PKIX and X.509 which creates the impression that a CA could be re-using the same Subject DName with different keys, but such an interpretation is a formally provable defect of the PKIX specification. Creating a certificate chain *MUST* be possible on the issuer name-> subject name chaining alone. Support for chaining by subjectKeyId is truely *OPTIONAL* based on the requirements in the specification, so reuse of the same DName with a different key would break certificate chaining (and verification) that is performed on the issuer->subject chain alone and is therefore prohibited. Support for the SubjectKeyIdentifier and AuthorityKeyIdentifier X.509v3 extensions is explicitly just *RECOMMENDED* and can therefore be absent from a perfectly PKIX-conforming minimum requirements RP. PKIX-conforming CA MUST NOT break minimum-requirements RPs, e.g. by creating/issuing CA certificates with identical subject names but different public keys. -Martin From nobody Thu May 4 07:53:27 2017 Return-Path: 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 02953128616 for ; Thu, 4 May 2017 07:53:26 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 qWP7y2_z0VvE for ; Thu, 4 May 2017 07:53:24 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF911205D3 for ; Thu, 4 May 2017 07:53:21 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id q1so12839998qkd.2 for ; Thu, 04 May 2017 07:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xh9XHqkoi4ZtzqbGSeG0FmiEjsCmkyO/y0j2A+YugSs=; b=Heiry1BFZgsEj6TnyksiuBzxveGNF/iv1+f3K/4RuduIAMqZuAsKO9adKdx/VO4dUd 6wPvtQUiGw1o2gB/q8ZfnOZ6OGoNVelfZueGEaxKDfM2BqIWfTV6EW4NIWsOiVsjNB71 uLdJDZHxSorhjcug8vTtdRBtnOv1XjWwaM5OE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xh9XHqkoi4ZtzqbGSeG0FmiEjsCmkyO/y0j2A+YugSs=; b=tX1YxObKjLzryiwFSAQ2l9EnDNKfkE49tCpvcPLfVz/RSu3dpLwV570fpPrv+Zt1uR 9JJjHRGx7J4xQsUpqrUpZyHpqvk9t7kigoPAi5mgxh+Ng7qOr1vf1pI8sAp5IoAuwVfb sr6TjUK3NdjMU1CiJ99WTqmBEBzPpAHaYb8GOGn39pNO/pstO3CAhYeBiR62vQNmJ8pZ oTHU/FR4nGZq+5a7a+bxRJ4ZgMXvLetXzvDp5yUCI/b+7HOUMTKIRuoPYUQNQ5/6Yoy0 aG1ETnGbRsB1s/fUbusFpwU5e/ay1PvpriXNzn5mz5OB9ndFkWU/tYMMc3NPyhM5xIOT cUcg== X-Gm-Message-State: AODbwcCWH8EetcgL2MmJY8qFVPMDUpK74fqkcSkGnh48ATxPA9HhAHf2 DmnUJtvNuaafjw== X-Received: by 10.55.188.70 with SMTP id m67mr8293542qkf.128.1493909600592; Thu, 04 May 2017 07:53:20 -0700 (PDT) Received: from [172.16.0.18] ([96.231.219.90]) by smtp.gmail.com with ESMTPSA id 36sm1612582qtz.16.2017.05.04.07.53.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 07:53:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> Date: Thu, 4 May 2017 10:53:18 -0400 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <54C90C99-A5F5-4710-9727-E2E628A30BC3@sn3rd.com> References: <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:53:26 -0000 > On May 4, 2017, at 08:41, Hubert Kario wrote: >=20 > On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote: >> All, >>=20 >> draft-ietf-tls-rfc4492bis has been revised since it left the WG and = we agree >> with Yoav=E2=80=99s statement at the mic in Chicago that the WG = should review the >> changes before we ask Kathleen (our newly appointed AD) to continue >> progressing the draft. Please review the differences from the -12 = version >> that went through WGLC and the latest version [0] and let us know by >> 20170426 whether there is anything that would stop progression of the >> draft. >=20 > I know I am late with the review, but I'd like to ask two questions: >=20 > 1. In table 2, the "key authorised for use in digital signatures" was=20= > removed. > Does that mean that key usage extension in X.509 certificates = should be=20 > ignored? No it does not. There were changes to the table, but s2.2 is still there = and that=E2=80=99s where it says =E2=80=9C=E2=80=A6 MUST contain an RSA = public key authorized for signing ..." > 2. Given that RFC7919 is already accepted, standards track document,=20= > shouldn't "NamedCurve" references be renamed to "NamedGroup" (e.g. = in=20 > Section 5.5.1.) It=E2=80=99s either a replace or note the name change (i.e., in my mind = this is a style thing). The 1st paragraph of s5.1.1 notes them; RFC 4492 defined 25 different curves in the NamedCurve registry (now renamed the "Supported Groups" registry, although the enumeration below is still named NamedCurve) for use in TLS. spt= From nobody Thu May 4 07:58:21 2017 Return-Path: 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 5E6A01274D0 for ; Thu, 4 May 2017 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 HI9HYXCM0RSt for ; Thu, 4 May 2017 07:58:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121EA126B71 for ; Thu, 4 May 2017 07:58:14 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v44Ev0Si022137; Thu, 4 May 2017 15:58:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=xc5SIF2xmlRMhn0Kf4CeChy2t7q4uuMaIBwwzhHHP2g=; b=adHMjH69uYl0o3AP6eEy6BM2un3mX5Lootch90aCo+O+AGqi/r/Nu1lc0Qn6AiIa4XON nmY5RMGH9MCIEV73tDDylZ3SBkVim2QebJCmnol9YOLAjmDYx+9NEMRhMZumOdu1HRk9 ugC4CV2mmDh4ElswVRaARFgruyfZteGYIkOa3hhF2iCsH541A/QxB6ZZDDblMIzeub/R eUoYCG3iQ3YZfB7J5zTH9Lpz9PBM7AV0YyW5hYezhnqLaHhxJuPnuiEpBSD+s6ptDVSI +WwYmMkgAZeEErKumXbRw3u452HNAPAxrSiiL6FkWdam4GCVQeZY6/cfw+DcjgJLOl4F Aw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2a7v2s337d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 15:58:09 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v44Eu2xI003747; Thu, 4 May 2017 10:58:08 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a72mb50cj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 10:58:08 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 07:58:07 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Thu, 4 May 2017 09:58:07 -0500 From: "Salz, Rich" To: "mrex@sap.com" CC: Ilari Liusvaara , Natasha Rooney , "tls@ietf.org" Thread-Topic: [TLS] trusted_ca_keys Thread-Index: AQHSwDDGEZlexoCE1UeM9rJfM1WBYaHkjEIA//+sgoCAAGZMgP//rT/A Date: Thu, 4 May 2017 14:58:07 +0000 Message-ID: <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> In-Reply-To: <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040237 Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:58:20 -0000 > There is some wording in PKIX and X.509 which creates the impression that= a > CA could be re-using the same Subject DName with different keys, but such > an interpretation is a formally provable defect of the PKIX specification= . Any links you can point to? I don't see how CA1 issuing a sub-ca for "... CN=3Dfred" can globally preve= nt CA2 from issuing a sub-ca with the exact same DN. Can you explain what = I am missing? From nobody Thu May 4 08:16:41 2017 Return-Path: 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 B94BF12EAA5 for ; Thu, 4 May 2017 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 WVvw-fUHZXcf for ; Thu, 4 May 2017 08:16:37 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id C1BB1129BC6 for ; Thu, 4 May 2017 08:16:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C384E5FF81; Thu, 4 May 2017 18:16:34 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 1H95NlT7hiBH; Thu, 4 May 2017 18:16:34 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 880862313; Thu, 4 May 2017 18:16:34 +0300 (EEST) Date: Thu, 4 May 2017 18:16:33 +0300 From: Ilari Liusvaara To: "Salz, Rich" Cc: "mrex@sap.com" , Natasha Rooney , "tls@ietf.org" Message-ID: <20170504151633.GA32574@LK-Perkele-V2.elisa-laajakaista.fi> References: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:16:40 -0000 On Thu, May 04, 2017 at 02:58:07PM +0000, Salz, Rich wrote: > > There is some wording in PKIX and X.509 which creates the impression > > that a CA could be re-using the same Subject DName with different keys, > > but such an interpretation is a formally provable defect of the PKIX > > specification. > > Any links you can point to? > > I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally > prevent CA2 from issuing a sub-ca with the exact same DN. Can you > explain what I am missing? The organization info (O, L, ST, C, etc...) is supposed to differ in that case (CN is just one field of DN), rendering the full DNs distinct. -Ilari From nobody Thu May 4 08:19:42 2017 Return-Path: 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 AB0DD1200ED for ; Thu, 4 May 2017 08:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 JP1uL9jafzUy for ; Thu, 4 May 2017 08:19:38 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F46129B60 for ; Thu, 4 May 2017 08:19:36 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3wJdx26WQ8z1HhQ; Thu, 4 May 2017 17:19:34 +0200 (CEST) X-purgate-ID: 152705::1493911174-00003836-A5C95ED9/0/0 X-purgate-size: 1874 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wJdx24HKhzGqKK; Thu, 4 May 2017 17:19:34 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8DA691A69D; Thu, 4 May 2017 17:19:34 +0200 (CEST) In-Reply-To: <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Date: Thu, 4 May 2017 17:19:34 +0200 (CEST) CC: "mrex@sap.com" , Ilari Liusvaara , Natasha Rooney , "tls@ietf.org" Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170504151934.8DA691A69D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:19:41 -0000 Salz, Rich wrote: [ Charset windows-1252 unsupported, converting... ] > > There is some wording in PKIX and X.509 which creates the impression that a > > CA could be re-using the same Subject DName with different keys, but such > > an interpretation is a formally provable defect of the PKIX specification. > > Any links you can point to? > > I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally prevent CA2 from issuing a sub-ca with the exact same DN. Can you explain what I am missing? Such an action will create two mutually exclusive PKIs, PKIs that are *NOT* allowed to ever be bridged. Bridging them or would open security problem in the design of CRL processing rules for a collision of distinct subCA names, because those rules say that a signature on a CRL is valid, if the CRL signer cert can be verified under the same root as the CA. PKIX (rfc5280) about AuthorityKeyIdentifier X.509v3 extension: https://tools.ietf.org/html/rfc5280#section-4.2.1.1 The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. While it is a requirement for conforming CAs to place AuthorityKeyIdentifiers into issued certificates, using it for building or verifying certificate chains by RPs is purely optional "faciliate". If re-using the same CA DName for certs with different keys would be allowed, then chain building and chain verifying would become *DESPERATELY* dependent on support *AND* use of AuthorityKeyIdentifier->SubjectKeyIdentifier. -Martin PS: Coincidentally, this also implies that "self-issued" (rather than self-signed) certificates are a "myth". While they can be created technically, they are *ALWAYS* in violation of requirements of the specification(s). From nobody Thu May 4 08:25:24 2017 Return-Path: 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 D8742129B8D for ; Thu, 4 May 2017 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 UYF7rLFfPuMM for ; Thu, 4 May 2017 08:25:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5A01293D8 for ; Thu, 4 May 2017 08:25:13 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v44FMEj1023219; Thu, 4 May 2017 16:25:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=aRWpvZhcmCin7NrZ3iXv9+j+QNX9kfTXNOHX9Lv2ivM=; b=CKF3qskYvGXIWYRCDGecYsTsZOOocWKCp8hW6TQuFEwFcTy8/dWT2uN9+IxkpDeQUdW+ U6WVQAalVjIMV44OWFrq14p3KiZZFt6DvcBY307uwWi9jaZtzYAGQbPHiUCZSwEXi+1q afsGKA7wX2tnEJnuo0Yq6BW93hKqFkOZD24PAlLTAQlZ+Y6mXuCVd6MTd3Q2ca0ZLYrR hpiw+kbC6aPnI2Af2rPHcT9cD1IiTkQrSirYK/ki75/x6kqz19DJk5ThYCm7TGc827Ck UEFuHPxS5OcB5I2aGPhWkfUi2rvBgLiZqN7k1qrA4AJ2j9LpWEnx0HCheSvjn0VIm8iy FA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2a7v1skpvs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 16:25:06 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v44FKpqG023427; Thu, 4 May 2017 11:25:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a72m93k18-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 11:25:05 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 10:25:04 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Thu, 4 May 2017 10:25:04 -0500 From: "Salz, Rich" To: "ilariliusvaara@welho.com" CC: "mrex@sap.com" , Natasha Rooney , "tls@ietf.org" Thread-Topic: [TLS] trusted_ca_keys Thread-Index: AQHSwDDGEZlexoCE1UeM9rJfM1WBYaHkjEIA//+sgoCAAGZMgP//rT/AgABZ9ID//65jcA== Date: Thu, 4 May 2017 15:25:03 +0000 Message-ID: <73e04e3ff7de42659c8bae6b5e6f92c8@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504151633.GA32574@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170504151633.GA32574@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040239 Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:25:24 -0000 PiBUaGUgb3JnYW5pemF0aW9uIGluZm8gKE8sIEwsIFNULCBDLCBldGMuLi4pIGlzIHN1cHBvc2Vk IHRvIGRpZmZlciBpbiB0aGF0IGNhc2UgKENODQo+IGlzIGp1c3Qgb25lIGZpZWxkIG9mIEROKSwg cmVuZGVyaW5nIHRoZSBmdWxsIEROcyBkaXN0aW5jdC4NCg0KQnV0IHdoZXJlIGFuZCBob3cgaXMg dGhhdCBlbmZvcmNlZCwgb3IgZW5mb3JjZWFibGU/ICBBZ2FpbiwgYW55IGxpbmtzIHRvIHNob3cg SSdtIHdyb25nPw0K From nobody Thu May 4 08:27:06 2017 Return-Path: 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 7366212EA93 for ; Thu, 4 May 2017 08:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 ewjSBztD7PXS for ; Thu, 4 May 2017 08:27:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63515129AC4 for ; Thu, 4 May 2017 08:27:04 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v44FMEBq023208; Thu, 4 May 2017 16:27:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=A41LY6gUjvYh2Sr31RMi5BvBe2PX7SOye0hJwE0ZbFs=; b=d36llAL7dzcFi3mwUR+rg/AaOBD7Sj07jR0gEyKOlYnu513HwK28G1uY1kt80+sTNma8 k71Hlrt3lX5HcUWjQEhZ79Rr2HdBlo8JYR7sWVHYQwESo6FBGsY+dpxEnQ4HUICaFW3U bj4fM0voAFGMChXXZORWyx5EhCaf4+Fd9GUMIp9Hn5P2WQgPTvnFgNCsMJYwxLbpAm1T IwGXHmOUllsf/K5AA0jKqBTx6sL5cbIjWLJ1zOYMHHfcIETRx1IBLXGSNwZ6COiAu7Qq I6vnNaTSIswVvcvWg2nJW5puectlCNIAoSAwPHsefHBbDKGK9G0heUC4As5Va926a26U 9A== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2a7v1skq7w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 16:27:00 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v44FQ39W023621; Thu, 4 May 2017 11:26:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a72mb53ad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 11:26:59 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 10:26:59 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Thu, 4 May 2017 10:26:59 -0500 From: "Salz, Rich" To: "mrex@sap.com" CC: Ilari Liusvaara , Natasha Rooney , "tls@ietf.org" Thread-Topic: [TLS] trusted_ca_keys Thread-Index: AQHSwDDGEZlexoCE1UeM9rJfM1WBYaHkjEIA//+sgoCAAGZMgP//rT/AgABazAD//64PAA== Date: Thu, 4 May 2017 15:26:58 +0000 Message-ID: <0cdc6045867f4d429c5dae1dd01f909a@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504151934.8DA691A69D@ld9781.wdf.sap.corp> In-Reply-To: <20170504151934.8DA691A69D@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040239 Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:27:05 -0000 > If re-using the same CA DName for certs with different keys would be > allowed, then chain building and chain verifying would become > *DESPERATELY* dependent on support *AND* use of > AuthorityKeyIdentifier->SubjectKeyIdentifier. Or, it could use subject/issuer. Or it could try all the matching CA DName= certs it has. From nobody Thu May 4 08:31:22 2017 Return-Path: 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 AC72C129496 for ; Thu, 4 May 2017 08:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 cFwQrKA7flMb for ; Thu, 4 May 2017 08:31:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9227D12EAAD for ; Thu, 4 May 2017 08:31:12 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C4FCD7A32F1 for ; Thu, 4 May 2017 15:31:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 4 May 2017 11:31:10 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:31:21 -0000 > On May 4, 2017, at 10:58 AM, Salz, Rich wrote: >=20 > I don't see how CA1 issuing a sub-ca for "... CN=3Dfred" can globally = prevent CA2 from issuing a sub-ca with the exact same DN. Can you = explain what I am missing? You forgot that all the CA certificates are of course published in the = global X.500 directory. And it is of course not possible for two CAs to have the = same directory DN. [ DNs in the global directory are of necessity distinct. ] :-) Apologies for sending this as SMTP email over IP, with any luck it'll = still make it to your X.400 mailbox via a suitable IP<->X.25 connected gateway. --=20 Viktor. P.S. I've found one brave SMTP server out there whose TLS certificate = took a bold minimalist departure from PKIX. Note the null subject, issuer and = lack of subjectAltNames. This works just fine with DANE for SMTP, but could = give some peers a bit of indigestion. The server administrator demonstrates = a clear understanding of what's essential in a DANE 3 1 1 certificate for SMTP = (with perhaps a "let anyone who can't deal with it fix their system" = attitude): Certificate: Data: Version: 3 (0x2) Serial Number: c3:26:2b:13:ca:b1:36:72 Signature Algorithm: sha256WithRSAEncryption Issuer:=20 Validity Not Before: Jul 27 14:59:59 2014 GMT Not After : Nov 27 14:59:59 3013 GMT Subject:=20 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier:=20 = 98:C6:9B:D5:20:5C:1D:A8:31:39:BD:78:11:37:FF:BD:AD:5B:BD:59 X509v3 Authority Key Identifier:=20 = keyid:98:C6:9B:D5:20:5C:1D:A8:31:39:BD:78:11:37:FF:BD:AD:5B:BD:59 X509v3 Basic Constraints:=20 CA:TRUE Signature Algorithm: sha256WithRSAEncryption ... -----BEGIN CERTIFICATE----- MIIE1TCCAr2gAwIBAgIJAMMmKxPKsTZyMA0GCSqGSIb3DQEBCwUAMAAwIBcNMTQw NzI3MTQ1OTU5WhgPMzAxMzExMjcxNDU5NTlaMAAwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQC200I1aOkqnrr48PS/MLULQM0QSyCUqvzo07G4Fcwkun+V tYWS6dWXcNP9s8mRutWFXcZtmIvDs3l0p0HG9N8UU7uQIXJxuuJWAwoLqdvVktOQ WE7rpItRgNtfVibPmyaoLkLfVBSGTh+tspxXVBZ6OSWjs5CX63CSBCcQtv2ecE+y AuL6bZDrmgxkPDGGTJiZRwB1ttC7gAITx0OXJOwePrEc1se33vzou8bYIHQWCSct FxelpEHQ9mDeooT65I3dHph+GXWkh1IYRdltOT4ssmQaEzcmP3KMff4u1ibXzDeq Bkov6rwPAF/VMHnoESFkA7mR5dpHa31D5l4g6B0dHj24V2IBmBNbzKifa9I04G+G uKydifHpJ7n4Vc6iijMrrDplwPsSuPdaR6bqg4CID8rU1dxiXAjZz+bK/jIAnuPA U5kho8lPZgf8YeIgGAF/Yd3hcrX9w5cjKlG/QlhkDStOzIWgXgFSK3tG8GMZm6Ne LHAjNqOpOrNgLq14aJbOpEzqE3cCl8RVgvP9O/P0ZU7dO/7S3dDaKeg+3anjxhbb 6/iQctxUNxcVyUMf3p1bAl4DqT54dRVNvIS/oH5KaH0rxsW12gmL80VugiuLvuld t7Pw6A0EjOO4yiMd3BAJCS4evyNMZ75kwZD9YlcX1DPmHUxw11j2F17SS9UfmwID AQABo1AwTjAdBgNVHQ4EFgQUmMab1SBcHagxOb14ETf/va1bvVkwHwYDVR0jBBgw FoAUmMab1SBcHagxOb14ETf/va1bvVkwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B AQsFAAOCAgEAjUcd319j7Nt7o6OmUNB29RqG2iG/eE1Mq++vob7ppSkgawWjiIUO Vxec5oz1h8cHo3vtffQDB1putL+c220zJK5NDjkGVJ5xaPZdWOkZ/+/i5Xypudoh 3RQZ2MFrq679L4YUuY+/d3W4B8wKYooAmMT7Duzv9xGICgUO75vAmOA5R8CDr1r2 qj2PLF2xlbSToYa/HbFFkeV/b2OrWc8DTsA3/s6fLc1koYFiAHkyTbBDLlhux3n3 tnS+yWXGL9DpuFZg1EZI2G3asoFZqfSUjMSf9qsWb/EE5+kquwQfTcXC4AuwYNgc MVnaxjJsd4vb53eITRVFyeq4lVrT1l8Z7c1dhA0wdXCso5ptg/68YPq7K0jXEutK 40C/AVapDdT8SYhwawokNujC3epsZ89e0gp6MbiSk3z1jJGO6dk57B/ymAw91TMz U72xY7YY4yDGUCrxCVBdiGl2kTihwUdxCRJ1baAXcq3meEAY0wQEcDq/dEUMSHp7 /gr9/8uu94VQ+uIjc4dU6oB+yV/agD+vBDpY2EskdVigxZQKuI5iFX4+2kGoooAb xkMDriyM/MeD3zjfuBLSrMEQtGZ1d8ilb0kWxCcEwv5SpO9ihiUA584C501syGCD H0y62RuD2sxdv4k3BKeFYt5NLE7QE8TNgVFKsAdTlW9Cni4yEnscwcM=3D -----END CERTIFICATE----- From nobody Thu May 4 08:32:17 2017 Return-Path: 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 89C5112EAB2 for ; Thu, 4 May 2017 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 fcGLXDnXbmAb for ; Thu, 4 May 2017 08:31:58 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3C812EAAE for ; Thu, 4 May 2017 08:31:56 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3wJfCG6lrGz1J0V; Thu, 4 May 2017 17:31:54 +0200 (CEST) X-purgate-ID: 152705::1493911914-0000521C-ED8D7563/0/0 X-purgate-size: 577 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wJfCG4Vl1zGp8r; Thu, 4 May 2017 17:31:54 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 947AE1A69D; Thu, 4 May 2017 17:31:54 +0200 (CEST) In-Reply-To: <73e04e3ff7de42659c8bae6b5e6f92c8@ustx2ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Date: Thu, 4 May 2017 17:31:54 +0200 (CEST) CC: "ilariliusvaara@welho.com" , "mrex@sap.com" , Natasha Rooney , "tls@ietf.org" Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170504153154.947AE1A69D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:32:00 -0000 Salz, Rich wrote: [ Charset UTF-8 unsupported, converting... ] > > The organization info (O, L, ST, C, etc...) is supposed to differ in that case (CN > > is just one field of DN), rendering the full DNs distinct. > > But where and how is that enforced, or enforceable? Again, any links to show I'm wrong? In theory: using Directory Name SubjectNameConstraints to enforce a hierarchical Naming on all Subject Names and one single hierarchy of CAs. (Just that this doesn't work for dozens of independent PKIs environments like the SSLiverse...) -Martin From nobody Thu May 4 08:38:57 2017 Return-Path: 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 49C11127863 for ; Thu, 4 May 2017 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.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 EZBK1EA_8fNW for ; Thu, 4 May 2017 08:38:53 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CDA124D37 for ; Thu, 4 May 2017 08:38:52 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 2904EC17C9 for ; Thu, 4 May 2017 10:38:52 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 69285C15A8; Thu, 4 May 2017 10:38:51 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 327A1FE06F; Thu, 4 May 2017 11:38:51 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F35FBFE071; Thu, 4 May 2017 11:38:50 -0400 (EDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.21]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Thu, 4 May 2017 11:38:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xyI+2FPFZlhGju3PMxaGViRee60VA95OT82zvTajd84=; b=Oa8ZIEtFBPOnVFJLxDDJn7x3xV2T3qQ9bgfWekgMxtUT5aIz8pn1oCD5/1Ws4euPU0s2AMS78i6eDsU+pjcerySx9ahSze1QDyRdeHufc+P50SFU4yj46/wJ6qE4KSsJfhlYHIYpo54CCR7CD2K6dDcF95XX2Xk1C3cDsSGCqgI= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 4 May 2017 15:38:47 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1047.023; Thu, 4 May 2017 15:38:47 +0000 From: "Ackermann, Michael" To: "Salz, Rich" , "mrex@sap.com" CC: Natasha Rooney , "tls@ietf.org" Thread-Topic: [TLS] trusted_ca_keys Thread-Index: AQHSwDDGEZlexoCE1UeM9rJfM1WBYaHkOHAAgAAAhQCAABJKgIAAAgyAgAALQRA= Date: Thu, 4 May 2017 15:38:47 +0000 Message-ID: References: <6741eaa623234de19e859c453d5475cf@ustx2ex-dag1mb1.msg.corp.akamai.com> <20170504145047.BC07B1A69D@ld9781.wdf.sap.corp> <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <0e083a98c13f4caba8e0302735d5333f@ustx2ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=bcbsm.com; x-originating-ip: [167.242.122.83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 7:3HmwbhMMwwTuWQjpNBKhFB7gvQJnYsdqjUOtv5zgFL+Fa6LyNDh/YmNVOx2nhZgHP7JFM0hCa/0xjzZrZ9orOaN/CP2EO3fANNWXh8iDWwmYRvG4Do4iZRtWq9lzI0MciC70nffs6KrcRLY0emcueC1R5XiIauoOdMmW//CPOhiqBQxGWeYLsW00WOA8x0efq5JeiAC7mhOYKsCvfXXVTrM/JV9ACYN2HsR9Yh9W/0eR0NnhVyQQMLw+uqCOhn2s/En07pxYMW26xeHlPHRrRryUvZI0EBxVfqvkrJj9la94ugQct0jnxYKx0CayGPx94E0FBgs68M7OZspi2qqGfg==; 20:CrgkIgsBD5nKVLkhUf8zg4FESKOKqKN/VJEe8BbczBQlUlehT6bnLf/ogME+p2ZueK53HITxDdC3rM3JuLEDA3qHjH2xBoibj2rj7KD6AvA2U2JWeXjbt5ZpwCRIHTCNgvptPusb8ykWk0HOI4HiklcS+d2iKdOQyFOG6Z3qziQ= x-ms-office365-filtering-correlation-id: 1305f9d9-4422-473c-0947-08d49303a7dd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR14MB1365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(55761251573089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:; SRVR:CY4PR14MB1365; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39830400002)(39410400002)(377454003)(13464003)(229853002)(102836003)(3846002)(6116002)(305945005)(7736002)(4326008)(189998001)(2501003)(8936002)(33656002)(86362001)(8676002)(2950100002)(77096006)(7696004)(508600001)(38730400002)(74316002)(80792005)(81166006)(2906002)(6306002)(54906002)(9686003)(99286003)(3660700001)(2900100001)(3280700002)(66066001)(6436002)(53936002)(6506006)(8656002)(25786009)(50986999)(76176999)(53546009)(54356999)(55016002)(8666007)(122556002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 15:38:47.5177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 944392e4-464d-488c-aca2-fb8176a72f28 X-VPM-MSG-ID: 37abb110-b7e4-4116-90a6-87b09e12ea0d X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] trusted_ca_keys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:38:55 -0000 Feel better Jason=21 =20 -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Salz, Rich Sent: Thursday, May 4, 2017 10:58 AM To: mrex=40sap.com Cc: Natasha Rooney ; tls=40ietf.org Subject: Re: =5BTLS=5D trusted_ca_keys > There is some wording in PKIX and X.509 which creates the impression=20 > that a CA could be re-using the same Subject DName with different=20 > keys, but such an interpretation is a formally provable defect of the = PKIX specification. Any links you can point to? I don't see how CA1 issuing a sub-ca for =22... CN=3Dfred=22 can globally = prevent CA2 from issuing a sub-ca with the exact same DN. Can you explain = what I am missing? _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Thu May 4 09:41:07 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F67129AB2; Thu, 4 May 2017 09:41:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Joseph Salowey , tls@ietf.org, joe@salowey.net, tls-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> Date: Thu, 04 May 2017 09:41:05 -0700 Archived-At: Subject: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2017 16:41:06 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu May 4 10:07:45 2017 Return-Path: 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 696431286CA for ; Thu, 4 May 2017 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=microsoft.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 y6J644IjW7td for ; Thu, 4 May 2017 10:07:41 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0101.outbound.protection.outlook.com [104.47.38.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A5E129436 for ; Thu, 4 May 2017 10:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wZJKOBUctrk6pVbHt6cKvJthI/Z5/2gJOQcM/coj9vQ=; b=JRS8/XCSNUn59u5nFuNdPIppfa57YEVELlVQonJmHB90JPKKYGYZlMEfDYWE9kF8iQHstfyt8NDyoWqq3rWSuW4eJ9SfwdyUyGNYOojRHbgm3Cadvrkpkb+lNwr95sF5B5uc4RLx2qE9GkvLTHse0ogbPNIVQ08htvKuZqt8VqQ= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.4; Thu, 4 May 2017 17:07:38 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1084.001; Thu, 4 May 2017 17:07:38 +0000 From: Andrei Popov To: Ilari Liusvaara , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= CC: "tls@ietf.org" Thread-Topic: [TLS] Security review of TLS1.3 0-RTT Thread-Index: AQHSw1NLuoeRqJY1j061PhdwGwZhyaHj7JsAgAB3F+A= Date: Thu, 4 May 2017 17:07:37 +0000 Message-ID: References: <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:6::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0091; 7:wRbOVIka6NFAIpu0BmxNo3B6gpdC/mHoiIeGgE+L0bJkAbhOlCh93fHaZJQG5+L+Tg0Jy5yUKfRhTjqmGJo7iB5/80KJgdCMMs7nyYD8c9PMMBWKQevBt/8K17E/MYCU8JfSbhj0g2XOna2ismH+SX6wMFyCS+xLa619ydGHBNzSRPsj5cucBwXOsXVe0u8+jxKdpbWrNhYkBFywrZSMrOovEM1Y0NLnjFsmKJ+7tVVmsyR2xsOtKuHsE2z2pvz0Os1HSZMgNfQ2GWmoqGB/9GikqOdUV2/enn9K33aTCXYTZcNjeOEt3BAnFRTNscfpuoNRqHu0/bOIBKhzguU4lmPTtcoP70COe6lDcZf+0dI= x-ms-office365-filtering-correlation-id: f6b496d1-5d13-4c50-1eb2-08d493101109 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0091; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(192374486261705)(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:DM2PR21MB0091; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0091; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39400400002)(39850400002)(39410400002)(13464003)(24454002)(377454003)(77096006)(6506006)(6436002)(99286003)(7736002)(6306002)(55016002)(81166006)(8676002)(74316002)(229853002)(3280700002)(122556002)(8936002)(189998001)(305945005)(53936002)(9686003)(38730400002)(4326008)(3660700001)(2900100001)(53546009)(25786009)(15650500001)(33656002)(54356999)(76176999)(50986999)(86362001)(7696004)(86612001)(575784001)(5660300001)(478600001)(2906002)(10290500003)(2950100002)(102836003)(10090500001)(5005710100001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0091; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 17:07:37.8771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0091 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:07:43 -0000 SU1ITyB3aGF0IHdlIGhhdmUgaXMgYSBmYWNpbGl0eSBpbiBUTFMgMS4zIHRoYXQ6DQoxLiBSZXF1 aXJlcyBleHRyYW9yZGluYXJ5IGVmZm9ydCBvbiB0aGUgc2VydmVyIHNpZGUgdG8gbWl0aWdhdGUg cmVwbGF5IChmb3IgYWxsIGJ1dCB0aGUgc21hbGxlc3QgZGVwbG95bWVudHMpOw0KMi4gT2ZmZXJz IG5vIHdheSBmb3IgdGhlIGNsaWVudCB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgc2VydmVyIGlz IG1pdGlnYXRpbmcgcmVwbGF5IChiZWZvcmUgcmVwbGF5IGJlY29tZXMgcG9zc2libGUpOw0KMy4g SXMgdHJpdmlhbCB0byBlbmFibGUgb24gdGhlIGNsaWVudCBhbmQgaW1wcm92ZXMgY29ubmVjdGlv biBsYXRlbmN5Ow0KNC4gRWxpbWluYXRlcyBhIG5vbmNlIHRoYXQgb3RoZXIgcHJvdG9jb2xzICh1 c2VkIHRvKSByZWx5IG9uLg0KDQpXaGlsZSBpdCBpcyB0cnVlIHRoYXQgdGhlcmUgYXJlIGNhc2Vz IHdoZXJlIHRoaXMgZmFjaWxpdHkgaXMgYmVuZWZpY2lhbCwgdGhlcmUgaXMgbm8gZG91YnQgdGhh dCBpdCB3aWxsIGJlIHdpZGVseSBtaXN1c2VkLCBpbiBib3RoIGFwcGxpY2F0aW9ucyBhbmQgcHJv dG9jb2xzLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJ bGFyaSBMaXVzdmFhcmENClNlbnQ6IFRodXJzZGF5LCBNYXkgNCwgMjAxNyAyOjM1IEFNDQpUbzog Q29sbSBNYWNDw6FydGhhaWdoIDxjb2xtQGFsbGNvc3RzLm5ldD4NCkNjOiB0bHNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbVExTXSBTZWN1cml0eSByZXZpZXcgb2YgVExTMS4zIDAtUlRUDQoNCk9u IFR1ZSwgTWF5IDAyLCAyMDE3IGF0IDA3OjQ0OjM1QU0gLTA3MDAsIENvbG0gTWFjQ8OhcnRoYWln aCB3cm90ZToNCj4gT24gU3VuZGF5IGF0IHRoZSBUTFM6RElWIHdvcmtzaG9wIEkgcHJlc2VudGVk IGEgc3VtbWFyeSBvZiBmaW5kaW5ncyBvZiANCj4gYSBzZWN1cml0eSByZXZpZXcgd2UgZGlkIG9u IFRMUzEuMyAwLVJUVCwgYXMgcGFydCBvZiBpbXBsZW1lbnRpbmcgMS4zIGluIHMybi4NCj4gVGhh bmtzIHRvIGZlZWRiYWNrIGluIHRoZSByb29tIEkndmUgbm93IHRpZ2h0ZW5lZCB1cCB0aGUgZmlu ZGluZ3MgZnJvbSANCj4gdGhlIHJldmlldyBhbmQgcG9zdGVkIHRoZW0gYXMgYW4gaXNzdWUgb24g dGhlIGRyYWZ0IEdpdEh1YiByZXBvOg0KPiANCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodQ0KPiBiLmNvbSUyRnRs c3dnJTJGdGxzMTMtc3BlYyUyRmlzc3VlcyUyRjEwMDEmZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBv cG92DQo+ICU0MG1pY3Jvc29mdC5jb20lN0M1MWQ3NzM5ZDZmNDM0MTEwOGFjYjA4ZDQ5MmQwY2Q4 ZiU3QzcyZjk4OGJmODZmMTQxYWYNCj4gOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Mjk0 ODcyODgyMDY3ODY4JnNkYXRhPUhUUUw5YTNDeFVFQzBHa0FRJQ0KPiAyQnZpUk1NTzV0czJQbmlm UWpPYVolMkJMWlhSOCUzRCZyZXNlcnZlZD0wDQoNCldoYXQgSSBkaWRuJ3Qgc2VlIGluIHRoZSBz dW1tYXJ5LCBidXQgSSB0aGluayBtaWdodCBiZSByZWxldmFudCBpbiByZWxhdGlvbiB0byAwLVJU VDoNCg0KVGhlcmUgaXMgYSB0aGluZyBjYWxsZWQgMC1SVFQgZXhwb3J0ZXIsIHdoaWNoIGFyZSBl eHBvcnRlciB2YWx1ZXMgYXZhaWxhYmxlIGR1cmluZyAwLVJUVCB0cmFuc21pc3Npb24uDQoNCklm IHRoZSBzZXJ2ZXIgdXNlcyAwLVJUVCBleHBvcnRlciBhbmQgZG9lc24ndCBlbmZvcmNlIG5vbi1y ZXBsYXksIHRoZSB2YWx1ZSBncm9zc2x5IGZhaWxzIHRvIGJlICJub25jZSIsIHdoaWNoIG1lYW5z IGl0IGlzIGxpa2VseSB1bnNhZmUgdG8gdXNlIGZvciBhdXRoZW50aWNhdGlvbi4NCg0KVW5mb3J0 dW5hdGVseSwgdGhlcmUgYXJlIHByb3RvY29scyB0aGF0IGFyZSBhbHJlYWR5IGRpc2N1c3Npbmcg dGhlIHVzZSBvZiBUTFMgMS4zIDAtUlRUIGV4cG9ydGVyLCBhbmQgc3dpdGNoaW5nIHRvICJmdWxs IiBleHBvcnRlci4NClVuZm9ydHVuYXRlbHksIHRoZSBlYXNpZXN0IHdheSBpcyBub3QgdG8gc3dp dGNoLCB3aGljaCBtZWFucyB0aGUgcG9zc2libHkgd2VhayAwLVJUVCBleHBvcnRlciB3aWxsIGJl IHVzZWQgZm9yIGF1dGhlbnRpY2F0aW5nIGV2ZW4gbm9uLXJlcGxheWFibGUgZGF0YS4NCg0KDQoN Ci1JbGFyaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRnRscyZkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBt aWNyb3NvZnQuY29tJTdDNTFkNzczOWQ2ZjQzNDExMDhhY2IwOGQ0OTJkMGNkOGYlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Mjk0ODcyODgyMDY3ODY4JnNk YXRhPXNnbndtM3Y3amZqTGVXSFpWNzd6d3BjaGZ6Z3k4NUFTS2VLWVl4RVF4c3MlM0QmcmVzZXJ2 ZWQ9MA0K From nobody Thu May 4 10:59:45 2017 Return-Path: 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 750AB129AFF for ; Thu, 4 May 2017 10:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 U1BWKLW_Aem1 for ; Thu, 4 May 2017 10:59:40 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0673129B10 for ; Thu, 4 May 2017 10:59:34 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id y10so4994577wmh.0 for ; Thu, 04 May 2017 10:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l7VduV8yKNCf3M8Ukg6YyMR8KXTsbdkbdw3INilq/C0=; b=DVpuSlk8uRXCZ4j3G0gkkxukzfjwwV6TkR72sfmEoh1sTslNLUs9D+h66iIqFZvwun Tb3apGeMDnszGAkvsC1HAeqtR8mVHEtkvSwf2ZAs1+Zts52eIk6I3IAx/W7WoygcLMkC cfpOoqWaYQEgIkjuED8Oq9c1FBlGkJ0hGMfCnXVl5QauGODaXar9JaQi1Xf0HX58OX7t F2UG8sjixzA8tmR7WCV03sNM+nPwmPJdemnUJgaBWrpRorDWj+rhNziqcWPtHR0QFODU 9KZC8ZajKaf4veBmwTUuK9AHccW9K1HN6m4751eLLGnJMNidSObK2+T5fznIWdjnsXnD V3Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=l7VduV8yKNCf3M8Ukg6YyMR8KXTsbdkbdw3INilq/C0=; b=fpy3OSOwWZTbBjZTfvkqZ7yAaWnWPYHxAkjOZ0n1SOBvAIR/0NoBFf/5C/mZHPw/Ki dWjLW7+eP57IEgVfHDvey5wWw51rxXmPAPu+auwZsmB2bZRlbJj5m9DFwKfGCFtRvL59 qwpK77keDbnGSWWiKL/9r86zv9bPgmYw8pfBkRygARj1gV/ikk3v/BbPzZoQ5scZkk82 StEV5YXI+GX9iRN5I36mRcMyxXagrmp7Mp+AqBbQaHLaiXfR0BgacRLuqnmK5qtZvPt3 nsseMjRyOE+QC7oa0r+15cGc6GUezr/J60MBP/Vv48KU3Chx3t+jkh4w0+YL+nMSOIqh kgkg== X-Gm-Message-State: AN3rC/45X5sOgi/RlHJ9tQ84BGG0Pmlwf+Pqb4RK+D4LtQoJatuaCEPq QG/XBNUhE2UnxQ== X-Received: by 10.80.174.230 with SMTP id f35mr31035333edd.157.1493920773264; Thu, 04 May 2017 10:59:33 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s42sm781687edb.22.2017.05.04.10.59.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 10:59:32 -0700 (PDT) From: Yoav Nir Message-Id: <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4344694C-3500-4DC7-8CFF-BCC09D7BCB03"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 4 May 2017 20:59:29 +0300 In-Reply-To: <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> Cc: Hubert Kario , tls@ietf.org To: Kathleen Moriarty References: <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:59:42 -0000 --Apple-Mail=_4344694C-3500-4DC7-8CFF-BCC09D7BCB03 Content-Type: multipart/alternative; boundary="Apple-Mail=_D4E44B37-8B0A-4794-86B9-B394E279BE94" --Apple-Mail=_D4E44B37-8B0A-4794-86B9-B394E279BE94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 May 2017, at 16:09, Kathleen Moriarty = wrote: >=20 > I haven't approved it yet as I noticed there was no response (that I = saw) to Alexey's comment and no change in the draft as a result of his = comments. You mean these comments? https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0 = I=E2=80=99ll quote them here: > 0) There is some general awkwardness in text talking about allowed = points > formats, considering that only uncompressed form is now allowed. I = don't > have recommendations about improving text, other than the following: >=20 > If no future formats are expected, it feels almost better to recommend > against inclusion of the Point formats extension, as lack of it means > uncompressed format anyway. So this was addressed in draft -16: OLD: Implementations of this document MUST support the uncompressed format for all of their supported curves, and MUST NOT support other formats for curves defined in this specification. For backwards compatibility purposes, the point format list extension MUST still be included, and contain exactly one value: the uncompressed point format (0). NEW: Implementations of this document MUST support the uncompressed format for all of their supported curves, and MUST NOT support other formats for curves defined in this specification. For backwards compatibility purposes, the point format list extension MAY still be included, and contain exactly one value: the uncompressed point format (0). RFC 4492 = specified that if this extension is missing, it means that only the uncompressed point format is supported, so interoperability with implementations that support the uncompressed format should work with or without the extension. > 1) In Section 2.3, last paragraph: Does this paragraph apply only to = 2.3 > or does it also apply to 2.1 and 2.2? If the latter, then it needs to = be > moved to section 2. The content of the last paragraph was moved to a new section: 2.4 = . = Algorithms in Certificate Chains This specification does not impose restrictions on signature schemes used anywhere in the certificate chain. The previous version of this document required the signatures to match, but this restriction, originating in previous TLS versions is lifted here as it had been in RFC 5246 . >=20 > 2) In Section 6: >=20 > Server implementations SHOULD support all of the following cipher > suites, and client implementations SHOULD support at least one of > them: >=20 > o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 >=20 > GCM ciphers are not listed in the table earlier in the same section. = They > are defined in RFC 5289. This document doesn't have any reference to = RFC > 5289 and GCM ciphers are not discussed anywhere else in the document. Seems like I missed this one. Yoav --Apple-Mail=_D4E44B37-8B0A-4794-86B9-B394E279BE94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 May 2017, at 16:09, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I = haven't approved it yet as I noticed there was no response (that I saw) = to Alexey's comment and no change in the draft as a result of his = comments.


You mean these = comments?  
https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-V= jxXRg0

I=E2=80=99ll quote them here:

0) There is =
some general awkwardness in text talking about allowed points
formats, considering that only uncompressed form is now allowed. I don't
have recommendations about improving text, other than the following:

If no future formats are expected, it feels almost better to recommend
against inclusion of the Point formats extension, as lack of it means
uncompressed format anyway.

So this was addressed in =
draft -16:

OLD:
      Implementations of this =
document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension
   MUST still be included, and contain exactly one value: the
   uncompressed point format (0).

NEW:
      Implementations of =
this document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension MAY
   still be included, and contain exactly one value: the uncompressed
   point format (0).  RFC 4492 specified that if this extension is
   missing, it means that only the uncompressed point format is
   supported, so interoperability with implementations that support the
   uncompressed format should work with or without the extension.



1) In =
Section 2.3, last paragraph: Does this paragraph apply only to 2.3
or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
moved to section 2.


The =
content of the last paragraph was moved to a new section:
2.4.  Algorithms =
in Certificate Chains


   This specification does not impose restrictions on signature schemes
   used anywhere in the certificate chain.  The previous version of this
   document required the signatures to match, but this restriction,
   originating in previous TLS versions is lifted here as it had been in
   RFC =
5246.


2) In Section 6:

   Server implementations SHOULD support all of the following cipher
   suites, and client implementations SHOULD support at least one of
   them:

   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

GCM ciphers are not listed in the table earlier in the same section. =
They
are defined in RFC 5289. This document doesn't have any reference to RFC
5289 and GCM ciphers are not discussed anywhere else in the document.


Seems=
 like I missed this one.

Yoav


=

--Apple-Mail=_D4E44B37-8B0A-4794-86B9-B394E279BE94--

--Apple-Mail=_4344694C-3500-4DC7-8CFF-BCC09D7BCB03
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZC2wBAAoJELhJCxUKWMyZWQsH/2xxeUtOOSrTYQkHn0WCOknB
rRMjJlFoEk/vptdT+xe5cEIHoeUEhkGoJAkj4oadbKB0rp0A3YaVYV3Zm+2xAPNp
kmeD/xLI1HePiSkvVzws7TRS0nMplxLpmR4YL+O15FHT/yuI4rPZs43PhRXwHgQ/
ZJiH194IfsZjEB4VPuoCG11Q9fvF3QceCOnAgI41WXOmqV+uzhj15nnMkHLKL1Lw
YHK5gGbko4x9pDsJFLN2vFJbot4MrIdXOhRab6FeUHmdqLKyzIglMHtuACEj2YxM
j9BR4adVNx+jeKYhpMawD0BGWQ8s/QvUd6wb4viS2N9oBN6wealHRkHOhcDJTD0=
=7tvH
-----END PGP SIGNATURE-----

--Apple-Mail=_4344694C-3500-4DC7-8CFF-BCC09D7BCB03--


From nobody Thu May  4 11:03:35 2017
Return-Path: 
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 13A7F12944E for ; Thu,  4 May 2017 11:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 tVx4zJC15A92 for ; Thu,  4 May 2017 11:03:32 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E48E1293FF for ; Thu,  4 May 2017 11:03:14 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id l18so10567175ywh.3 for ; Thu, 04 May 2017 11:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W4Dg0Ok1PYkoNQR6zErEBrajX08svtMcIenOHNO9SRw=; b=JfPBgh6qQG4C76IjDCZx6P9N2BYsQm/OULUksIikqCk+XyN1pMhJw/0UXo39MQ8HnU DrmV3H5YQz/IBBHR1OJ8gPgIgLeKAc32KF6HpXNp/v9KzTtLx60VzU5qUGomeA3G0xaP wj/5pmkWoupeq9+CI3WY32r4p4T8aJ6f6zOjmAnbwG+Arz1rjp22KMNveaTBK4t49u8T rf4qNhCv7kyjSP9TV8LLIlIzDOvggUsL2DiNzWZQK6Mu2aLB0ndwvFSB/imTQCskgdqi BUq9aAfYxlCvt0bEH+cEHitjn/LE7IWea+5LXdDX/kA4Qas7L/YaCRCkt1CF0tE+GxZz 1yog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W4Dg0Ok1PYkoNQR6zErEBrajX08svtMcIenOHNO9SRw=; b=YZS7XqYXI0L9PIy9Vm/iH52kv7ys220/2VGEPhK0QSUsZIVXraVI4M8PRe51Lvj/xJ 5w1BbVc/WGQILQcVObL0rCsBu01RiH7Tx+NWslYRsmcDri6oxHv3ciwIfXjSPO0e4Owc okTx+fOhQvvn9vSDVRweUhci8z7+JQYXnmC4x3vL19YmJbGjBSbudnPdzHEdRB4XHpiO DSwf5zfxuulQ/CkJCLpZtU1WbW6dyqXFm/6jVqI6DIo3133NHeMINH9bxtDuBA88fNrS P+IBPnKBrIszBWEnxET+VK7LhsQprS8Cz9AJ/ELyRQrZqI848h+uSdH3EdByz6FQUkN5 fOSQ==
X-Gm-Message-State: AN3rC/5oANAxMQz9bpxUsczqsmREF0HCOI2iV2LeZ4KEj0sL+kslUs/4 593NVzovFqcAc7U4r7rKf0WBYtGaew==
X-Received: by 10.13.238.65 with SMTP id x62mr34378346ywe.122.1493920993863; Thu, 04 May 2017 11:03:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 11:03:12 -0700 (PDT)
In-Reply-To: 
References:  <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi> 
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 11:03:12 -0700
Message-ID: 
To: Andrei Popov 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c034d8c297c44054eb696fb
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 18:03:34 -0000

--94eb2c034d8c297c44054eb696fb
Content-Type: text/plain; charset=UTF-8

On Thu, May 4, 2017 at 10:07 AM, Andrei Popov 
wrote:

> IMHO what we have is a facility in TLS 1.3 that:
> 1. Requires extraordinary effort on the server side to mitigate replay
> (for all but the smallest deployments);
> 2. Offers no way for the client to determine whether the server is
> mitigating replay (before replay becomes possible);
>

I'm less worried about these problems. There's a nice property that the
operators of large deployments tend to also be technically sophisticated. I
don't think we'll have a problem implementing a single use cache, strike
register, we have similar systems for other services, at higher volumes.
It's a cost of being big, and that's ok.

It will be possible to tell whether a service permits replays; by trying
them. If the service permits them, that's a pretty clear CVE, and the usual
incentives work as well as they usually do.


> 3. Is trivial to enable on the client and improves connection latency;
> 4. Eliminates a nonce that other protocols (used to) rely on.
>
> While it is true that there are cases where this facility is beneficial,
> there is no doubt that it will be widely misused, in both applications and
> protocols.
>

This doesn't need to be an anchor around the neck of the whole feature.
0-RTT is still an awesome speed benefit - if servers prevent replays, I
think we have a very good balance.

-- 
Colm

--94eb2c034d8c297c44054eb696fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 10:07 AM, Andrei Popov <Andrei.Popov@m=
icrosoft.com> wrote:
IMHO w=
hat we have is a facility in TLS 1.3 that:

1. Requires extraordinary effort on the server side to mitigate replay (for=
 all but the smallest deployments);

2. Offers no way for the client to determine whether the server is mitigati=
ng replay (before replay becomes possible);

=

I'm less worried about these problems. There's a nice property=
 that the operators of large deployments tend to also be technically sophis=
ticated. I don't think we'll have a problem implementing a single u=
se cache, strike register, we have similar systems for other services, at h=
igher volumes.=C2=A0 It's a cost of being big, and that's ok.=C2=A0=


It will be possible to tell whether a service per=
mits replays; by trying them. If the service permits them, that's a pre=
tty clear CVE, and the usual incentives work as well as they usually do. =
=C2=A0
=C2=A0=C2=A0

3. Is trivial to enable on the client and improves connection latency;

4. Eliminates a nonce that other protocols (used to) rely on.



While it is true that there are cases where this facility is beneficial, th=
ere is no doubt that it will be widely misused, in both applications and pr=
otocols.

This doesn't need to be an=
 anchor around the neck of the whole feature. 0-RTT is still an awesome spe=
ed benefit - if servers prevent replays, I think we have a very good balanc=
e.

-- 
Colm




--94eb2c034d8c297c44054eb696fb--


From nobody Thu May  4 11:22:51 2017
Return-Path: 
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 F0282128799 for ; Thu,  4 May 2017 11:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 2KfYvAch9DiV for ; Thu,  4 May 2017 11:22:48 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0138.outbound.protection.outlook.com [104.47.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5D712706D for ; Thu,  4 May 2017 11:22:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EA4bUQRz3keZkigIP3amUXGtUCjWXYA4L+9SZpB6NH0=; b=Zbhw3JzhGbLLwk4kr6dUwFl3Jd3QafIb6prjSdqxc6YJQcx3/GqolM1QJJOebc9CzprUKiwvWaIWHq2zVQ20F3v7aWFfkmHHRUExHxBmaE+Tm7nafzTDal2VjSpXCSwSe9FlSG8AlzRxQmheHo89Yf6JS83kp+FZFnViN8Gau6A=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0090.namprd21.prod.outlook.com (10.161.141.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.4; Thu, 4 May 2017 18:22:43 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1084.001; Thu, 4 May 2017 18:22:42 +0000
From: Andrei Popov 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: Ilari Liusvaara , "tls@ietf.org" 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NLuoeRqJY1j061PhdwGwZhyaHj7JsAgAB3F+CAABcKAIAABEKg
Date: Thu, 4 May 2017 18:22:42 +0000
Message-ID: 
References:  <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none; allcosts.net; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [2001:4898:80e8:6::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0090; 7:OukgYKBOSfi8x1Iz0oeN4IgawHgaw7Txbbc6pYjZPlpqxBwaWqwKecGgOOpmwC42C7VSl5vgGUHQwmaU+DvuDhN0/745jPidWjXSDauDcXyZCWWZ0xkoYZS13lUTOimgFs3z3DCAmF8YGjes6ivB1a+Cwr1YICth11wmpk13MJWfd2kEJZAplylyNuWSDuv6HRz+m88drNpwbmSp3sgnyiMTh/EX6B0qdwlCJuHJEZnzSYgQ5HHOzwUcLTLFJ5u6wzcUbwOHHmTesnnWpRKdg7pGlMgBTzuzZuOGPbs2UqRXJaWYXYebygPxkGrE5YiNWoXOfclkx3EQu8Oys5POjnMkcbFwp4fSrTpm7Flv1Pk=
x-ms-office365-filtering-correlation-id: 3a27e2b7-122d-4323-2a17-08d4931a8e18
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR21MB0090; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(6072148); SRVR:DM2PR21MB0090; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0090; 
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(39860400002)(5005710100001)(5660300001)(3660700001)(10090500001)(2950100002)(77096006)(7696004)(74316002)(53936002)(6306002)(122556002)(54896002)(54906002)(55016002)(3280700002)(2900100001)(6916009)(9686003)(99286003)(25786009)(10290500003)(8676002)(8936002)(6436002)(6506006)(81166006)(7736002)(189998001)(478600001)(86612001)(38730400002)(790700001)(110136004)(4326008)(102836003)(6116002)(229853002)(33656002)(54356999)(2906002)(558084003)(50986999)(93886004)(86362001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0090; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB00917F892A1331090F3EC6E78CEA0DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 18:22:42.5461 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0090
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 18:22:50 -0000

--_000_DM2PR21MB00917F892A1331090F3EC6E78CEA0DM2PR21MB0091namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

ICAqICAgSSBkb24ndCB0aGluayB3ZSdsbCBoYXZlIGEgcHJvYmxlbSBpbXBsZW1lbnRpbmcgYSBz
aW5nbGUgdXNlIGNhY2hlLCBzdHJpa2UgcmVnaXN0ZXIsIHdlIGhhdmUgc2ltaWxhciBzeXN0ZW1z
IGZvciBvdGhlciBzZXJ2aWNlcywgYXQgaGlnaGVyIHZvbHVtZXMuDQrigKYgYW5kIHRoZXNlIHRo
aW5ncyB3b3JrIGFjcm9zcyBnZW9ncmFwaGljYWxseSBkaXN0cmlidXRlZCBkYXRhY2VudGVycywg
d2l0aG91dCBuZWdhdGluZyB0aGUgbGF0ZW5jeSBiZW5lZml0cyBvZiAwLVJUVD8NCg0KQ2hlZXJz
LA0KDQpBbmRyZWkNCg==

--_000_DM2PR21MB00917F892A1331090F3EC6E78CEA0DM2PR21MB0091namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz
dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7
bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv
d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv
bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExOTAxNDcwOTk7DQoJbXNvLWxpc3QtdHlw
ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ4NTc2OTUzNCAxODgzMzg2OTU4IDY3
Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4
NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NDsN
Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJy
aTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls
eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp
c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n
ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t
Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp
c2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu
O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JIGRvbid0IHRoaW5rIHdlJ2xsIGhhdmUgYSBwcm9i
bGVtIGltcGxlbWVudGluZyBhIHNpbmdsZSB1c2UgY2FjaGUsIHN0cmlrZSByZWdpc3Rlciwgd2Ug
aGF2ZSBzaW1pbGFyIHN5c3RlbXMgZm9yIG90aGVyIHNlcnZpY2VzLCBhdCBoaWdoZXIgdm9sdW1l
cy4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKApiBh
bmQgdGhlc2UgdGhpbmdzIHdvcmsgYWNyb3NzIGdlb2dyYXBoaWNhbGx5IGRpc3RyaWJ1dGVkIGRh
dGFjZW50ZXJzLCB3aXRob3V0IG5lZ2F0aW5nIHRoZSBsYXRlbmN5IGJlbmVmaXRzIG9mIDAtUlRU
PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkFuZHJlaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_DM2PR21MB00917F892A1331090F3EC6E78CEA0DM2PR21MB0091namp_--


From nobody Thu May  4 11:26:34 2017
Return-Path: 
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 F377E12947B for ; Thu,  4 May 2017 11:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 HZHW-GZk50RK for ; Thu,  4 May 2017 11:26:30 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96816129B45 for ; Thu,  4 May 2017 11:26:29 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l135so10857100ywb.2 for ; Thu, 04 May 2017 11:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WIb0TP/0Iw5+7GdujM+0r+TUsHeQ3ImEzG5cRn3TA/A=; b=EZHJlSa0vwsXrMst4gmdKB5Ivoyg5BggIN4/jvZE/V7cSyJ9vsJZmHdNPPzlsWnjif cD7wK8hJHqEibzu2VV/R4RKN4lLsn/TY36vfReFlM1DovPHC9P4tt3YP0QrwM1rHCITb clv20sVP96G4LW6vqN+sr6DyDwkEf6ghUfqV6qT24D5SkXluIyccdNL5Lk66tq14g9r1 mdrZlal0JTDdffBjgZoE543WWjxxKu7Ir2wrdML9oSwIdyaohUo1bBpcNQMI1L17VnqF TJhXkMK/JHtFJK8VQ5xEVc8HX3GkaNbvqFsDlN1+0NuPTZgsAajvpdJcRGcWRrAyG7eR vhzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WIb0TP/0Iw5+7GdujM+0r+TUsHeQ3ImEzG5cRn3TA/A=; b=fCAZJapTV5S3AqYcW1pXncOk1ZQ7XEBJD6B7A935+U0WFkI7s3t3IrHbisTNMmBNsG +/PBfouPJi95h1j4hQ2iI6gyz+f6JMZ80XD7jSaNfRgSwVhpXANq3CAg9Qmp1L56EYTT Tkq/v9+XrbgGPzCYCIrqSX55W6DcSpYVTzco65RuNNuWyYERMH+tgIN0Tpx5v8UHVB2P W14tEJxhFcSuK+f3bNimKjKdhYC7xbH3d034QDbsUKHhLBS8cu/VgBZIp9JhRoz7OBJP hkR32GKVfuHzvDjASzH1iqA3HNmkVKYDtHe+YiQctieHp5opcvPHKXk62g21CPfGUtUO 69Fw==
X-Gm-Message-State: AN3rC/4cWiWUGbx14T36mZpfnZ+7WYsAbJ3/aJjmsKc+h/KGDP46VJBX pj4vUUee3+2Uvuw86AIgRaj2NcSu9Q==
X-Received: by 10.129.104.69 with SMTP id d66mr5479415ywc.74.1493922388943; Thu, 04 May 2017 11:26:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 11:26:27 -0700 (PDT)
In-Reply-To: 
References:  <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi>   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 11:26:27 -0700
Message-ID: 
To: Andrei Popov 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11490b9a50c28b054eb6e9ad
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 18:26:32 -0000

--001a11490b9a50c28b054eb6e9ad
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 11:22 AM, Andrei Popov 
wrote:

>
>    - I don't think we'll have a problem implementing a single use cache,
>    strike register, we have similar systems for other services, at higher
>    volumes.
>
> =E2=80=A6 and these things work across geographically distributed datacen=
ters,
> without negating the latency benefits of 0-RTT?
>

They won't work across geographically distributed data centers, no, but I
don't think that's a significant problem. Providers already work hard to
maximize user affinity to a data center for other operational reasons;
re-routing is relatively rare and quickly repaired by issuing a new ticket.

--=20
Colm

--001a11490b9a50c28b054eb6e9ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, May 4, 2017 at 11:22 AM, Andrei Popov <A=
ndrei.Popov@microsoft.com> wrote:













    

  • I don't think we'll have a problem implementing a single use cac=
he, strike register, we have similar systems for other services, at higher =
volumes.=C2=A0


=E2=80=A6 and these things work across geogra=
phically distributed datacenters, without negating the latency benefits of =
0-RTT?

They won't=
 work across geographically distributed data centers, no, but I don't t=
hink that's a significant problem. Providers already work hard to maxim=
ize user affinity to a data center for other operational reasons; re-routin=
g is relatively rare and quickly repaired by issuing a new ticket.=C2=A0

-- 
Colm




--001a11490b9a50c28b054eb6e9ad--


From nobody Thu May  4 11:29:36 2017
Return-Path: 
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 8ED6A129B6C for ; Thu,  4 May 2017 11:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 1XKprPWa8K2y for ; Thu,  4 May 2017 11:29:33 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0098.outbound.protection.outlook.com [104.47.41.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7B312949F for ; Thu,  4 May 2017 11:29:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/2hVOhktpBadCDeNjFYI6ZalQKJTWeR+vZxdUXJFt40=; b=J+culFLKazwHlwONglShZpz4Uoa1uvT/HyK228yGRYSSmugUYkVki3o9Jn7EDIHXNldRV9dA+HK8ZPTSf5a+G/CYD8PN3O6Yddynmp63pFMrkJBs8iTuPNIrbyf8OhAjM6gg+YHTTXr8TUT/YVrTaqmLRqr8la8ODNAQI2Qtung=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0092.namprd21.prod.outlook.com (10.161.141.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.4; Thu, 4 May 2017 18:29:30 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1084.001; Thu, 4 May 2017 18:29:30 +0000
From: Andrei Popov 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: Ilari Liusvaara , "tls@ietf.org" 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NLuoeRqJY1j061PhdwGwZhyaHj7JsAgAB3F+CAABcKAIAABEKggAACPYCAAAAt4A==
Date: Thu, 4 May 2017 18:29:30 +0000
Message-ID: 
References:  <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none; allcosts.net; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [2001:4898:80e8:6::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0092; 7:Aj7CYRW4Ty23rGmoeoF5nem+nVQY0Phwfvnw9LLzD+bPQ/rjXzeUnt24eZzICd9Nx7J5dwIbru5wDDnnGB0qZ73Razft0gMIkB/hUBTw1sqjhx/QaceF0ADH/AsHMqLRJVQHp3qlNhf9UPmj1YX/MU0/VxxOBtahzYpxmWFB47beHlwDKGisueJb+Dz9V2a2IYQjWMJRUBBug1zNXXcKQHHhA73AdKHlVniKVnY6ManQPGA6IODJR2Rc9X7kh+JhLgDKb7LykzaITQE1c/ccmt5CKU9oTr5S7ZqIcz+3pl0MCQxqVINOLkG631yWA/vz2a/111KCX1bNTxRB5f3Ggv8mGFpcX4pzZFnPvumtBBY=
x-ms-office365-filtering-correlation-id: f3dd1c71-fd22-4464-69ed-08d4931b8128
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:DM2PR21MB0092; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:DM2PR21MB0092; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0092; 
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39860400002)(39400400002)(39410400002)(3280700002)(55016002)(122556002)(53936002)(99286003)(54906002)(558084003)(38730400002)(2906002)(110136004)(4326008)(3660700001)(478600001)(25786009)(9686003)(2900100001)(6306002)(10290500003)(54896002)(102836003)(77096006)(6436002)(33656002)(6916009)(6506006)(229853002)(5005710100001)(74316002)(790700001)(5660300001)(2950100002)(10090500001)(93886004)(7696004)(86612001)(86362001)(8936002)(81166006)(54356999)(189998001)(50986999)(76176999)(8676002)(7736002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0092; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091C3CCC015ABFE1904EF008CEA0DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 18:29:30.4960 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0092
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 18:29:35 -0000

--_000_DM2PR21MB0091C3CCC015ABFE1904EF008CEA0DM2PR21MB0091namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

ICAqICAgUHJvdmlkZXJzIGFscmVhZHkgd29yayBoYXJkIHRvIG1heGltaXplIHVzZXIgYWZmaW5p
dHkgdG8gYSBkYXRhIGNlbnRlciBmb3Igb3RoZXIgb3BlcmF0aW9uYWwgcmVhc29uczsgcmUtcm91
dGluZyBpcyByZWxhdGl2ZWx5IHJhcmUgYW5kIHF1aWNrbHkgcmVwYWlyZWQgYnkgaXNzdWluZyBh
IG5ldyB0aWNrZXQuDQpVbmRlcnN0b29kLCBidXQgaXNu4oCZdCBhbiBhdHRhY2tlciBnb2luZyB0
byBiZSBhYmxlIHRvIHJlLXJvdXRlIGF0IHdpbGw/DQo=

--_000_DM2PR21MB0091C3CCC015ABFE1904EF008CEA0DM2PR21MB0091namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz
dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7
bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu
NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA
bGlzdCBsMA0KCXttc28tbGlzdC1pZDo4Mjg4NjYwMzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7
DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02OTAwNDUwMzQgLTkyMDQ3Mzk4NCA2NzY5ODY5MSA2
NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5
ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1m
b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA
bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp
bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJ
e21zby1saXN0LWlkOjE2NzQ4NDA0NDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MzI5NDY3
MzQ7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl
bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps
ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90
dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJn
aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0
eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPlByb3ZpZGVycyBh
bHJlYWR5IHdvcmsgaGFyZCB0byBtYXhpbWl6ZSB1c2VyIGFmZmluaXR5IHRvIGEgZGF0YSBjZW50
ZXIgZm9yIG90aGVyIG9wZXJhdGlvbmFsIHJlYXNvbnM7IHJlLXJvdXRpbmcgaXMgcmVsYXRpdmVs
eSByYXJlIGFuZCBxdWlja2x5IHJlcGFpcmVkIGJ5IGlzc3VpbmcgYSBuZXcgdGlja2V0LiZuYnNw
OzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5kZXJzdG9vZCwg
YnV0IGlzbuKAmXQgYW4gYXR0YWNrZXIgZ29pbmcgdG8gYmUgYWJsZSB0byByZS1yb3V0ZSBhdCB3
aWxsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DM2PR21MB0091C3CCC015ABFE1904EF008CEA0DM2PR21MB0091namp_--


From nobody Thu May  4 11:32:56 2017
Return-Path: 
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 1F07A129B52 for ; Thu,  4 May 2017 11:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 Hhm4befWulBg for ; Thu,  4 May 2017 11:32:51 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824E31293EC for ; Thu,  4 May 2017 11:32:50 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id p143so5685235yba.2 for ; Thu, 04 May 2017 11:32:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iouLOTqgPhgS8Xy0uD3rwkV1kI+PBZ5rZVtdxYZXD5s=; b=qbG/h1SG/dTE5qnmourTaK7XvR9r218goX+VSFN8hYf1Sv757foEb3SP+vCaz28izI oU3Aj9Ig+ly7B3ZZ5dQo50yEPP9OQCS5M738zu4vJSdl+ipvOeNrfRs1TdAxZJZk9a6K u46YShm+36ekMBn+m9mHjOnasC0MNyQj9Je5KXefuJgLjGCHjdxqeSuNn9g76UjE+6dJ Rzk1xwqJcSUYFth9uR2ALN5xgu8kwjPJJRL62qftf97JalmNirrmlFHYZfyVh4hv9DWj R67VqR9Bnthq8cHID6joU1xVE8iq70SXtgpaVBvIiX70NAvqpEsLKl73Y7XVODuUFSr6 q8Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iouLOTqgPhgS8Xy0uD3rwkV1kI+PBZ5rZVtdxYZXD5s=; b=Mp5NaPpPhkFnNzqQyCe5q0NOLYJF0oX75frLKCqLKNCHaRsRlXcg46SX/pEdFoIos5 MaFfb+OPwZZxOenx9Ji6jM12QK6Lpex9CORtqhH7tnhQS75aoR6BxT4RmpIDSOpBnKdz VY7652v0UKrU91jqtBFN793AxZFkzD1uCQOga/V7fyU7hY0mKFDxsVbK8RQDD4cWkVJV mZfOg8umPpRO+rWTgfYksuA8IFMYKSaPUykDqRQqWYNWdoKlpYHf5FYlapuPliXoc8Qe yonXJ6BLebw1i1rAQYf6dzG9FhRkNx8vs6j2RGE29fRkJIfk5qTJ67RBcmQ5YDpCDdAf xKnQ==
X-Gm-Message-State: AN3rC/4YKNAYvjY5kTB/Crk3qNmxTjwVlvv4ptXNcDkCzV5+XvHBraBh P83khwfEIIKMqhFDv4uJSeZ7JJ0Ghw==
X-Received: by 10.37.16.212 with SMTP id 203mr22355576ybq.90.1493922769727; Thu, 04 May 2017 11:32:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 11:32:48 -0700 (PDT)
In-Reply-To: 
References:  <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi>     
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 11:32:48 -0700
Message-ID: 
To: Andrei Popov 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c0ff0403289d054eb7008d
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 18:32:53 -0000

--001a11c0ff0403289d054eb7008d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov 
wrote:

>
>    - Providers already work hard to maximize user affinity to a data
>    center for other operational reasons; re-routing is relatively rare an=
d
>    quickly repaired by issuing a new ticket.
>
> Understood, but isn=E2=80=99t an attacker going to be able to re-route at=
 will?
>

Yes, but I don't see the significance.  If the attacker reroutes the user,
or replays a ticket, to a different data center - the ticket won't work,
it'll degrade gracefully to a regular connection.  Of course the attacker
succeeded in slowing the user down, but that's possible anyway.

Maybe you're thinking of a strike register that shares a global namespace?
That would be an implementation error; tickets should be scoped to the
location they are issued from, and checked against its strike register (or
not used at all).

--=20
Colm

--001a11c0ff0403289d054eb7008d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, May 4, 2017 at 11:29 AM, Andrei Popov <A=
ndrei.Popov@microsoft.com> wrote:











    

  • Providers already work hard to maximize user affinity to a data center =
for other operational reasons; re-routing is relatively rare and quickly re=
paired by issuing a new ticket.=C2=A0


Understood, but isn=E2=80=99t an attacker goi=
ng to be able to re-route at will?

Yes, but I don't see the significance.=C2=A0 If the attacker re=
routes the user, or replays a ticket, to a different data center - the tick=
et won't work, it'll degrade gracefully to a regular connection.=C2=
=A0 Of course the attacker succeeded in slowing the user down, but that'=
;s possible anyway.=C2=A0

Maybe you're thinkin=
g of a strike register that shares a global namespace? That would be an imp=
lementation error; tickets should be scoped to the location they are issued=
 from, and checked against its strike register (or not used at all).=C2=A0<=
/div>

-- 
Colm




--001a11c0ff0403289d054eb7008d--


From nobody Thu May  4 12:03:18 2017
Return-Path: 
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 D8289129516 for ; Thu,  4 May 2017 12:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=microsoft.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 rklGg-aJGaoU for ; Thu,  4 May 2017 12:03:15 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1FF128D69 for ; Thu,  4 May 2017 12:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KIKBZ2G3EzmiK3XsRtLNrMji3gOHbjgAJXsEwXwEhFM=; b=H5PqL4etTPDqQ22ZW8lY3u+dncqyqLmBaIQuk8XFQf01TUjbjAaYKtRhJ0YRFUIrc8bbhyUn22/30MGYK0EUyp7pX86dRz/YFlz+ZDernnlbmMxrfsOktNePxa899LzQ3IxzXdPI5On5IVLFUUvQddI2v1lgqUEXE43hxvvFP5M=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.4; Thu, 4 May 2017 19:03:11 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1084.001; Thu, 4 May 2017 19:03:11 +0000
From: Andrei Popov 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: Ilari Liusvaara , "tls@ietf.org" 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NLuoeRqJY1j061PhdwGwZhyaHj7JsAgAB3F+CAABcKAIAABEKggAACPYCAAAAt4IAAAZoAgAAGKVA=
Date: Thu, 4 May 2017 19:03:11 +0000
Message-ID: 
References:  <20170504093429.GA31781@LK-Perkele-V2.elisa-laajakaista.fi>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none; allcosts.net; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [2001:4898:80e8:6::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0091; 7:UnhgywGVvhWbbc6roXkZxgYTqmEVm+zV1GJgh06Llgw4M/h4Ns3E19MjU9GPLKPttCv1y7peKIXw0ELQWTHVD3T1Wt94B4Jt3SYbXyL9wCFPgM5gqKwZRwpSq9J+vvRiRu7R+WhPPUrgy+EBWlKo1yYyADzs/iCZL74eiGi/XR/3nH55TnT3YfCXKGJ5XHFhD28RkkGh7lDsDd9W1qkJgE9d2dUy8q8v9R+sOxyRwU55Q65aEDOvKRLtHgE1mR49lLTMTkxfLZwAMJ41rnhRveefZm5UE1Za32Bto8MJXtBIlUdL7ci1hfTmiSZeTnvLKLIKSisx75P5PGDGzdmpwCLfKyFmABtpcr6FxP+mCmM=
x-ms-office365-filtering-correlation-id: c61905b0-8dc5-44db-e0f0-08d4932035f1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:DM2PR21MB0091; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DM2PR21MB0091; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0091; 
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39860400002)(39410400002)(39400400002)(39850400002)(24454002)(377454003)(6506006)(77096006)(6306002)(54896002)(6436002)(7736002)(55016002)(54906002)(8676002)(81166006)(99286003)(74316002)(3280700002)(122556002)(8936002)(189998001)(53936002)(93886004)(7110500001)(110136004)(19609705001)(229853002)(3660700001)(9686003)(4326008)(38730400002)(2900100001)(236005)(53546009)(25786009)(15650500001)(2420400007)(86362001)(33656002)(76176999)(50986999)(54356999)(7696004)(86612001)(5660300001)(478600001)(2906002)(10290500003)(10710500007)(6916009)(2950100002)(790700001)(102836003)(10090500001)(5005710100001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0091; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091A1AAF51428FBF96CECBD8CEA0DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 19:03:11.7381 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0091
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 19:03:17 -0000

--_000_DM2PR21MB0091A1AAF51428FBF96CECBD8CEA0DM2PR21MB0091namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW5kZWVkLCBhcyBsb25nIGFzIHRoZSBzY29wZSBvZiB0aGUgdGlja2V0IDw9IHNjb3BlIG9mIHRo
ZSBub25jZSBkYXRhYmFzZSwgaXQgYXBwZWFycyB0aGF0IHJlcm91dGluZyB3b2504oCZIGhlbHAg
dGhlIGF0dGFja2VyLg0KRnJvbTogQ29sbSBNYWNDw6FydGhhaWdoIFttYWlsdG86Y29sbUBhbGxj
b3N0cy5uZXRdDQpTZW50OiBUaHVyc2RheSwgTWF5IDQsIDIwMTcgMTE6MzMgQU0NClRvOiBBbmRy
ZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IElsYXJpIExpdXN2YWFy
YSA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPjsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W1RMU10gU2VjdXJpdHkgcmV2aWV3IG9mIFRMUzEuMyAwLVJUVA0KDQpPbiBUaHUsIE1heSA0LCAy
MDE3IGF0IDExOjI5IEFNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t
PG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQogICogICBQcm92
aWRlcnMgYWxyZWFkeSB3b3JrIGhhcmQgdG8gbWF4aW1pemUgdXNlciBhZmZpbml0eSB0byBhIGRh
dGEgY2VudGVyIGZvciBvdGhlciBvcGVyYXRpb25hbCByZWFzb25zOyByZS1yb3V0aW5nIGlzIHJl
bGF0aXZlbHkgcmFyZSBhbmQgcXVpY2tseSByZXBhaXJlZCBieSBpc3N1aW5nIGEgbmV3IHRpY2tl
dC4NClVuZGVyc3Rvb2QsIGJ1dCBpc27igJl0IGFuIGF0dGFja2VyIGdvaW5nIHRvIGJlIGFibGUg
dG8gcmUtcm91dGUgYXQgd2lsbD8NCg0KWWVzLCBidXQgSSBkb24ndCBzZWUgdGhlIHNpZ25pZmlj
YW5jZS4gIElmIHRoZSBhdHRhY2tlciByZXJvdXRlcyB0aGUgdXNlciwgb3IgcmVwbGF5cyBhIHRp
Y2tldCwgdG8gYSBkaWZmZXJlbnQgZGF0YSBjZW50ZXIgLSB0aGUgdGlja2V0IHdvbid0IHdvcmss
IGl0J2xsIGRlZ3JhZGUgZ3JhY2VmdWxseSB0byBhIHJlZ3VsYXIgY29ubmVjdGlvbi4gIE9mIGNv
dXJzZSB0aGUgYXR0YWNrZXIgc3VjY2VlZGVkIGluIHNsb3dpbmcgdGhlIHVzZXIgZG93biwgYnV0
IHRoYXQncyBwb3NzaWJsZSBhbnl3YXkuDQoNCk1heWJlIHlvdSdyZSB0aGlua2luZyBvZiBhIHN0
cmlrZSByZWdpc3RlciB0aGF0IHNoYXJlcyBhIGdsb2JhbCBuYW1lc3BhY2U/IFRoYXQgd291bGQg
YmUgYW4gaW1wbGVtZW50YXRpb24gZXJyb3I7IHRpY2tldHMgc2hvdWxkIGJlIHNjb3BlZCB0byB0
aGUgbG9jYXRpb24gdGhleSBhcmUgaXNzdWVkIGZyb20sIGFuZCBjaGVja2VkIGFnYWluc3QgaXRz
IHN0cmlrZSByZWdpc3RlciAob3Igbm90IHVzZWQgYXQgYWxsKS4NCg0KLS0NCkNvbG0NCg==

--_000_DM2PR21MB0091A1AAF51428FBF96CECBD8CEA0DM2PR21MB0091namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcwMDkw
NzkyMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcxMTAxNDk4Njt9DQpAbGlzdCBsMDpsZXZl
bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl
dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww
OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJ
e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQsIGFzIGxv
bmcgYXMgdGhlIHNjb3BlIG9mIHRoZSB0aWNrZXQgJmx0Oz0gc2NvcGUgb2YgdGhlIG5vbmNlIGRh
dGFiYXNlLCBpdCBhcHBlYXJzIHRoYXQgcmVyb3V0aW5nIHdvbnTigJkgaGVscCB0aGUgYXR0YWNr
ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBDb2xtIE1hY0PDoXJ0aGFpZ2ggW21h
aWx0bzpjb2xtQGFsbGNvc3RzLm5ldF0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkg
NCwgMjAxNyAxMTozMyBBTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWku
UG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElsYXJpIExpdXN2YWFyYSAm
bHQ7aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tJmd0OzsgdGxzQGlldGYub3JnPGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbVExTXSBTZWN1cml0eSByZXZpZXcgb2YgVExTMS4zIDAtUlRUPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSA0LCAyMDE3IGF0IDExOjI5IEFN
LCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K
PGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl
ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClByb3ZpZGVycyBhbHJlYWR5IHdvcmsg
aGFyZCB0byBtYXhpbWl6ZSB1c2VyIGFmZmluaXR5IHRvIGEgZGF0YSBjZW50ZXIgZm9yIG90aGVy
IG9wZXJhdGlvbmFsIHJlYXNvbnM7IHJlLXJvdXRpbmcgaXMgcmVsYXRpdmVseSByYXJlIGFuZCBx
dWlja2x5IHJlcGFpcmVkIGJ5IGlzc3VpbmcgYSBuZXcgdGlja2V0LiZuYnNwOzxvOnA+PC9vOnA+
PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5VbmRlcnN0b29kLCBidXQgaXNu4oCZ
dCBhbiBhdHRhY2tlciBnb2luZyB0byBiZSBhYmxlIHRvIHJlLXJvdXRlIGF0IHdpbGw/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+WWVzLCBidXQgSSBkb24ndCBzZWUgdGhlIHNpZ25pZmljYW5jZS4mbmJz
cDsgSWYgdGhlIGF0dGFja2VyIHJlcm91dGVzIHRoZSB1c2VyLCBvciByZXBsYXlzIGEgdGlja2V0
LCB0byBhIGRpZmZlcmVudCBkYXRhIGNlbnRlciAtIHRoZSB0aWNrZXQgd29uJ3Qgd29yaywgaXQn
bGwgZGVncmFkZSBncmFjZWZ1bGx5IHRvIGEgcmVndWxhciBjb25uZWN0aW9uLiZuYnNwOyBPZiBj
b3Vyc2UgdGhlIGF0dGFja2VyIHN1Y2NlZWRlZCBpbiBzbG93aW5nDQogdGhlIHVzZXIgZG93biwg
YnV0IHRoYXQncyBwb3NzaWJsZSBhbnl3YXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIHlvdSdyZSB0aGlua2luZyBvZiBh
IHN0cmlrZSByZWdpc3RlciB0aGF0IHNoYXJlcyBhIGdsb2JhbCBuYW1lc3BhY2U/IFRoYXQgd291
bGQgYmUgYW4gaW1wbGVtZW50YXRpb24gZXJyb3I7IHRpY2tldHMgc2hvdWxkIGJlIHNjb3BlZCB0
byB0aGUgbG9jYXRpb24gdGhleSBhcmUgaXNzdWVkIGZyb20sIGFuZCBjaGVja2VkIGFnYWluc3Qg
aXRzIHN0cmlrZSByZWdpc3RlciAob3Igbm90IHVzZWQgYXQgYWxsKS4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbG08bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_DM2PR21MB0091A1AAF51428FBF96CECBD8CEA0DM2PR21MB0091namp_--


From nobody Thu May  4 12:12:53 2017
Return-Path: 
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 E431E126D73 for ; Thu,  4 May 2017 12:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OaQFcjYdrAow for ; Thu,  4 May 2017 12:12:50 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A7B12947B for ; Thu,  4 May 2017 12:12:42 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id m91so18137145qte.3 for ; Thu, 04 May 2017 12:12:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eZQxW9/fLz0Bpo5D0LyMqqRPjuFsDcwK58y7mwaNrdk=; b=PCIwNxQoRsepugiXS6UtMbx6zkSKTXVJeSJHb/4ey2VnPZO87lS1F/l7ThuVoGyx03 MsV/eYoZbmeYttys4slcLdx8LolDxve27YDfSPnBROyKzzTBJfEfynmnBtADSmOxa8ts UpfAfgAWVkwGuGiRelKD8jxOBcpmDN0Xf6Y2rQr7fSc+R05L2vjfvSR+M1Hdfkke2uL9 LIflqHZ8r2ubX6hEU02YExDy0Y4klV6Gnt+AUJFB4SxrYXAczUvYKcRRMpiVT954ZAjP VaedX4WEnQ/7c1z3TvmPvKp/skLOk7P56JBHPYbNb09MJOuuraG9zS3xUf40zBBLSuPj 3t4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eZQxW9/fLz0Bpo5D0LyMqqRPjuFsDcwK58y7mwaNrdk=; b=fCoyMX07kwHrBdLZF8sWzj9h5Cqph8VWwdwYMRfA8CHFEJUq7S1co5oDC3GZY2cuLX ZFAnuXcGWtrrniypHnU/faDKD6TQTnCiNGoug0+EdxJZ4rluP5IG+xs/uAgXfGFgI4MY r8KzoMetMEevdVBnNnia5njMcfoaNo9aVjYNyOQAArwqx4hRYYr4guNRFiSTYOkTfM55 tvyooxkWug6CCtW70Z+jKwWcr/i3/UqYAn4K0xelFKxGL8231S6+DV5lHtDn+RtTxwh2 0ZrcQuelpYIeaaxqIFSEJPFoFiFGWTQwbFbYYqRGszems2yGeNru7IV4u6XHjBwqL70h kGbQ==
X-Gm-Message-State: AN3rC/4ZBx+CtYPpqL8wWDZJO0H+X9MRojCTpXTOX0uHBemQ4475887v XB2vmFjhldQ8/36IfvrVOj+x+wDsRsZB
X-Received: by 10.237.36.17 with SMTP id r17mr37165225qtc.44.1493925162125; Thu, 04 May 2017 12:12:42 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.12.172.151 with HTTP; Thu, 4 May 2017 12:12:41 -0700 (PDT)
In-Reply-To: 
References:  
From: Erik Nygren 
Date: Thu, 4 May 2017 15:12:41 -0400
X-Google-Sender-Auth: RwRJPC3rUEzKLpA26DtrG6C4TzM
Message-ID: 
To: Eric Rescorla 
Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11405cbe9c11a1054eb78e55
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 19:12:52 -0000

--001a11405cbe9c11a1054eb78e55
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:

>
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>

I don't believe this is technically viable for the large-scale server
operators most interested in 0-RTT.  Having session ticket reuse across
clusters is a requirement for performance, especially in cases such as
moving load between clusters.  In the cross-cluster case, neither session
caches nor strike registers are possible in the time-frames that are
interesting and relevant to 0-RTT (as strong consistency between clusters
has inherent latency that isn't possible in the 0-RTT time-frames).

I fear having a "SHOULD" requirement here is one that will be widely
ignored.

Anything stateful here defeats the purpose of session tickets and is also
far too vulnerable to DDoS attacks to be useful, especially when trying to
scale up
to large clusters.

Many of the discussions I've been in seem to have concluded that we should
always be assuming that 0-RTT data can and will be replayed, and
applications
and application protocols need to design and use it carefully, accordingly.

Some of these mechanisms (timestamps, strike registers, etc)
are useful for servers protecting themselves from DDoS attacks
but aren't useful against an adversary trying to actively exploit replays.


4. I would add to this that we recommend that proxy/CDN implementations
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was i=
n
> Colm's original message).
>

I'm not entirely sure what back-ends are going to do here.  By the time
they gain visibility into this it is too late.

As some of us have been saying for awhile, we need to assume that 0-RTT
data is replayable and require application protocols and clients
implementing those protocols to define when and when it is not safe to
use.  For example, if exporters from 0RTT are not safe to use, we should
make that super-clear that this is not a safe use of 0RTT.

In the HTTP case, Patrick McManus has pointed out that many
application-layer clients will retry/replay non-idempotent POST operations
regardless even over 1RTT (and if the app doesn't, the user will just click
reload).  The best defense against these classes of issues is for
end-to-end application semantics rather than trying to provide properties
at the session  layer.

        Erik




> On Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh 
> wrote:
>
>> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
>> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s=
2n.
>> Thanks to feedback in the room I've now tightened up the findings from t=
he
>> review and posted them as an issue on the draft GitHub repo:
>>
>> https://github.com/tlswg/tls13-spec/issues/1001
>>
>> I'll summarize the summary: Naturally the focus was on forward secrecy
>> and replay. On forward secrecy the main finding was that it's not necess=
ary
>> to trade off Forward Secrecy and 0-RTT. A single-use session cache can
>> provide it, and with the modification that ekr has created in
>> https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for
>> both pre-auth and post-auth tickets, and it allows clients to build up
>> pools of meaningfully distinct tickets.
>>
>> There's also an observation there that it should really be that clients
>> "MUST" use tickets only once. Any re-use likely discloses the obfuscated
>> ticket age, which is intended to be secret. Right now it's a "SHOULD".
>>
>> On replay, the main finding is that what's in the draft is not workably
>> secure, and the review includes 5 different attacks against 0-RTT data t=
o
>> illustrate that. Attacks 1 and 2 show that the kind of replay permitted =
by
>> the draft is very different from the kind of replay permitted by dkg's
>> existing downgrade-and-retry attack. I also go over why it very very
>> difficult to many applications to achieve that idempotency, and why one
>> idempotency pattern actually relies on non-replayable messages.
>>
>> Attack 3 shows that idempotency is not sufficient, applications must als=
o
>> be free of measurable side-effects, which is not practical.  Attack 4 sh=
ows
>> that 0-RTT breaks a common security mechanism: spoofing-resistant
>> throttles. Attack 5 shows that 0-RTT replay-ability enables an additiona=
l
>> form of traffic analysis.
>>
>> The recommendation in the review is that implementations "MUST" prevent
>> replays of 0-RTT section, with some additional discussion about why the
>> existing advice is unlikely to be followed, and why consistent
>> interoperability matters here.
>>
>> Unfortunately, I wasn't aware until Friday that this review would be
>> coming so late in the TLD1.3 draft process, and my apologies for that. I=
 am
>> now planning to attend the future WG in-person meetings and look forward=
 to
>> seeing many of you there.
>>
>> --
>> Colm
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a11405cbe9c11a1054eb78e55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, May 3, 2017 at 11:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:<=
br>

<=
div>1. A SHOULD-level requirement for server-side 0-RTT defense, explaining=

both session-cache and strike register styles and the merits of =
each.

I don't believe this =
is technically viable for the large-scale server operators most interested =
in 0-RTT.=C2=A0 Having session ticket reuse across clusters is a requiremen=
t for performance, especially in cases such as moving load between clusters=
.=C2=A0 In the cross-cluster case, neither session caches nor strike regist=
ers are possible in the time-frames that are interesting and relevant to 0-=
RTT (as strong consistency between clusters has inherent latency that isn&#=
39;t possible in the 0-RTT time-frames).

I fear having a =
"SHOULD" requirement here is one that will be widely ignored.
=

Anything stateful here defeats the purpose of session tickets and =
is also
far too vulnerable to DDoS attacks to be useful, espe=
cially when trying to scale up
to large clusters.

Many of the discussions I've been in seem to have concluded that we s=
hould 
always be assuming that 0-RTT data can and will be rep=
layed, and applications 
and application protocols need to design and us=
e it carefully, accordingly.

Some of these mec=
hanisms (timestamps, strike registers, etc) 
are useful for servers prot=
ecting themselves from DDoS attacks
but aren't useful aga=
inst an adversary trying to actively exploit replays.
=C2=A0<=
/div>
4. I would add to this that we recommend that proxy/CDN imp=
lementations
signal which data is 0-RTT and which is 1-RTT to the=
 back-end (this was in
Colm's original message).
<=
/blockquote>

I'm not entirely sure what back-ends ar=
e going to do here.=C2=A0 By the time they gain visibility into this it is =
too late.
=C2=A0
As some of us have been saying for=
 awhile, we need to assume that 0-RTT data is replayable and require applic=
ation protocols and clients implementing those protocols to define when and=
 when it is not safe to use.=C2=A0 For example, if exporters from 0RTT are =
not safe to use, we should make that super-clear that this is not a safe us=
e of 0RTT.

In the HTTP case, Patrick McManus h=
as pointed out that many application-layer clients will retry/replay non-id=
empotent POST operations regardless even over 1RTT (and if the app doesn=
9;t, the user will just click reload).=C2=A0 The best defense against these=
 classes of issues is for end-to-end application semantics rather than tryi=
ng to provide properties at the session=C2=A0 layer.

=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

<=
br>=C2=A0
On=
 Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh <=
colm@allcosts.net> wrote:
On Sunday at the T=
LS:DIV workshop I presented a summary of findings of a security review we d=
id on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. Thanks to feedback =
in the room I've now tightened up the findings from the review and post=
ed them as an issue on the draft GitHub repo:


<=
div>I'll summarize the summary: Naturally the focus was on forward secr=
ecy and replay. On forward secrecy the main finding was that it's not n=
ecessary to trade off Forward Secrecy and 0-RTT. A single-use session cache=
 can provide it, and with the modification that ekr has created in=C2=A0htt=
ps://github.com/tlswg/tls13-spec/pull/998 , such a cache works for=
 both pre-auth and post-auth tickets, and it allows clients to build up poo=
ls of meaningfully distinct tickets.

There's a=
lso an observation there that it should really be that clients "MUST&q=
uot; use tickets only once. Any re-use likely discloses the obfuscated tick=
et age, which is intended to be secret. Right now it's a "SHOULD&q=
uot;.=C2=A0

On replay, the main finding is that wh=
at's in the draft is not workably secure, and the review includes 5 dif=
ferent attacks against 0-RTT data to illustrate that. Attacks 1 and 2 show =
that the kind of replay permitted by the draft is very different from the k=
ind of replay permitted by dkg's existing downgrade-and-retry attack. I=
 also go over why it very very difficult to many applications to achieve th=
at idempotency, and why one idempotency pattern actually relies on non-repl=
ayable messages.=C2=A0

Attack 3 shows that idempot=
ency is not sufficient, applications must also be free of measurable side-e=
ffects, which is not practical.=C2=A0 Attack 4 shows that 0-RTT breaks a co=
mmon security mechanism: spoofing-resistant throttles. Attack 5 shows that =
0-RTT replay-ability enables an additional form of traffic analysis.=C2=A0<=
/div>

The recommendation in the review is that implement=
ations "MUST" prevent replays of 0-RTT section, with some additio=
nal discussion about why the existing advice is unlikely to be followed, an=
d why consistent interoperability matters here.=C2=A0

<=
div>Unfortunately, I wasn't aware until Friday that this review would b=
e coming so late in the TLD1.3 draft process, and my apologies for that. I =
am now planning to attend the future WG in-person meetings and look forward=
 to seeing many of you there.=C2=A0

-- 
Colm




_______________________________=
________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a11405cbe9c11a1054eb78e55--


From nobody Thu May  4 12:40:04 2017
Return-Path: 
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 51A74129B19 for ; Thu,  4 May 2017 12:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 apqVus7EP5pp for ; Thu,  4 May 2017 12:39:58 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C272126B7F for ; Thu,  4 May 2017 12:39:58 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id AF56BA004921; Thu,  4 May 2017 12:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=c3DqVJd7hzo7rf ZzQ0tP32je9q4=; b=QAmuKFBIV/M4j7+y4QlRR3pUb6KAdb2GptB7e82vju5VZU hyfS47rfG3tFTtHW41RTkJd6bEP0j9qYQG6GVMpnDhG41Y9Q/dP0Dv1bJQIPiR6u TJUizqM3idyNBaVZGlEiqaHzqZSGGGXNbyFiRBFX56916vwb5bdJm1LoYqfRc=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 3E7B7A004920; Thu,  4 May 2017 12:39:57 -0700 (PDT)
Date: Thu, 4 May 2017 14:39:54 -0500
From: Nico Williams 
To: Erik Nygren 
Cc: Eric Rescorla , "tls@ietf.org" 
Message-ID: <20170504193953.GU10188@localhost>
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 19:40:02 -0000

On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > both session-cache and strike register styles and the merits of each.

The SHOULD should say that the server-side needs to apply a replay cache
OR fallback onto a full exchange when the 0-rtt data payload involves a
non-idempotent operation.

> I don't believe this is technically viable for the large-scale server
> operators most interested in 0-RTT.  Having session ticket reuse across
> clusters is a requirement for performance, especially in cases such as
> moving load between clusters.  In the cross-cluster case, neither session
> caches nor strike registers are possible in the time-frames that are
> interesting and relevant to 0-RTT (as strong consistency between clusters
> has inherent latency that isn't possible in the 0-RTT time-frames).

Making the SHOULD be about non-idempotent 0-rtt payloads is sufficient.

That is, if you're GETting something and the server correctly makes GET
idempotent, then you can accept 0-rtt without any replay cache checking.

A POST, on the other hand, should get the fallback-to-full-handshake
treatment.  (And, indeed, the application should not even bother with a
0-rtt POST.)

> I fear having a "SHOULD" requirement here is one that will be widely
> ignored.

It should not be ignored as to non-idempotent operations though!

> Anything stateful here defeats the purpose of session tickets [...]

Right.

> Many of the discussions I've been in seem to have concluded that we
> should always be assuming that 0-RTT data can and will be replayed,
> and applications and application protocols need to design and use it
> carefully, accordingly.

Correct.  See the above text about idempotency.

Nico
-- 


From nobody Thu May  4 12:44:12 2017
Return-Path: 
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 2D385128C83 for ; Thu,  4 May 2017 12:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level: 
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Ywo-cYgs-4fh for ; Thu,  4 May 2017 12:44:08 -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 C71ED1294CD for ; Thu,  4 May 2017 12:44:08 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8088A496C3D; Thu,  4 May 2017 19:44:07 +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 60AD0496C1D; Thu,  4 May 2017 19:44:07 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493927047; bh=gaZZt3zAgpNT64ofrB9pcNMbO16OydigWYxIvQXYgiA=; l=3376; h=To:References:Cc:From:Date:In-Reply-To:From; b=IgkArkoZePI5cT+gwKylFnYtJiKETqnOgAI/+7G3xti6ckUS5dCjemVG47WhTt9NL YiTIsFYTZwJVvacCW6X8hK+xtqWObqSjLeQhPxDY584cwEPjYUB/8/PxLVfVHqM3fR Fye5VLVxYD4ex4DpWG9+6ZBu+1flcgdpuVxwu6sU=
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 A232F1E103; Thu,  4 May 2017 19:44:06 +0000 (GMT)
To: Nico Williams , Erik Nygren 
References:    <20170504193953.GU10188@localhost>
Cc: "tls@ietf.org" 
From: Benjamin Kaduk 
Message-ID: <1fdbaf5f-e425-2c8a-04a1-ac6dae8daa59@akamai.com>
Date: Thu, 4 May 2017 14:44:06 -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: <20170504193953.GU10188@localhost>
Content-Type: multipart/alternative; boundary="------------1D0E1C8D501B80B56FB84865"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 19:44:10 -0000

This is a multi-part message in MIME format.
--------------1D0E1C8D501B80B56FB84865
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/04/2017 02:39 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
>> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the merits of each.
> The SHOULD should say that the server-side needs to apply a replay cache
> OR fallback onto a full exchange when the 0-rtt data payload involves a
> non-idempotent operation.

You seem confused on this key point.  The server commits to accepting or
rejecting *all* early data, *before* it can look inside and see what it
is (in particular, whether or not it is idempotent).

>
>> Many of the discussions I've been in seem to have concluded that we
>> should always be assuming that 0-RTT data can and will be replayed,
>> and applications and application protocols need to design and use it
>> carefully, accordingly.
> Correct.  See the above text about idempotency.
>
>

Which is why we (try to) make such a big deal about having an
application profile -- to write down what is actually idempotent.

-Ben

--------------1D0E1C8D501B80B56FB84865
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/04/2017 02:39 PM, Nico Williams wrote:

    

      
On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:


      

        
On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:


        

          
1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
both session-cache and strike register styles and the merits of each.


        

      

      
The SHOULD should say that the server-side needs to apply a replay cache
OR fallback onto a full exchange when the 0-rtt data payload involves a
non-idempotent operation.


    

    

    You seem confused on this key point.  The server commits to
    accepting or rejecting *all* early data, *before* it can look inside
    and see what it is (in particular, whether or not it is idempotent).

    

    

      

      

      

        
Many of the discussions I've been in seem to have concluded that we
should always be assuming that 0-RTT data can and will be replayed,
and applications and application protocols need to design and use it
carefully, accordingly.


      

      
Correct.  See the above text about idempotency.




    

    

    Which is why we (try to) make such a big deal about having an
    application profile -- to write down what is actually idempotent.

    

    -Ben

  


--------------1D0E1C8D501B80B56FB84865--


From nobody Thu May  4 12:49:30 2017
Return-Path: 
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 2C34C129A8E for ; Thu,  4 May 2017 12:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 emrs02iY7m2O for ; Thu,  4 May 2017 12:49:27 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A09F129B19 for ; Thu,  4 May 2017 12:49:23 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 42A94A00491B; Thu,  4 May 2017 12:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=pE2E6hurBdNMLp rMTm5mdcNMVIM=; b=OEPwWpNMDeLzQlsraXxXkohrpFerkxoe4XIyznlwX8HI9p 6C6ikfWRn4hLgm/gcNw9GtLhEjM/iAwnBt/O33b6YSYfS+lGTG01mLLT8qKvK7/P mkFQQx+s+cVA8Pb8LWKbOp5Ac3VMvHjkmbUbb90IGOilJDoH8uxeG3Rrn5MVw=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id E084CA00491C; Thu,  4 May 2017 12:49:22 -0700 (PDT)
Date: Thu, 4 May 2017 14:49:20 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: Erik Nygren , "tls@ietf.org" 
Message-ID: <20170504194919.GV10188@localhost>
References:    <20170504193953.GU10188@localhost> <1fdbaf5f-e425-2c8a-04a1-ac6dae8daa59@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1fdbaf5f-e425-2c8a-04a1-ac6dae8daa59@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 19:49:29 -0000

On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 02:39 PM, Nico Williams wrote:
> > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> >>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> >>> both session-cache and strike register styles and the merits of each.
> > The SHOULD should say that the server-side needs to apply a replay cache
> > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > non-idempotent operation.
> 
> You seem confused on this key point.  The server commits to accepting or
> rejecting *all* early data, *before* it can look inside and see what it
> is (in particular, whether or not it is idempotent).

Sure, that's fine.  You could run an HTTP server that only accepts
HEADs, GETs, maybe DELETEs, and accepts 0-rtt and have the client send
all POSTs and such to a different HTTP server.

> > [...]
> 
> Which is why we (try to) make such a big deal about having an
> application profile -- to write down what is actually idempotent.

It's one good reason, but we were doing that ages ago, before 0-rtt was
ever proposed.  (Well, Kerberos has a 0-rtt scheme, with very little
guidance on this point...)

Nico
-- 


From nobody Thu May  4 13:01:09 2017
Return-Path: 
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 1C62D1294CD for ; Thu,  4 May 2017 13:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 nxENPEGFu1rf for ; Thu,  4 May 2017 13:01:06 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF81294E0 for ; Thu,  4 May 2017 13:01:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7FEF5214FF; Thu,  4 May 2017 23:01:04 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id DuGKM5IGesyb; Thu,  4 May 2017 23:01:03 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5604EC4; Thu,  4 May 2017 23:01:03 +0300 (EEST)
Date: Thu, 4 May 2017 23:01:02 +0300
From: Ilari Liusvaara 
To: Erik Nygren 
Cc: Eric Rescorla , "tls@ietf.org" 
Message-ID: <20170504200102.GA8268@LK-Perkele-V2.elisa-laajakaista.fi>
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:01:08 -0000

On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> 
> >
> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > both session-cache and strike register styles and the merits of each.
> >

> Many of the discussions I've been in seem to have concluded that we should
> always be assuming that 0-RTT data can and will be replayed, and
> applications
> and application protocols need to design and use it carefully, accordingly.

The problem is, the amount of replays is so great even non-idempotency
that is normally of no consequence becomes a major problem. It isn't one
or two or three replays, it could be _millions_ of replays.

Almost nothing is idempotent enough, unless extremely carefully designed,
and very few things are.

There are loads of GET endpoints there that don't have any wild non-
idempotent behaviour, but still aren't idempotent enough.




-Ilari


From nobody Thu May  4 13:10:15 2017
Return-Path: 
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 C32E7129A8E for ; Thu,  4 May 2017 13:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xwQNjxAMbeTZ for ; Thu,  4 May 2017 13:10:13 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCB8129687 for ; Thu,  4 May 2017 13:10:11 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id q4so6211007pga.3 for ; Thu, 04 May 2017 13:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7pr8r9bHH2z/KBLnyE7T4a0+pvEden0hTeAEY9q1BL4=; b=ipg6xh8JZdmeqGT8dF5lVGtfMrqhr/5iLedQUXwV103CM4dISbjOlJSCE4kkO3ED3K h8Lx156342KJYQUh15kva1HT3G5JxbKhwQrRl4IZc511ndvKLuuSjilkeSQw5RqMVwlD ZYFLFN2sZVg3r3RbrwWIPM9CUl1ZD2zYGWjgiPUzgoVhHa95ddQ6vnwAsAHYoMBVfNy1 E5mRxRJqSu0RNgwBTdUHraFlIUQqvLNydyqEgA9Bav6AdNPDUN5QO5QcCRXuD/SCpY42 3TZhAgP3xvOmPBr3MIb8Px4flyS0lDcs/UtlVn92mkKMk06vE+rQC/OgsoDBp/fIoeLg V/dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7pr8r9bHH2z/KBLnyE7T4a0+pvEden0hTeAEY9q1BL4=; b=GsuCyKinUEFo/m36ElfH3O3A44nxXS0BjIt4Bw6DfCVfKslq6peaoSLsfcV2ONJh0Y 4sKc1QGK7PSBu98gfXolt9cU9lT2bdvtqaxcKy0EbcgauuCvH2VbgduFdwBc9UaKNyQQ 7iwRdeLg6Tn7gWwdFq/w6AXgVxLlCBF+6PWM+5A6tsR1K+Eem/PUH79ygklH9EKyDltQ jZbcIEXc9Z0Vh0QKHuQ1OUT73CURUXPwVreFzmi8+PB1GI5Eph+VPo1dOQUmIScyTIy6 BigF0EABV27a1gmpn/+jZebexNRXAiugSv2m5lF8VJrcMjnNEgejtCwY/uUwUy25+2zb Yuew==
X-Gm-Message-State: AN3rC/4k9vvhetNKVAvkmd3BmYoAL2o65/2O6nohbhe8R6vpfhcWCkuJ dDwWoRoEt04z3OMl/W5CHV5Mvsckqg==
X-Received: by 10.84.241.133 with SMTP id b5mr4890948pll.107.1493928611400; Thu, 04 May 2017 13:10:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.185.143 with HTTP; Thu, 4 May 2017 13:09:30 -0700 (PDT)
In-Reply-To: <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com>
References:  <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com>
From: Kathleen Moriarty 
Date: Thu, 4 May 2017 16:09:30 -0400
Message-ID: 
To: Yoav Nir 
Cc: Hubert Kario , "" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:10:15 -0000

Yoav,

On Thu, May 4, 2017 at 1:59 PM, Yoav Nir  wrote:
>
> On 4 May 2017, at 16:09, Kathleen Moriarty
>  wrote:
>
> I haven't approved it yet as I noticed there was no response (that I saw)=
 to
> Alexey's comment and no change in the draft as a result of his comments.
>
>
>
> You mean these comments?
> https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0
>
> I=E2=80=99ll quote them here:
>
> 0) There is some general awkwardness in text talking about allowed points
> formats, considering that only uncompressed form is now allowed. I don't
> have recommendations about improving text, other than the following:
>
> If no future formats are expected, it feels almost better to recommend
> against inclusion of the Point formats extension, as lack of it means
> uncompressed format anyway.
>
> So this was addressed in draft -16:
>
> OLD:
>
>       Implementations of this document MUST support the
>    uncompressed format for all of their supported curves, and MUST NOT
>    support other formats for curves defined in this specification.  For
>    backwards compatibility purposes, the point format list extension
>    MUST still be included, and contain exactly one value: the
>    uncompressed point format (0).
>
>
> NEW:
>
>       Implementations of this document MUST support the
>    uncompressed format for all of their supported curves, and MUST NOT
>    support other formats for curves defined in this specification.  For
>    backwards compatibility purposes, the point format list extension MAY
>    still be included, and contain exactly one value: the uncompressed
>    point format (0).  RFC 4492 specified that if this extension is
>    missing, it means that only the uncompressed point format is
>    supported, so interoperability with implementations that support the
>    uncompressed format should work with or without the extension.
>
>
>
> 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
> or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
> moved to section 2.
>
>
> The content of the last paragraph was moved to a new section:
>
> 2.4.  Algorithms in Certificate Chains
>
>    This specification does not impose restrictions on signature schemes
>    used anywhere in the certificate chain.  The previous version of this
>    document required the signatures to match, but this restriction,
>    originating in previous TLS versions is lifted here as it had been in
>    RFC 5246.
>
>
>
> 2) In Section 6:
>
>    Server implementations SHOULD support all of the following cipher
>    suites, and client implementations SHOULD support at least one of
>    them:
>
>    o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>    o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>    o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>    o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>
> GCM ciphers are not listed in the table earlier in the same section. They
> are defined in RFC 5289. This document doesn't have any reference to RFC
> 5289 and GCM ciphers are not discussed anywhere else in the document.
>
>
> Seems like I missed this one.

Thanks, let me know when the update is ready.

>
> Yoav
>
>



--=20

Best regards,
Kathleen


From nobody Thu May  4 13:11:59 2017
Return-Path: 
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 185BF126C3D for ; Thu,  4 May 2017 13:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 PvYneebG1vNA for ; Thu,  4 May 2017 13:11:56 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435C0129502 for ; Thu,  4 May 2017 13:11:56 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id D3D28A00491D; Thu,  4 May 2017 13:11:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=I4ZZ7IhC95T31r QGyzIN69QtoE8=; b=fCJHrtKXJyP8A28LryKZtBvsmsDNh+74hFj+RrMHroosF6 5giZFrE9Gdw9vDfX3JD+O1qo/EtJ+uiQabdLYuQ65v94Cc58m4FzlSZXMJv/g7aH 2NAwYyV1qNWSFaKpbdvEiiML5+wmG2qyECtMEKTMCsl7ahiLoFQs+QPXfNETY=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 709C6A00491C; Thu,  4 May 2017 13:11:55 -0700 (PDT)
Date: Thu, 4 May 2017 15:11:52 -0500
From: Nico Williams 
To: Ilari Liusvaara 
Cc: Erik Nygren , "tls@ietf.org" 
Message-ID: <20170504201152.GW10188@localhost>
References:    <20170504200102.GA8268@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170504200102.GA8268@LK-Perkele-V2.elisa-laajakaista.fi>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:11:57 -0000

On Thu, May 04, 2017 at 11:01:02PM +0300, Ilari Liusvaara wrote:
> On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > > both session-cache and strike register styles and the merits of each.
> 
> > Many of the discussions I've been in seem to have concluded that we should
> > always be assuming that 0-RTT data can and will be replayed, and
> > applications and application protocols need to design and use it
> > carefully, accordingly.
> 
> The problem is, the amount of replays is so great even non-idempotency
> that is normally of no consequence becomes a major problem. It isn't one
> or two or three replays, it could be _millions_ of replays.

Adaptive fallback to full handshakes.

> Almost nothing is idempotent enough, unless extremely carefully designed,
> and very few things are.

GETs of static data are.

> There are loads of GET endpoints there that don't have any wild non-
> idempotent behaviour, but still aren't idempotent enough.

Yes, this is true.  But the idea is that one should not enable 0-rtt for
servers that have such behavior.

Nico
-- 


From nobody Thu May  4 13:14:13 2017
Return-Path: 
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 8949D129687 for ; Thu,  4 May 2017 13:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 3wEFl9yE7W6x for ; Thu,  4 May 2017 13:14:10 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F361292F4 for ; Thu,  4 May 2017 13:14:10 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id BFEC5A00491D; Thu,  4 May 2017 13:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XisJPIL6m/xzuK Yw76dwSpGyt6Q=; b=Rr8KmpmF/fIvh+yGePjXqrw6F1/DDp/aIeuEFEWDRWMsQ4 52tLWNoqNllT2buYw8GZ7jOANN+15NDLuHWYGR5LjqnkkkQC2+lD6ZRgmutYUOnL egESTS1OLdm/RfjfC5KYbSRRLQoA7IsC/E9NSiDsBOBzeICgSDBAqQJYpo8U0=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 57FFFA00491B; Thu,  4 May 2017 13:14:09 -0700 (PDT)
Date: Thu, 4 May 2017 15:14:06 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: Erik Nygren , "tls@ietf.org" 
Message-ID: <20170504201406.GX10188@localhost>
References:    <20170504193953.GU10188@localhost> <1fdbaf5f-e425-2c8a-04a1-ac6dae8daa59@akamai.com> <20170504194919.GV10188@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170504194919.GV10188@localhost>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:14:12 -0000

On Thu, May 04, 2017 at 02:49:20PM -0500, Nico Williams wrote:
> On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote:
> > On 05/04/2017 02:39 PM, Nico Williams wrote:
> > > The SHOULD should say that the server-side needs to apply a replay cache
> > > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > > non-idempotent operation.
> > 
> > You seem confused on this key point.  The server commits to accepting or
> > rejecting *all* early data, *before* it can look inside and see what it
> > is (in particular, whether or not it is idempotent).
> 
> Sure, that's fine.  You could run an HTTP server that only accepts
> HEADs, GETs, maybe DELETEs, and accepts 0-rtt and have the client send
> all POSTs and such to a different HTTP server.

Also, a server could accept all sorts of 0-rtt data and at the
application-layer cause extra round-trips and force the client to
re-request.  Not all existing application protocols will support that,
naturally.  For HTTP... maybe a redirect?

Nico
-- 


From nobody Thu May  4 13:21:50 2017
Return-Path: 
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 354E7129789 for ; Thu,  4 May 2017 13:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 w34Pt-jsJ-iR for ; Thu,  4 May 2017 13:21:47 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4686E129B70 for ; Thu,  4 May 2017 13:21:44 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l18so12403777ywh.3 for ; Thu, 04 May 2017 13:21:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M5QDYnwAD2hUuEBPBTLxA4r2xT6jIPSl/2vYF14Lcr0=; b=2LjW6BpMofoVezCFOqbwmfnUZAUufwyG4gGsQoTc/7MwdUl3QssxN+zWMkCG6P/8TO 4iynQyiLAvblzhDT0womoNR4/sZP7Bn7nmG0B3l5LRMAoyLwVzmsHIDeCqKy6QKppGRO BiSuwayxP1QIcXvxkTJ4+HWo0+aQvTRezVMQvXAvzEVYRzVrjHez+Q91ut77yS1um/JS O8QY5tHDO9Wj7lkBicYAYU3I2ygpE03E2xKxYH11jRPOTdccB0wOH0gq/7odhT4FNTQq zBF2+71YyJ4AluEFWAyinnZzXaP9KXqxISscOVbQQ6doBh31/r0B+izJCnyqKYIffKxX mNhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M5QDYnwAD2hUuEBPBTLxA4r2xT6jIPSl/2vYF14Lcr0=; b=hMQ9ZsG/zIddyrB97h/CmajQc1JLHKuM927vyPKXULkxYY9I5LGDgayitgd+hq4HyK 5v/+sC6Ss7HhK4D0m0IK9HwrRUEtkSkjqZCEFXpgv7GXQLGHHNzohDD1qru6tgGpB4vp yaLI0Dl1rfOKJu5mRoGeax4r6ZqzAHhvO/pldflzk9Vip33zA49fZE5ByJn7bbZNvHT0 Lk2h5EhivTSlabRksB4qJYxT7hV5RYRHgr0scwLf1Ixj50yksRGT0CBLurhRoUMMi+BK 7Hyr2OM+8cGZnufYT+tPOEWuOsURKphjpOO42jXfaE8Kc8Z+vdn8F1HiAi20jB8viToy DLAw==
X-Gm-Message-State: AN3rC/5EmfmDZ5Kniee3HNZ0UypdLoR9FnVjAc60KEh8FSO3UfsbgY/G 1VJp6TeXzkbko7EevhxktMhht1KD+w==
X-Received: by 10.129.157.142 with SMTP id u136mr8008067ywg.323.1493929303554;  Thu, 04 May 2017 13:21:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 13:21:43 -0700 (PDT)
In-Reply-To: <20170504193953.GU10188@localhost>
References:    <20170504193953.GU10188@localhost>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 13:21:43 -0700
Message-ID: 
To: Nico Williams 
Cc: Erik Nygren , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c0b68aa7565c8054eb88549
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:21:48 -0000

--94eb2c0b68aa7565c8054eb88549
Content-Type: text/plain; charset=UTF-8

On Thu, May 4, 2017 at 12:39 PM, Nico Williams 
wrote:

> The SHOULD should say that the server-side needs to apply a replay cache
> OR fallback onto a full exchange when the 0-rtt data payload involves a
> non-idempotent operation.
>

I don't mean to be dismissive with this but TLS stands for "Transport Layer
Security". The transport layer just isn't aware of what the operations are,
and whether then can be idempotent (99% of the time, the answer is "no").
Only the application can tell, but this violation of layers is what leads
to so many problems. I don't think it's workable.


-- 
Colm

--94eb2c0b68aa7565c8054eb88549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 12:39 PM, Nico Williams <nico@cryptonector.=
com> wrote:
The SHOULD shou=
ld say that the server-side needs to apply a replay cache

OR fallback onto a full exchange when the 0-rtt data payload involves a

non-idempotent operation.

I don't m=
ean to be dismissive with this but TLS stands for "Transport Layer Sec=
urity". The transport layer just isn't aware of what the operation=
s are, and whether then can be idempotent (99% of the time, the answer is &=
quot;no"). Only the application can tell, but this violation of layers=
 is what leads to so many problems. I don't think it's workable.=C2=
=A0


-- 
Colm




--94eb2c0b68aa7565c8054eb88549--


From nobody Thu May  4 13:24:36 2017
Return-Path: 
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 6D7F6126E64 for ; Thu,  4 May 2017 13:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 EqNVv-lxSK6Y for ; Thu,  4 May 2017 13:24:32 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87E6126BF0 for ; Thu,  4 May 2017 13:24:32 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id j17so6472961ybj.0 for ; Thu, 04 May 2017 13:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JdbXZ+ThKPEX41Eob92wCgRKk6gg/6a5Wuzg+v58hWk=; b=T+pz2GMI4UQtmZh3zROrq1mAwVHEa4Xx3yx7YVg8EEqF41DUQ1ZeCUAES2vt7A4VXJ c5GK90aGZGCmN+SXsy5pi/akxm9krhCgtqqg8CU1r4WeZeDRkiqnL9FSHr9/oJdjJr6p Gx72gwnWuoDVKFVUtWC1nF0oNIzLCabFMq5y+4OxSmNYFR+BD31ZTM4F5+yG6OMwAF4C OE8cBRAbRC2c3rc725vRD3IQBwSUvJ6p8cD7ohwpN7lTZ+maFcEotXNkvAppSp+nSaML 6C0zGj1DpwCnDhFMhFczJDbW9GtgN534VSHsV3nuHZEJTRUm0Z/xiujREo7TrMaUrxUo W52w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JdbXZ+ThKPEX41Eob92wCgRKk6gg/6a5Wuzg+v58hWk=; b=DL6UbU3sYEOZzfVR7wMjmr0GQMROPeNaydRtfXF2uri0H4yMPCN0YObUa9tjkhJBkA vSSCUEm0E+XYhEqZ8vuaJL0E67o/3VQDuZXux0SiMa1iIjaklF0A6Ze6km4rMzgOXhVw AuPTQHzlc1dMC/1+vbrFkZC37F3gTdh2GBeMvIiWjY9ZB8PQ//WdnOgIhlQbvf6Xd43C G0b/luzVPTTrLCcSnGWfkJ4ZFM151HV6XpnQSOy6xl+HeB5eDGFKtCSSRoJB3nmYmxvw HYcfySDMFUXOeWGIZ3kFUaAN4R5infMpUnQ0qI6wamXvEKKSin+5cRxPp8FUpYiV3FkB HVtQ==
X-Gm-Message-State: AN3rC/5DIX9gJevcLOQ7fYq3ngSlzZKqcbWU6w96LduItHcasZTK80sx +E7FWXXUGKZq7bCPBeALj59RM1xKmL+S
X-Received: by 10.37.203.78 with SMTP id b75mr34983429ybg.19.1493929471891; Thu, 04 May 2017 13:24:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 13:24:30 -0700 (PDT)
In-Reply-To: 
References:   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 13:24:30 -0700
Message-ID: 
To: Erik Nygren 
Cc: Eric Rescorla , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c05b1d27dff6f054eb88fdc
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:24:34 -0000

--94eb2c05b1d27dff6f054eb88fdc
Content-Type: text/plain; charset=UTF-8

On Thu, May 4, 2017 at 12:12 PM, Erik Nygren  wrote:

> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
>
>>
>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>
> I don't believe this is technically viable for the large-scale server
> operators most interested in 0-RTT.
>

I think it is (and work at one of the biggest) ... but if even it weren't,
that would just imply that we can't have 0-RTT at all, not that it's ok to
ship an insecure version.

-- 
Colm

--94eb2c05b1d27dff6f054eb88fdc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 12:12 PM, Erik Nygren <erik+ietf@nygren.org<=
/a>> wrote:
On Wed=
, May 3, 2017 at 11:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:

1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
both session-cache and strike register styles and the merits of ea=
ch.

I don't believe =
this is technically viable for the large-scale server operators most intere=
sted in 0-RTT.

I th=
ink it is (and work at one of the biggest) ... but if even it weren't, =
that would just imply that we can't have 0-RTT at all, not that it'=
s ok to ship an insecure version.

-- 
Colm




--94eb2c05b1d27dff6f054eb88fdc--


From nobody Thu May  4 13:26:58 2017
Return-Path: 
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 9E53F1270A3 for ; Thu,  4 May 2017 13:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 dSFu8GJn6r1Z for ; Thu,  4 May 2017 13:26:55 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE25126BF0 for ; Thu,  4 May 2017 13:26:55 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 09C35A00491C; Thu,  4 May 2017 13:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=/3uL9atTJkt8jiTwQ3nQsRu8oCA=; b=Arwc1HrbR/p 1KJnxjqmA7z2iF3dbgw/6HeULrlqKs9hRV8yzMIE/AwpB4XyVuX/0jk7E8qWznSm WYYP2NysZ7lXsPuj5FFJR1a3FdWaIoQWugNvj7K4+7jNs4TVC+Q8u5NMd5FbNMxs n0sgv04MMb1xbgBUr2LBHNP5dRHOIt8k=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9CA71A00491B; Thu,  4 May 2017 13:26:54 -0700 (PDT)
Date: Thu, 4 May 2017 15:26:52 -0500
From: Nico Williams 
To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= 
Cc: Erik Nygren , "tls@ietf.org" 
Message-ID: <20170504202651.GY10188@localhost>
References:    <20170504193953.GU10188@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 20:26:57 -0000

On Thu, May 04, 2017 at 01:21:43PM -0700, Colm MacC=E1rthaigh wrote:
> On Thu, May 4, 2017 at 12:39 PM, Nico Williams 
> wrote:
> > The SHOULD should say that the server-side needs to apply a replay ca=
che
> > OR fallback onto a full exchange when the 0-rtt data payload involves=
 a
> > non-idempotent operation.
>=20
> I don't mean to be dismissive with this but TLS stands for "Transport L=
ayer
> Security". The transport layer just isn't aware of what the operations =
are,
> and whether then can be idempotent (99% of the time, the answer is "no"=
).
> Only the application can tell, but this violation of layers is what lea=
ds
> to so many problems. I don't think it's workable.

I don't mean to be dismissive, but it doesn't matter what "TLS" stands
for.  It does what we make it do via Standards Action at the IETF.  We
follow our rules for everything to do with development of Internet
Standards and publication of Experimental, Informational and BCP RFCs.

We have a process.  If you don't like what we're doing, you can voice
your opinion.  If you don't like the outcome of consensus calls and/or
IESG decisions, you can appeal those.

Thanks,

Nico
--=20


From nobody Thu May  4 14:14:04 2017
Return-Path: 
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 460A2126DC2 for ; Thu,  4 May 2017 14:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 icpw53XWhPHz for ; Thu,  4 May 2017 14:14:01 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A7D126E64 for ; Thu,  4 May 2017 14:14:01 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id 8so6754763ybw.1 for ; Thu, 04 May 2017 14:14:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vNe7Kc04+iyoc/NcRKimLum+JLDYJQVxfUrqlZHf1F8=; b=buJNIYqXbRAidwsUbh9oS8DgZaSYBs4ASuDDI20Z5pm27u0oNw7vG3nJlHptGfkrqS u5J5bjwOKsM0Apc78WlOXT4DwSKdQ82Vw67T0Aw8m7cH4/G3FLFom84IcwN6Ue7lff53 gB+2zET0PuMWoqiPvP38QwnIL+tA0qUf9cl/dUgLUHYcY0Ftvgmg4FuY9Omh5SP7cmsa 1qVkN6z5DMQ299I0fexIy3Wux2YgyoZzefhNGptftyXRKBpMC12ubTPaRByb/0H08DYj gwZnmoV9EFliMDFbfmEFpSXUf1Er5PfCAHPwF3acHZFIqlttYKGtC9BB8gmd+wYw+9MN Figw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vNe7Kc04+iyoc/NcRKimLum+JLDYJQVxfUrqlZHf1F8=; b=LFmI8lw5Q77uFLCnPUFVR9Eenvk76NW73YAMbiph9r83PiSPfzbv3vXa5is6JLkQBP cia2dV36Pd7VFydYch9fpNH12hOHfloB6Y5M+5/4bTKmQSzXBC+znUI0iutIQO2Ef8i1 vQSVJV2ru/9PDn39D1p/hI2mwPsc4b/VZPMwpfPLBgjwVZ7odlJJSt9/NVgFvHxUuB+H x2MZvBgwxzDsaRFmKCwAgHNRf499SXRxM+5q4k7YNLCX4pvY85qm5WNCe3mbgdv2VMNC HO2RaJRMZ6c2zzpr5DTozpzzgNskBdPmd5UBeRCk6+xoIbjPsOLBDt+rms8uVzdx8pTS Y6sw==
X-Gm-Message-State: AN3rC/7fsxi2aPy9uTLIHVC5pBgLmLGB4VLtXvZz+wMFzu4Y6M5yUaIy 4/vKOXH8M0fmE+ZjOJhNTf2gmdMS/4gKPtU=
X-Received: by 10.37.174.24 with SMTP id a24mr36492941ybj.50.1493932440282; Thu, 04 May 2017 14:14:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 4 May 2017 14:13:19 -0700 (PDT)
In-Reply-To: 
References:    
From: Eric Rescorla 
Date: Thu, 4 May 2017 14:13:19 -0700
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045da3586bfdc2054eb94035
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 21:14:03 -0000

--f403045da3586bfdc2054eb94035
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As promised:
https://github.com/tlswg/tls13-spec/pull/1005

Note: I may have to do a little post-landing cleanup, but I wanted to get
people's senses of the text ASAP.

Comments welcome.
-Ekr


On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla  wrote:

>
>
> On Wed, May 3, 2017 at 8:20 PM, Colm MacC=C3=A1rthaigh 
> wrote:
>
>>
>>
>> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla  wrote:
>>
>>> I made some proposals yesterday
>>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>>>
>>> Specifically:
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the merits of each.
>>>
>>> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>>>
>>> 3. Adopt PR#448 (or some variant) so that session-id style
>>> implementations
>>> provide PFS.
>>>
>>> 4. I would add to this that we recommend that proxy/CDN implementations
>>> signal which data is 0-RTT and which is 1-RTT to the back-end (this was
>>> in
>>> Colm's original message).
>>>
>>
>> This all sounds great to me. I'm not sure that we need (4.) if we have
>> (1.).  I think with (1.) - recombobulating to a single stream might even=
 be
>> best overall, to reduce application complexity, and it seems to be what
>> most implementors are actually doing.
>>
>> I know that leaves the DKG attack, but from a client and servers
>> perspective that attack is basically identical to a server timeout, and
>> it's something that systems likely have some fault tolerance around. It'=
s
>> not /new/ broken-ness.
>>
>
> Heh. Always happy to do less writing.
>
> Thanks,
> -Ekr
>
>
>>
>>
>>> Based on Colm's response, I think these largely hits the points he made
>>> in his original message.
>>>
>>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>>> What would be most helpful to me as Editor would be if people could
>>> review
>>> these PRs and/or suggest other specific changes that we should make
>>> to the document.
>>>
>>
>> Will do! Many thanks.
>>
>> --
>> Colm
>>
>
>

--f403045da3586bfdc2054eb94035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


As promised:
https://github.com/tlswg/tls13-spec/pull/1005

Note: I may have to do a little post-landing cleanup, =
but I wanted to get
people's senses of the text ASAP.

Comments welcome.
-Ekr

=


On Wed, May=
 3, 2017 at 8:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:

<=
br>
On Wed, May 3, 2017 at 8:20 =
PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:


On Wed, May 3, 2017 at 8:13 PM, Eric =
Rescorla <ekr@rtfm.com> wrote:
I made some proposals yesterday=C2=A0
(https:=
//www.ietf.org/mail-archive/web/tls/current/msg23088.html).

Specifically:
1. A SHOULD-level requireme=
nt for server-side 0-RTT defense, explaining
both session-cache a=
nd strike register styles and the merits of each.

=
2. Document 0-RTT greasing in draft-ietf-tls-grease

3. Adopt PR#448 (or some variant) so that session-id style implementa=
tions
provide PFS.

4. I would add to thi=
s that we recommend that proxy/CDN implementations
signal which d=
ata is 0-RTT and which is 1-RTT to the back-end (this was in
Colm=
's original message).

This all sounds great to me. I'm not sure that we need (4.) if we hav=
e (1.).=C2=A0 I think with (1.) - recombobulating to a single stream might =
even be best overall, to reduce application complexity, and it seems to be =
what most implementors are actually doing. =C2=A0

=
I know that leaves the DKG attack, but from a client and servers perspectiv=
e that attack is basically identical to a server timeout, and it's some=
thing that systems likely have some fault tolerance around. It's not /n=
ew/ broken-ness.=C2=A0

<=
/span>
Heh. Always happy to do less writing.

T=
hanks,
-Ekr
=C2=A0
=C2=A0
=
Based on Colm's response, I think these largely hits the points he made=

in his original message.

There's al=
ready a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
What would be most helpful to me as Editor would be if people could revi=
ew
these PRs and/or suggest other specific changes that we should=
 make
to the document.

Will do! Many thanks.=C2=A0

-- 
Colm










--f403045da3586bfdc2054eb94035--


From nobody Thu May  4 14:28:11 2017
Return-Path: 
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 1B9A7129502 for ; Thu,  4 May 2017 14:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level: 
X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=i5SITW9i; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Wi34fq3q
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 tOJQaIL_DDQJ for ; Thu,  4 May 2017 14:28:06 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F151F120227 for ; Thu,  4 May 2017 14:28:02 -0700 (PDT)
Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v44LLbC5002692; Thu, 4 May 2017 14:28:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=td62ue6J0SwwlKoF8CX8Nu1535C/2Wji8UkjmLR5g4o=; b=i5SITW9ixw7VqCDxUgbE/mftR+gEbuF+CPG+GepkUCAXu1c61KB5RnUdXlKWw+QIX7M4 CTyDc6HCbQWwbZQ/EGx3QM9/WgSYXJugTDGhPyJ/y7QfC/A0ITcQ5rj9zoPjQfrXfXr5 3GLrNbrnBK+ltoKrFaCrwRFoTceGqHiFlzw= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2a87hw17ff-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 04 May 2017 14:28:02 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 4 May 2017 17:28:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=td62ue6J0SwwlKoF8CX8Nu1535C/2Wji8UkjmLR5g4o=; b=Wi34fq3qAJWdwPRLZAoYDwrv/H2RGsTmMvBPvTFQFIdvsOCE08sszi/h1t2DYDihOLcxYIVWhFJGNN1H2sq6mGusI9wrWcHYJr53mpai8iUYkTWqkR1HvwJU+6DCzTRKtf/y8bkcVIh861qOW7fK5/jLctfFb6A8/ScqSs+RgWI=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 21:27:41 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.1061.022; Thu, 4 May 2017 21:27:41 +0000
From: Kyle Nekritz 
To: Eric Rescorla , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NWfzhsEfLgEUy3mG3N+R1DLqHjghwAgADwDPA=
Date: Thu, 4 May 2017 21:27:40 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=fb.com;
x-originating-ip: [2620:10d:c091:200::2:713]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 7:8WEyvmxt2v4Ya/ize5sYdnD8KgGgzmSSPSUrTSA9FTZMAfxpOSaNnQ63xbfleFZKZAexoApnrES/bwfbUMNnE2IpkNoA5LQYvS6pNbqIXdSwjprOc6y/ZO+W2Dm2edN55qSL7wiuKtGrMpJgeQuDgQjynZmYVp0ikoeHE9650qgdBa0wUbP/tXEtVyYGfXsmCSTIqcmCuNFISBadfdPjkX3eDL8cDNsIKAHIAVSTuWTN4fL1apWditu6mQghw7ZD33+EtG0nnWXEs+sfN54uIBLw4yc9S0Rux0nLN8wmYSoaUc6orBxKw8oovYVOAeKs2DeMhd1igB9opcxnKYdzzA==; 20:lgXoAxRWfX7nhKU+3T/06jKdh1lhU/3lgOnLXerrrMzvaaPIgeDT6Pqo/Kn1mAug2QJlWVLpteMNsK+X+6213Q6dNfDXR6Z7lv8TM7fFffrgvgwRsL8XMOzjHZikmxX7xBAYeUpo9508vPcKESVY52SCiNO4XGBnzbHR4XNqpOQ=
x-ms-office365-filtering-correlation-id: 22953d3b-4a0b-4b07-a784-08d493346555
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1182; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(166708455590820)(192374486261705)(21748063052155)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148); SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182; 
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39450400003)(39840400002)(24454002)(377454003)(2906002)(77096006)(3660700001)(53546009)(3280700002)(25786009)(54356999)(86362001)(76176999)(50986999)(19609705001)(4326008)(38730400002)(189998001)(6246003)(6506006)(55016002)(99286003)(33656002)(7110500001)(6306002)(6436002)(606005)(53936002)(54896002)(9686003)(7696004)(7906003)(236005)(74316002)(2950100002)(2900100001)(8936002)(7736002)(102836003)(5660300001)(6116002)(15650500001)(122556002)(81166006)(478600001)(2420400007)(8676002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB11825419AF296AE7EC26F3BDAFEA0MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 21:27:41.0654 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_14:, , signatures=0
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 21:28:10 -0000

--_000_MWHPR15MB11825419AF296AE7EC26F3BDAFEA0MWHPR15MB1182namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiAxLiBBIFNIT1VMRC1sZXZlbCByZXF1aXJlbWVudCBmb3Igc2VydmVyLXNpZGUgMC1SVFQgZGVm
ZW5zZSwgZXhwbGFpbmluZyBib3RoIHNlc3Npb24tY2FjaGUgYW5kIHN0cmlrZSByZWdpc3RlciBz
dHlsZXMgYW5kIHRoZSBtZXJpdHMgb2YgZWFjaC4NCg0KRmlyc3QsIGEgcG9pbnQgb2YgY2xhcmlm
aWNhdGlvbiwgSSB0aGluayB0d28gaXNzdWVzIGhhdmUgYmVlbiBjb25mbGF0ZWQgaW4gdGhpcyBs
b25nIHRocmVhZDoNCjEpIFNlcnZlcnMgcmVqZWN0aW5nIHJlcGxheWVkIDAtUlRUIGRhdGEgKHVz
aW5nIGEgc2luZ2xlIHVzZSBzZXNzaW9uIGNhY2hlL3N0cmlrZSByZWdpc3Rlci9yZXBsYXkgY2Fj
aGUvc29tZSBvdGhlciBtZXRob2QpDQoNClRoZXJlIGFyZSBkZWZpbml0ZWx5IGNhc2VzIChpLmUu
IGFwcGxpY2F0aW9uIHByb2ZpbGVzKSB3aGVyZSB0aGlzIHNob3VsZCBiZSBkb25lLiBJIHRoaW5r
IGEgZ2VuZXJhbCBjYXNlIEhUVFBTIHNlcnZlciBpcyBvbmUuIEJ1dCBJIGRvbuKAmXQgdGhpbmsg
dGhpcyBpcyBzdHJpY3RseSBuZWNlc3NhcnkgYWNyb3NzIHRoZSBib2FyZCAoZm9yIGV2ZXJ5IGFw
cGxpY2F0aW9uIHVzaW5nIDAtUlRUIGF0IGFsbCkuIEROUyB3YXMgYnJvdWdodCB1cCBlYXJsaWVy
IGluIHRoaXMgdGhyZWFkIGFzIGFuIGV4YW1wbGUgb2YgYSBwcm90b2NvbCB0aGF0IGlzIGxpa2Vs
eSBxdWl0ZSB3b3JrYWJsZSB3aXRob3V0IGV4dHJhIG1lYXN1cmVzIHRvIHByZXZlbnQgcmVwbGF5
Lg0KDQpXZSBhbHJlYWR5IHN0YXRlIOKAnFByb3RvY29scyBNVVNUIE5PVCB1c2UgMC1SVFQgZGF0
YSB3aXRob3V0IGEgcHJvZmlsZSB0aGF0IGRlZmluZXMgaXRzIHVzZS7igJ0uIFdlIGNvdWxkIGFs
c28gZGVzY3JpYmUgbWV0aG9kcyB0aGF0IG1heSBiZSB1c2VkIHRvIHByb3ZpZGUgZnVydGhlciBy
ZXBsYXkgcHJvdGVjdGlvbi4gQnV0IEkgZG9u4oCZdCB0aGluayBpdOKAmXMgYXBwcm9wcmlhdGUg
dG8gbWFrZSBhIGJsYW5rZXQgcmVxdWlyZW1lbnQgdGhhdCAqYWxsKiBhcHBsaWNhdGlvbiBwcm90
b2NvbHMgc2hvdWxkIHJlcXVpcmUgaXQuDQoNCkkgYWxzbyBjb25zaWRlciBpdCBxdWl0ZSBtaXNs
ZWFkaW5nIHRvIHNheSBUTFMgMS4zIGlzIGluc2VjdXJlIHdpdGhvdXQgc3VjaCBhIHJlY29tbWVu
ZGF0aW9uLiBVc2VzIG9mIFRMUyBjYW4gYmUgaW5zZWN1cmUsIHRoYXQgZG9lcyBub3QgbWVhbiB0
aGUgcHJvdG9jb2wgaXRzZWxmIGlzLiBJdOKAmXMgaW5zZWN1cmUgdG8gdXNlIFRMUyB3aXRob3V0
IHByb3Blcmx5IGF1dGhlbnRpY2F0aW5nIHRoZSBzZXJ2ZXIuIFNvbWUgdXNlcnMgb2YgVExTIGRv
IG5vdCBkbyB0aGlzIGNvcnJlY3RseS4gSeKAmWQgYWN0dWFsbHkgYXJndWUgdGhhdCBpdCBpcyBl
YXNpZXIgdG8gbWVzcyB0aGlzIHVwIHRoYW4gaXQgaXMgdG8gbWVzcyB1cCBhIDAtUlRUIGRlcGxv
eW1lbnQgKGFuZCBpdCBjYW4gcmVzdWx0IGluIHdvcnNlIGNvbnNlcXVlbmNlcykuIFRoYXQgZG9l
c27igJl0IG1lYW4gd2Ugc2hvdWxkIHJlcXVpcmUgYSBwYXJ0aWN1bGFyIG1ldGhvZCBvZiBhdXRo
ZW50aWNhdGlvbiwgZm9yIGFsbCB1c2VzIG9mIFRMUy4NCg0KMikgUHJldmVudGluZyBjbGllbnRz
IGZyb20gc2VuZGluZyAwLVJUVCBkYXRhIG11bHRpcGxlIHRpbWVzIChvbiBzZXBhcmF0ZSBjb25u
ZWN0aW9ucykgdXNpbmcgdGhlIHNhbWUgUFNLIChmb3IgZm9yd2FyZCBzZWNyZWN5IHJlYXNvbnMp
DQoNCkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYWxsb3dlZC4gT3RoZXJ3aXNlLCBjbGllbnRzIHdp
bGwgbm90IGJlIGFibGUgdG8gcmV0cnkgMC1SVFQgcmVxdWVzdHMgdGhhdCBmYWlsIGR1ZSB0byBh
biB1bmtub3duIG5ldHdvcmsgZXJyb3IgcHJpb3IgdG8gcmVjZWl2aW5nIGEgTlNUIChpZiB0aGV5
IGFyZSBvdXQgb2YgY2FjaGVkIFBTS3MpLiBJ4oCZZCBleHBlY3QgdGhlIG5lZWQgZm9yIHRoZXNl
IHJldHJpZXMgdG8gYmUgbGFyZ2VyIHdpdGggMC1SVFQgZGF0YSwgcGFydGljdWxhcmx5IHdoZW4g
MC1SVFQgZGF0YSBpcyBzZW50IHdpdGhvdXQgZXZlbiBhIHRyYW5zcG9ydCByb3VuZHRyaXAgKGlu
IHRoZSBjYXNlIG9mIFRGTyBvciBRVUlDKS4gU2VydmVycyBhcmUgZGVmaW5pdGVseSBub3QgcmVx
dWlyZWQgdG8gYWNjZXB0IG11bHRpcGxlIDAtUlRUIGNvbm5lY3Rpb25zIHVzaW5nIHRoZSBzYW1l
IFBTSywgYnV0IEkgZG9u4oCZdCB0aGluayBjbGllbnRzIHNob3VsZCBiZSBiYW5uZWQgZnJvbSBh
dHRlbXB0aW5nLg0KDQo+IDIuIERvY3VtZW50IDAtUlRUIGdyZWFzaW5nIGluIGRyYWZ0LWlldGYt
dGxzLWdyZWFzZQ0KDQpJ4oCZbSBub3QgY29udmluY2VkIHRoaXMgaXMgYWN0dWFsbHkgYSBwcm9k
dWN0aXZlIHRoaW5nIHRvIGRvIGluIHRoZSBzYW1lIG1hbm5lciBhcyBncmVhc2UsIHBhcnRpY3Vs
YXJseSBpZiBzZXJ2ZXJzIGFyZSB0YWtpbmcgYW50aS1yZXBsYXkgbWVhc3VyZXMgKGluIHdoaWNo
IGNhc2UgSSBzZWUgdGhpcyBiZWluZyB1c2VmdWwgaW4gYSBUTFMgdGVzdGluZyB0b29sIGxpa2Ug
c3NsbGFicywgYnV0IG5vdCBpbiBhY3R1YWwgZGVwbG95bWVudHMpLiBJIHRoaW5rIHdlIGNhbiBs
ZWF2ZSB0aGlzIGRpc2N1c3Npb24gZm9yIGxhdGVyIHRob3VnaC4NCg0KPiAzLiBBZG9wdCBQUiM0
NDggKG9yIHNvbWUgdmFyaWFudCkgc28gdGhhdCBzZXNzaW9uLWlkIHN0eWxlIGltcGxlbWVudGF0
aW9ucyBwcm92aWRlIFBGUy4NCg0KU291bmRzIGdvb2QgdG8gbWUuDQoNCj4gNC4gSSB3b3VsZCBh
ZGQgdG8gdGhpcyB0aGF0IHdlIHJlY29tbWVuZCB0aGF0IHByb3h5L0NETiBpbXBsZW1lbnRhdGlv
bnMgc2lnbmFsIHdoaWNoIGRhdGEgaXMgMC1SVFQgYW5kIHdoaWNoIGlzIDEtUlRUIHRvIHRoZSBi
YWNrLWVuZCAodGhpcyB3YXMgaW4gQ29sbSdzIG9yaWdpbmFsIG1lc3NhZ2UpLg0KDQpJ4oCZbSBu
b3Qgc3VyZSB0aGF0IHRoZSBUTFMgMS4zIHNwZWMgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIG1ha2Ug
cmVjb21tZW5kYXRpb25zIGZvciB0aGlzLiBJIGNhbiBzZWUgc2V2ZXJhbCByZWFzb25hYmxlIGFw
cHJvYWNoZXMgaGVyZSwgZm9yIGV4YW1wbGU6DQotIEFkZGluZyBzb21lIGtpbmQgb2YgYXBwbGlj
YXRpb24gbGV2ZWwgYW5ub3RhdGlvbiAoZm9yIGV4YW1wbGUgYW4gSFRUUCBoZWFkZXIpDQotIFJv
YnVzdGx5IHByZXZlbnRpbmcgcmVwbGF5IG9uIHRoZSAwLVJUVCBob3ANCi0gU2VuZGluZyBwcm94
aWVkIGVhcmx5IGRhdGEgd2l0aCBhIGRpZmZlcmVudCBUTFMgQ29udGVudFR5cGUsIGV0Yy4NCkkg
ZG9u4oCZdCBzZWUgYSBuZWVkIHRvIHNwZWNpZmljYWxseSBlbmRvcnNlIGFueSBwYXJ0aWN1bGFy
IG1ldGhvZCBoZXJlLg0KDQoNClRoZXJlIHdhcyBhbHNvIGEgcG9pbnQgYnJvdWdodCB1cCBhYm91
dCB0aGUgdXNlIG9mIHRpY2tldF9hZ2Ugd2l0aG91dCAwLVJUVC4gSeKAmW0gbm90IGF3YXJlIG9m
IGFueSB1c2UgZm9yIHRpY2tldF9hZ2Ugb3RoZXIgdGhhbiAwLVJUVCByZXBsYXkgcHJvdGVjdGlv
bi4gSSBiZWxpZXZlIHRoYXQgdGlja2V0X2FnZSBpcyBzZW50IHdpdGggYWxsIFBTS3MgbW9zdGx5
IG91dCBvZiBjb252ZW5pZW5jZS9jb25zaXN0ZW5jeS4gSSBkb27igJl0IHJlYWxseSBoYXZlIGFu
IG9iamVjdGlvbiB0byB0aGUgY3VycmVudCBtZXRob2QsIGJ1dCBJIGFsc28gd291bGRu4oCZdCBi
ZSBvcHBvc2VkIHRvIG1vdmluZyB0aGUgdGlja2V0IGFnZSB0byB0aGUgZWFybHkgZGF0YSBleHRl
bnNpb24sIHNvIHRoYXQgaXQgaXMgb25seSBzZW50IGFsb25nIHdpdGggMC1SVFQgZGF0YS4NCkl0
IGFsc28gc2VlbXMgYSBsaXR0bGUgdW5kZXItc3BlY2lmaWVkIHdoYXQgaW1wbGVtZW50YXRpb25z
IHVuYWJsZSB0byBjb21wdXRlIGEgcmVhc29uYWJsZSB0aWNrZXQgYWdlIHNob3VsZCBzZW5kIChm
b3IgZXhhbXBsZSBpbiB0aGUgY2FzZSBvZiBhIGRldmljZSB3aXRob3V0IGEgcmVhbCB0aW1lIGNs
b2NrLCBvciB3aXRoIGFuIGV4dGVybmFsIFBTSykuDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogV2VkbmVz
ZGF5LCBNYXkgMywgMjAxNyAxMToxMyBQTQ0KVG86IENvbG0gTWFjQ8OhcnRoYWlnaCA8Y29sbUBh
bGxjb3N0cy5uZXQ+DQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gU2VjdXJp
dHkgcmV2aWV3IG9mIFRMUzEuMyAwLVJUVA0KDQpbRGVsaWJlcmF0ZWx5IHJlc3BvbmRpbmcgdG8g
dGhlIE9QIHJhdGhlciB0aGFuIHRvIGFueW9uZSBpbiBwYXJ0aWN1bGFyXQ0KDQpIaSBmb2xrcywN
Cg0KSSdtIHNlZWluZyBhIGxvdCBvZiBiYWNrIGFuZCBmb3J0aCBhYm91dCBnZW5lcmFsIHBoaWxv
c29waHkgYW5kIHRoZQ0Kd2lzZG9tIG9mIDAtUlRUIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVz
ZWZ1bCBpZiB3ZSBmb2N1c2VkIG9uIHdoYXQNCmNoYW5nZXMsIGlmIGFueSwgd2UgbmVlZCB0byBt
YWtlIHRvIHRoZSBkcmFmdC4NCg0KSSBtYWRlIHNvbWUgcHJvcG9zYWxzIHllc3RlcmRheQ0KKGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMjMwODgu
aHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfdGxzX2N1cnJlbnRfbXNnMjMwODguaHRt
bCZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1sMmo0QmprTzBMYzN1NENIMno3
alB3Jm09XzJCRUNmOU9mVzFyMWFSV3JMX3BTYlFlS01zaHlPbTJOSVZXRjRHR0JJMCZzPVhnSGJV
d1Q2dXBBc09pbjRUNlA4ZVBzOGkwWkZzbkQtX0JOdnVlZXE4M0UmZT0+KS4NCg0KU3BlY2lmaWNh
bGx5Og0KMS4gQSBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1lbnQgZm9yIHNlcnZlci1zaWRlIDAtUlRU
IGRlZmVuc2UsIGV4cGxhaW5pbmcNCmJvdGggc2Vzc2lvbi1jYWNoZSBhbmQgc3RyaWtlIHJlZ2lz
dGVyIHN0eWxlcyBhbmQgdGhlIG1lcml0cyBvZiBlYWNoLg0KDQoyLiBEb2N1bWVudCAwLVJUVCBn
cmVhc2luZyBpbiBkcmFmdC1pZXRmLXRscy1ncmVhc2UNCg0KMy4gQWRvcHQgUFIjNDQ4IChvciBz
b21lIHZhcmlhbnQpIHNvIHRoYXQgc2Vzc2lvbi1pZCBzdHlsZSBpbXBsZW1lbnRhdGlvbnMNCnBy
b3ZpZGUgUEZTLg0KDQo0LiBJIHdvdWxkIGFkZCB0byB0aGlzIHRoYXQgd2UgcmVjb21tZW5kIHRo
YXQgcHJveHkvQ0ROIGltcGxlbWVudGF0aW9ucw0Kc2lnbmFsIHdoaWNoIGRhdGEgaXMgMC1SVFQg
YW5kIHdoaWNoIGlzIDEtUlRUIHRvIHRoZSBiYWNrLWVuZCAodGhpcyB3YXMgaW4NCkNvbG0ncyBv
cmlnaW5hbCBtZXNzYWdlKS4NCg0KQmFzZWQgb24gQ29sbSdzIHJlc3BvbnNlLCBJIHRoaW5rIHRo
ZXNlIGxhcmdlbHkgaGl0cyB0aGUgcG9pbnRzIGhlIG1hZGUNCmluIGhpcyBvcmlnaW5hbCBtZXNz
YWdlLg0KDQpUaGVyZSdzIGFscmVhZHkgYSBQUiBmb3IgIzMgYW5kIEknbGwgaGF2ZSBQUnMgZm9y
ICMxIGFuZCAjNCB0b21vcnJvdy4NCldoYXQgd291bGQgYmUgbW9zdCBoZWxwZnVsIHRvIG1lIGFz
IEVkaXRvciB3b3VsZCBiZSBpZiBwZW9wbGUgY291bGQgcmV2aWV3DQp0aGVzZSBQUnMgYW5kL29y
IHN1Z2dlc3Qgb3RoZXIgc3BlY2lmaWMgY2hhbmdlcyB0aGF0IHdlIHNob3VsZCBtYWtlDQp0byB0
aGUgZG9jdW1lbnQuDQoNClRoYW5rcywNCi1Fa3INCg0KDQoNCg0KT24gVHVlLCBNYXkgMiwgMjAx
NyBhdCA3OjQ0IEFNLCBDb2xtIE1hY0PDoXJ0aGFpZ2ggPGNvbG1AYWxsY29zdHMubmV0PG1haWx0
bzpjb2xtQGFsbGNvc3RzLm5ldD4+IHdyb3RlOg0KT24gU3VuZGF5IGF0IHRoZSBUTFM6RElWIHdv
cmtzaG9wIEkgcHJlc2VudGVkIGEgc3VtbWFyeSBvZiBmaW5kaW5ncyBvZiBhIHNlY3VyaXR5IHJl
dmlldyB3ZSBkaWQgb24gVExTMS4zIDAtUlRULCBhcyBwYXJ0IG9mIGltcGxlbWVudGluZyAxLjMg
aW4gczJuLiBUaGFua3MgdG8gZmVlZGJhY2sgaW4gdGhlIHJvb20gSSd2ZSBub3cgdGlnaHRlbmVk
IHVwIHRoZSBmaW5kaW5ncyBmcm9tIHRoZSByZXZpZXcgYW5kIHBvc3RlZCB0aGVtIGFzIGFuIGlz
c3VlIG9uIHRoZSBkcmFmdCBHaXRIdWIgcmVwbzoNCg0KaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dn
L3RsczEzLXNwZWMvaXNzdWVzLzEwMDENCg0KSSdsbCBzdW1tYXJpemUgdGhlIHN1bW1hcnk6IE5h
dHVyYWxseSB0aGUgZm9jdXMgd2FzIG9uIGZvcndhcmQgc2VjcmVjeSBhbmQgcmVwbGF5LiBPbiBm
b3J3YXJkIHNlY3JlY3kgdGhlIG1haW4gZmluZGluZyB3YXMgdGhhdCBpdCdzIG5vdCBuZWNlc3Nh
cnkgdG8gdHJhZGUgb2ZmIEZvcndhcmQgU2VjcmVjeSBhbmQgMC1SVFQuIEEgc2luZ2xlLXVzZSBz
ZXNzaW9uIGNhY2hlIGNhbiBwcm92aWRlIGl0LCBhbmQgd2l0aCB0aGUgbW9kaWZpY2F0aW9uIHRo
YXQgZWtyIGhhcyBjcmVhdGVkIGluIGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVj
L3B1bGwvOTk4ICwgc3VjaCBhIGNhY2hlIHdvcmtzIGZvciBib3RoIHByZS1hdXRoIGFuZCBwb3N0
LWF1dGggdGlja2V0cywgYW5kIGl0IGFsbG93cyBjbGllbnRzIHRvIGJ1aWxkIHVwIHBvb2xzIG9m
IG1lYW5pbmdmdWxseSBkaXN0aW5jdCB0aWNrZXRzLg0KDQpUaGVyZSdzIGFsc28gYW4gb2JzZXJ2
YXRpb24gdGhlcmUgdGhhdCBpdCBzaG91bGQgcmVhbGx5IGJlIHRoYXQgY2xpZW50cyAiTVVTVCIg
dXNlIHRpY2tldHMgb25seSBvbmNlLiBBbnkgcmUtdXNlIGxpa2VseSBkaXNjbG9zZXMgdGhlIG9i
ZnVzY2F0ZWQgdGlja2V0IGFnZSwgd2hpY2ggaXMgaW50ZW5kZWQgdG8gYmUgc2VjcmV0LiBSaWdo
dCBub3cgaXQncyBhICJTSE9VTEQiLg0KDQpPbiByZXBsYXksIHRoZSBtYWluIGZpbmRpbmcgaXMg
dGhhdCB3aGF0J3MgaW4gdGhlIGRyYWZ0IGlzIG5vdCB3b3JrYWJseSBzZWN1cmUsIGFuZCB0aGUg
cmV2aWV3IGluY2x1ZGVzIDUgZGlmZmVyZW50IGF0dGFja3MgYWdhaW5zdCAwLVJUVCBkYXRhIHRv
IGlsbHVzdHJhdGUgdGhhdC4gQXR0YWNrcyAxIGFuZCAyIHNob3cgdGhhdCB0aGUga2luZCBvZiBy
ZXBsYXkgcGVybWl0dGVkIGJ5IHRoZSBkcmFmdCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHRoZSBr
aW5kIG9mIHJlcGxheSBwZXJtaXR0ZWQgYnkgZGtnJ3MgZXhpc3RpbmcgZG93bmdyYWRlLWFuZC1y
ZXRyeSBhdHRhY2suIEkgYWxzbyBnbyBvdmVyIHdoeSBpdCB2ZXJ5IHZlcnkgZGlmZmljdWx0IHRv
IG1hbnkgYXBwbGljYXRpb25zIHRvIGFjaGlldmUgdGhhdCBpZGVtcG90ZW5jeSwgYW5kIHdoeSBv
bmUgaWRlbXBvdGVuY3kgcGF0dGVybiBhY3R1YWxseSByZWxpZXMgb24gbm9uLXJlcGxheWFibGUg
bWVzc2FnZXMuDQoNCkF0dGFjayAzIHNob3dzIHRoYXQgaWRlbXBvdGVuY3kgaXMgbm90IHN1ZmZp
Y2llbnQsIGFwcGxpY2F0aW9ucyBtdXN0IGFsc28gYmUgZnJlZSBvZiBtZWFzdXJhYmxlIHNpZGUt
ZWZmZWN0cywgd2hpY2ggaXMgbm90IHByYWN0aWNhbC4gIEF0dGFjayA0IHNob3dzIHRoYXQgMC1S
VFQgYnJlYWtzIGEgY29tbW9uIHNlY3VyaXR5IG1lY2hhbmlzbTogc3Bvb2ZpbmctcmVzaXN0YW50
IHRocm90dGxlcy4gQXR0YWNrIDUgc2hvd3MgdGhhdCAwLVJUVCByZXBsYXktYWJpbGl0eSBlbmFi
bGVzIGFuIGFkZGl0aW9uYWwgZm9ybSBvZiB0cmFmZmljIGFuYWx5c2lzLg0KDQpUaGUgcmVjb21t
ZW5kYXRpb24gaW4gdGhlIHJldmlldyBpcyB0aGF0IGltcGxlbWVudGF0aW9ucyAiTVVTVCIgcHJl
dmVudCByZXBsYXlzIG9mIDAtUlRUIHNlY3Rpb24sIHdpdGggc29tZSBhZGRpdGlvbmFsIGRpc2N1
c3Npb24gYWJvdXQgd2h5IHRoZSBleGlzdGluZyBhZHZpY2UgaXMgdW5saWtlbHkgdG8gYmUgZm9s
bG93ZWQsIGFuZCB3aHkgY29uc2lzdGVudCBpbnRlcm9wZXJhYmlsaXR5IG1hdHRlcnMgaGVyZS4N
Cg0KVW5mb3J0dW5hdGVseSwgSSB3YXNuJ3QgYXdhcmUgdW50aWwgRnJpZGF5IHRoYXQgdGhpcyBy
ZXZpZXcgd291bGQgYmUgY29taW5nIHNvIGxhdGUgaW4gdGhlIFRMRDEuMyBkcmFmdCBwcm9jZXNz
LCBhbmQgbXkgYXBvbG9naWVzIGZvciB0aGF0LiBJIGFtIG5vdyBwbGFubmluZyB0byBhdHRlbmQg
dGhlIGZ1dHVyZSBXRyBpbi1wZXJzb24gbWVldGluZ3MgYW5kIGxvb2sgZm9yd2FyZCB0byBzZWVp
bmcgbWFueSBvZiB5b3UgdGhlcmUuDQoNCi0tDQpDb2xtDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5v
cmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vdGxzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw
cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGxzJmQ9RHdNRmFRJmM9NVZEMFJU
dE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmbT1fMkJFQ2Y5T2ZXMXIx
YVJXckxfcFNiUWVLTXNoeU9tMk5JVldGNEdHQkkwJnM9NkdJb2NHelc2d1BLNEVBbHFETElpck52
c3VRajdnV2hZR19PelJPUjJxWSZlPT4NCg0K

--_000_MWHPR15MB11825419AF296AE7EC26F3BDAFEA0MWHPR15MB1182namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs
IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w
cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp
bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0
Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy
aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t
c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy
NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+
DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n
PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj
dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDEuIEEg
U0hPVUxELWxldmVsIHJlcXVpcmVtZW50IGZvciBzZXJ2ZXItc2lkZSAwLVJUVCBkZWZlbnNlLCBl
eHBsYWluaW5nIGJvdGggc2Vzc2lvbi1jYWNoZSBhbmQgc3RyaWtlIHJlZ2lzdGVyIHN0eWxlcyBh
bmQgdGhlIG1lcml0cyBvZiBlYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GaXJzdCwgYSBwb2ludCBvZiBj
bGFyaWZpY2F0aW9uLCBJIHRoaW5rIHR3byBpc3N1ZXMgaGF2ZSBiZWVuIGNvbmZsYXRlZCBpbiB0
aGlzIGxvbmcgdGhyZWFkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+MSkgU2VydmVycyByZWplY3RpbmcgcmVwbGF5ZWQgMC1SVFQg
ZGF0YSAodXNpbmcgYSBzaW5nbGUgdXNlIHNlc3Npb24gY2FjaGUvc3RyaWtlIHJlZ2lzdGVyL3Jl
cGxheSBjYWNoZS9zb21lIG90aGVyIG1ldGhvZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgYXJlIGRl
ZmluaXRlbHkgY2FzZXMgKGkuZS4gYXBwbGljYXRpb24gcHJvZmlsZXMpIHdoZXJlIHRoaXMgc2hv
dWxkIGJlIGRvbmUuIEkgdGhpbmsgYSBnZW5lcmFsIGNhc2UgSFRUUFMgc2VydmVyIGlzIG9uZS4g
QnV0IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHN0cmljdGx5IG5lY2Vzc2FyeSBhY3Jvc3MNCiB0
aGUgYm9hcmQgKGZvciBldmVyeSBhcHBsaWNhdGlvbiB1c2luZyAwLVJUVCBhdCBhbGwpLiBETlMg
d2FzIGJyb3VnaHQgdXAgZWFybGllciBpbiB0aGlzIHRocmVhZCBhcyBhbiBleGFtcGxlIG9mIGEg
cHJvdG9jb2wgdGhhdCBpcyBsaWtlbHkgcXVpdGUgd29ya2FibGUgd2l0aG91dCBleHRyYSBtZWFz
dXJlcyB0byBwcmV2ZW50IHJlcGxheS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBhbHJlYWR5IHN0YXRl
IOKAnFByb3RvY29scyBNVVNUIE5PVCB1c2UgMC1SVFQgZGF0YSB3aXRob3V0IGEgcHJvZmlsZSB0
aGF0IGRlZmluZXMgaXRzIHVzZS7igJ0uIFdlIGNvdWxkIGFsc28gZGVzY3JpYmUgbWV0aG9kcyB0
aGF0IG1heSBiZSB1c2VkIHRvIHByb3ZpZGUgZnVydGhlciByZXBsYXkgcHJvdGVjdGlvbi4NCiBC
dXQgSSBkb27igJl0IHRoaW5rIGl04oCZcyBhcHByb3ByaWF0ZSB0byBtYWtlIGEgYmxhbmtldCBy
ZXF1aXJlbWVudCB0aGF0ICphbGwqIGFwcGxpY2F0aW9uIHByb3RvY29scyBzaG91bGQgcmVxdWly
ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+SSBhbHNvIGNvbnNpZGVyIGl0IHF1aXRlIG1pc2xlYWRpbmcg
dG8gc2F5IFRMUyAxLjMgaXMgaW5zZWN1cmUgd2l0aG91dCBzdWNoIGEgcmVjb21tZW5kYXRpb24u
IFVzZXMgb2YgVExTIGNhbiBiZSBpbnNlY3VyZSwgdGhhdCBkb2VzIG5vdCBtZWFuIHRoZSBwcm90
b2NvbCBpdHNlbGYgaXMuIEl04oCZcyBpbnNlY3VyZQ0KIHRvIHVzZSBUTFMgd2l0aG91dCBwcm9w
ZXJseSBhdXRoZW50aWNhdGluZyB0aGUgc2VydmVyLiBTb21lIHVzZXJzIG9mIFRMUyBkbyBub3Qg
ZG8gdGhpcyBjb3JyZWN0bHkuIEnigJlkIGFjdHVhbGx5IGFyZ3VlIHRoYXQgaXQgaXMgZWFzaWVy
IHRvIG1lc3MgdGhpcyB1cCB0aGFuIGl0IGlzIHRvIG1lc3MgdXAgYSAwLVJUVCBkZXBsb3ltZW50
IChhbmQgaXQgY2FuIHJlc3VsdCBpbiB3b3JzZSBjb25zZXF1ZW5jZXMpLiBUaGF0IGRvZXNu4oCZ
dCBtZWFuIHdlDQogc2hvdWxkIHJlcXVpcmUgYSBwYXJ0aWN1bGFyIG1ldGhvZCBvZiBhdXRoZW50
aWNhdGlvbiwgZm9yIGFsbCB1c2VzIG9mIFRMUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MikgUHJldmVudGlu
ZyBjbGllbnRzIGZyb20gc2VuZGluZyAwLVJUVCBkYXRhIG11bHRpcGxlIHRpbWVzIChvbiBzZXBh
cmF0ZSBjb25uZWN0aW9ucykgdXNpbmcgdGhlIHNhbWUgUFNLIChmb3IgZm9yd2FyZCBzZWNyZWN5
IHJlYXNvbnMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYWxsb3dlZC4g
T3RoZXJ3aXNlLCBjbGllbnRzIHdpbGwgbm90IGJlIGFibGUgdG8gcmV0cnkgMC1SVFQgcmVxdWVz
dHMgdGhhdCBmYWlsIGR1ZSB0byBhbiB1bmtub3duIG5ldHdvcmsgZXJyb3IgcHJpb3IgdG8gcmVj
ZWl2aW5nIGEgTlNUIChpZiB0aGV5IGFyZQ0KIG91dCBvZiBjYWNoZWQgUFNLcykuIEnigJlkIGV4
cGVjdCB0aGUgbmVlZCBmb3IgdGhlc2UgcmV0cmllcyB0byBiZSBsYXJnZXIgd2l0aCAwLVJUVCBk
YXRhLCBwYXJ0aWN1bGFybHkgd2hlbiAwLVJUVCBkYXRhIGlzIHNlbnQgd2l0aG91dCBldmVuIGEg
dHJhbnNwb3J0IHJvdW5kdHJpcCAoaW4gdGhlIGNhc2Ugb2YgVEZPIG9yIFFVSUMpLiBTZXJ2ZXJz
IGFyZSBkZWZpbml0ZWx5IG5vdCByZXF1aXJlZCB0byBhY2NlcHQgbXVsdGlwbGUgMC1SVFQgY29u
bmVjdGlvbnMNCiB1c2luZyB0aGUgc2FtZSBQU0ssIGJ1dCBJIGRvbuKAmXQgdGhpbmsgY2xpZW50
cyBzaG91bGQgYmUgYmFubmVkIGZyb20gYXR0ZW1wdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAy
LiBEb2N1bWVudCAwLVJUVCBncmVhc2luZyBpbiBkcmFmdC1pZXRmLXRscy1ncmVhc2U8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+SeKAmW0gbm90IGNvbnZpbmNlZCB0aGlzIGlzIGFjdHVhbGx5IGEgcHJvZHVjdGl2
ZSB0aGluZyB0byBkbyBpbiB0aGUgc2FtZSBtYW5uZXIgYXMgZ3JlYXNlLCBwYXJ0aWN1bGFybHkg
aWYgc2VydmVycyBhcmUgdGFraW5nIGFudGktcmVwbGF5IG1lYXN1cmVzIChpbiB3aGljaCBjYXNl
IEkgc2VlIHRoaXMNCiBiZWluZyB1c2VmdWwgaW4gYSBUTFMgdGVzdGluZyB0b29sIGxpa2Ugc3Ns
bGFicywgYnV0IG5vdCBpbiBhY3R1YWwgZGVwbG95bWVudHMpLiBJIHRoaW5rIHdlIGNhbiBsZWF2
ZSB0aGlzIGRpc2N1c3Npb24gZm9yIGxhdGVyIHRob3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAz
LiBBZG9wdCBQUiM0NDggKG9yIHNvbWUgdmFyaWFudCkgc28gdGhhdCBzZXNzaW9uLWlkIHN0eWxl
IGltcGxlbWVudGF0aW9ucyBwcm92aWRlIFBGUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U291bmRzIGdvb2Qg
dG8gbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgNC4gSSB3b3VsZCBhZGQgdG8gdGhpcyB0aGF0IHdl
IHJlY29tbWVuZCB0aGF0IHByb3h5L0NETiBpbXBsZW1lbnRhdGlvbnMgc2lnbmFsIHdoaWNoIGRh
dGEgaXMgMC1SVFQgYW5kIHdoaWNoIGlzIDEtUlRUIHRvIHRoZSBiYWNrLWVuZCAodGhpcyB3YXMg
aW4gQ29sbSdzIG9yaWdpbmFsIG1lc3NhZ2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J4oCZbSBub3Qgc3Vy
ZSB0aGF0IHRoZSBUTFMgMS4zIHNwZWMgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIG1ha2UgcmVjb21t
ZW5kYXRpb25zIGZvciB0aGlzLiBJIGNhbiBzZWUgc2V2ZXJhbCByZWFzb25hYmxlIGFwcHJvYWNo
ZXMgaGVyZSwgZm9yIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tIEFkZGluZyBzb21lIGtpbmQgb2YgYXBwbGljYXRp
b24gbGV2ZWwgYW5ub3RhdGlvbiAoZm9yIGV4YW1wbGUgYW4gSFRUUCBoZWFkZXIpPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tIFJv
YnVzdGx5IHByZXZlbnRpbmcgcmVwbGF5IG9uIHRoZSAwLVJUVCBob3A8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0gU2VuZGluZyBw
cm94aWVkIGVhcmx5IGRhdGEgd2l0aCBhIGRpZmZlcmVudCBUTFMgQ29udGVudFR5cGUsIGV0Yy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVkIHRvIHNwZWNpZmljYWxseSBlbmRvcnNlIGFueSBwYXJ0
aWN1bGFyIG1ldGhvZCBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlIHdhcyBh
bHNvIGEgcG9pbnQgYnJvdWdodCB1cCBhYm91dCB0aGUgdXNlIG9mIHRpY2tldF9hZ2Ugd2l0aG91
dCAwLVJUVC4gSeKAmW0gbm90IGF3YXJlIG9mIGFueSB1c2UgZm9yIHRpY2tldF9hZ2Ugb3RoZXIg
dGhhbiAwLVJUVCByZXBsYXkgcHJvdGVjdGlvbi4gSSBiZWxpZXZlIHRoYXQgdGlja2V0X2FnZQ0K
IGlzIHNlbnQgd2l0aCBhbGwgUFNLcyBtb3N0bHkgb3V0IG9mIGNvbnZlbmllbmNlL2NvbnNpc3Rl
bmN5LiBJIGRvbuKAmXQgcmVhbGx5IGhhdmUgYW4gb2JqZWN0aW9uIHRvIHRoZSBjdXJyZW50IG1l
dGhvZCwgYnV0IEkgYWxzbyB3b3VsZG7igJl0IGJlIG9wcG9zZWQgdG8gbW92aW5nIHRoZSB0aWNr
ZXQgYWdlIHRvIHRoZSBlYXJseSBkYXRhIGV4dGVuc2lvbiwgc28gdGhhdCBpdCBpcyBvbmx5IHNl
bnQgYWxvbmcgd2l0aCAwLVJUVCBkYXRhLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JdCBhbHNvIHNlZW1zIGEgbGl0dGxlIHVu
ZGVyLXNwZWNpZmllZCB3aGF0IGltcGxlbWVudGF0aW9ucyB1bmFibGUgdG8gY29tcHV0ZSBhIHJl
YXNvbmFibGUgdGlja2V0IGFnZSBzaG91bGQgc2VuZCAoZm9yIGV4YW1wbGUgaW4gdGhlIGNhc2Ug
b2YgYSBkZXZpY2Ugd2l0aG91dCBhIHJlYWwgdGltZSBjbG9jaywNCiBvciB3aXRoIGFuIGV4dGVy
bmFsIFBTSykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg
bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0
bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxi
cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAzLCAyMDE3IDExOjEzIFBNPGJyPg0KPGI+
VG86PC9iPiBDb2xtIE1hY0PDoXJ0aGFpZ2ggJmx0O2NvbG1AYWxsY29zdHMubmV0Jmd0Ozxicj4N
CjxiPkNjOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBT
ZWN1cml0eSByZXZpZXcgb2YgVExTMS4zIDAtUlRUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+W0RlbGliZXJhdGVseSByZXNwb25kaW5nIHRvIHRoZSBPUCByYXRoZXIgdGhh
biB0byBhbnlvbmUgaW4gcGFydGljdWxhcl08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gc2VlaW5nIGEgbG90IG9mIGJhY2sgYW5kIGZvcnRo
IGFib3V0IGdlbmVyYWwgcGhpbG9zb3BoeSBhbmQgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aXNkb20gb2YgMC1SVFQgYnV0IEkgdGhpbmsg
aXQgd291bGQgYmUgdXNlZnVsIGlmIHdlIGZvY3VzZWQgb24gd2hhdDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hhbmdlcywgaWYgYW55LCB3ZSBu
ZWVkIHRvIG1ha2UgdG8gdGhlIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1hZGUgc29tZSBwcm9wb3NhbHMgeWVzdGVy
ZGF5Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4oPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX3Rsc19jdXJyZW50X21z
ZzIzMDg4Lmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1w
O3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZhbXA7bT1fMkJFQ2Y5T2ZXMXIxYVJXckxfcFNiUWVL
TXNoeU9tMk5JVldGNEdHQkkwJmFtcDtzPVhnSGJVd1Q2dXBBc09pbjRUNlA4ZVBzOGkwWkZzbkQt
X0JOdnVlZXE4M0UmYW1wO2U9Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi
L3Rscy9jdXJyZW50L21zZzIzMDg4Lmh0bWw8L2E+KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlY2lmaWNhbGx5OjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQSBTSE9VTEQtbGV2ZWwg
cmVxdWlyZW1lbnQgZm9yIHNlcnZlci1zaWRlIDAtUlRUIGRlZmVuc2UsIGV4cGxhaW5pbmc8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJvdGggc2Vz
c2lvbi1jYWNoZSBhbmQgc3RyaWtlIHJlZ2lzdGVyIHN0eWxlcyBhbmQgdGhlIG1lcml0cyBvZiBl
YWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4yLiBEb2N1bWVudCAwLVJUVCBncmVhc2luZyBpbiBkcmFmdC1pZXRmLXRscy1ncmVhc2U8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gQWRv
cHQgUFIjNDQ4IChvciBzb21lIHZhcmlhbnQpIHNvIHRoYXQgc2Vzc2lvbi1pZCBzdHlsZSBpbXBs
ZW1lbnRhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPnByb3ZpZGUgUEZTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj40LiBJIHdvdWxkIGFkZCB0byB0aGlzIHRoYXQgd2UgcmVjb21tZW5k
IHRoYXQgcHJveHkvQ0ROIGltcGxlbWVudGF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2lnbmFsIHdoaWNoIGRhdGEgaXMgMC1SVFQgYW5k
IHdoaWNoIGlzIDEtUlRUIHRvIHRoZSBiYWNrLWVuZCAodGhpcyB3YXMgaW48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbG0ncyBvcmlnaW5hbCBt
ZXNzYWdlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+QmFzZWQgb24gQ29sbSdzIHJlc3BvbnNlLCBJIHRoaW5rIHRoZXNlIGxhcmdlbHkgaGl0
cyB0aGUgcG9pbnRzIGhlIG1hZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPmluIGhpcyBvcmlnaW5hbCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSdzIGFscmVhZHkgYSBQ
UiBmb3IgIzMgYW5kIEknbGwgaGF2ZSBQUnMgZm9yICMxIGFuZCAjNCB0b21vcnJvdy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgd291bGQg
YmUgbW9zdCBoZWxwZnVsIHRvIG1lIGFzIEVkaXRvciB3b3VsZCBiZSBpZiBwZW9wbGUgY291bGQg
cmV2aWV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij50aGVzZSBQUnMgYW5kL29yIHN1Z2dlc3Qgb3RoZXIgc3BlY2lmaWMgY2hhbmdlcyB0aGF0IHdl
IHNob3VsZCBtYWtlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj50byB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1heSAyLCAyMDE3IGF0IDc6NDQgQU0s
IENvbG0gTWFjQ8OhcnRoYWlnaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvbG1AYWxsY29zdHMubmV0
IiB0YXJnZXQ9Il9ibGFuayI+Y29sbUBhbGxjb3N0cy5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1bmRheSBhdCB0aGUgVExTOkRJViB3
b3Jrc2hvcCBJIHByZXNlbnRlZCBhIHN1bW1hcnkgb2YgZmluZGluZ3Mgb2YgYSBzZWN1cml0eSBy
ZXZpZXcgd2UgZGlkIG9uIFRMUzEuMyAwLVJUVCwgYXMgcGFydCBvZiBpbXBsZW1lbnRpbmcgMS4z
IGluIHMybi4gVGhhbmtzIHRvIGZlZWRiYWNrIGluIHRoZSByb29tIEkndmUgbm93IHRpZ2h0ZW5l
ZCB1cCB0aGUgZmluZGluZ3MgZnJvbSB0aGUgcmV2aWV3IGFuZCBwb3N0ZWQNCiB0aGVtIGFzIGFu
IGlzc3VlIG9uIHRoZSBkcmFmdCBHaXRIdWIgcmVwbzo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90
bHMxMy1zcGVjL2lzc3Vlcy8xMDAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29t
L3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzEwMDE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwgc3VtbWFyaXplIHRoZSBzdW1tYXJ5
OiBOYXR1cmFsbHkgdGhlIGZvY3VzIHdhcyBvbiBmb3J3YXJkIHNlY3JlY3kgYW5kIHJlcGxheS4g
T24gZm9yd2FyZCBzZWNyZWN5IHRoZSBtYWluIGZpbmRpbmcgd2FzIHRoYXQgaXQncyBub3QgbmVj
ZXNzYXJ5IHRvIHRyYWRlIG9mZiBGb3J3YXJkIFNlY3JlY3kgYW5kIDAtUlRULiBBIHNpbmdsZS11
c2Ugc2Vzc2lvbiBjYWNoZSBjYW4gcHJvdmlkZSBpdCwgYW5kIHdpdGgNCiB0aGUgbW9kaWZpY2F0
aW9uIHRoYXQgZWtyIGhhcyBjcmVhdGVkIGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu
Y29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC85OTgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dp
dGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzk5ODwvYT4gLCBzdWNoIGEgY2FjaGUgd29y
a3MgZm9yIGJvdGggcHJlLWF1dGggYW5kIHBvc3QtYXV0aCB0aWNrZXRzLCBhbmQgaXQgYWxsb3dz
IGNsaWVudHMgdG8gYnVpbGQgdXANCiBwb29scyBvZiBtZWFuaW5nZnVsbHkgZGlzdGluY3QgdGlj
a2V0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhlcmUncyBhbHNvIGFuIG9ic2VydmF0aW9uIHRoZXJlIHRoYXQgaXQgc2hvdWxkIHJlYWxs
eSBiZSB0aGF0IGNsaWVudHMgJnF1b3Q7TVVTVCZxdW90OyB1c2UgdGlja2V0cyBvbmx5IG9uY2Uu
IEFueSByZS11c2UgbGlrZWx5IGRpc2Nsb3NlcyB0aGUgb2JmdXNjYXRlZCB0aWNrZXQgYWdlLCB3
aGljaCBpcyBpbnRlbmRlZCB0byBiZSBzZWNyZXQuIFJpZ2h0IG5vdyBpdCdzIGEgJnF1b3Q7U0hP
VUxEJnF1b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiByZXBsYXksIHRoZSBtYWluIGZpbmRpbmcgaXMgdGhhdCB3aGF0J3Mg
aW4gdGhlIGRyYWZ0IGlzIG5vdCB3b3JrYWJseSBzZWN1cmUsIGFuZCB0aGUgcmV2aWV3IGluY2x1
ZGVzIDUgZGlmZmVyZW50IGF0dGFja3MgYWdhaW5zdCAwLVJUVCBkYXRhIHRvIGlsbHVzdHJhdGUg
dGhhdC4gQXR0YWNrcyAxIGFuZCAyIHNob3cgdGhhdCB0aGUga2luZCBvZiByZXBsYXkgcGVybWl0
dGVkIGJ5IHRoZSBkcmFmdCBpcyB2ZXJ5DQogZGlmZmVyZW50IGZyb20gdGhlIGtpbmQgb2YgcmVw
bGF5IHBlcm1pdHRlZCBieSBka2cncyBleGlzdGluZyBkb3duZ3JhZGUtYW5kLXJldHJ5IGF0dGFj
ay4gSSBhbHNvIGdvIG92ZXIgd2h5IGl0IHZlcnkgdmVyeSBkaWZmaWN1bHQgdG8gbWFueSBhcHBs
aWNhdGlvbnMgdG8gYWNoaWV2ZSB0aGF0IGlkZW1wb3RlbmN5LCBhbmQgd2h5IG9uZSBpZGVtcG90
ZW5jeSBwYXR0ZXJuIGFjdHVhbGx5IHJlbGllcyBvbiBub24tcmVwbGF5YWJsZSBtZXNzYWdlcy4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+QXR0YWNrIDMgc2hvd3MgdGhhdCBpZGVtcG90ZW5jeSBpcyBub3Qgc3VmZmljaWVudCwgYXBw
bGljYXRpb25zIG11c3QgYWxzbyBiZSBmcmVlIG9mIG1lYXN1cmFibGUgc2lkZS1lZmZlY3RzLCB3
aGljaCBpcyBub3QgcHJhY3RpY2FsLiZuYnNwOyBBdHRhY2sgNCBzaG93cyB0aGF0IDAtUlRUIGJy
ZWFrcyBhIGNvbW1vbiBzZWN1cml0eSBtZWNoYW5pc206IHNwb29maW5nLXJlc2lzdGFudCB0aHJv
dHRsZXMuIEF0dGFjayA1DQogc2hvd3MgdGhhdCAwLVJUVCByZXBsYXktYWJpbGl0eSBlbmFibGVz
IGFuIGFkZGl0aW9uYWwgZm9ybSBvZiB0cmFmZmljIGFuYWx5c2lzLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVjb21tZW5k
YXRpb24gaW4gdGhlIHJldmlldyBpcyB0aGF0IGltcGxlbWVudGF0aW9ucyAmcXVvdDtNVVNUJnF1
b3Q7IHByZXZlbnQgcmVwbGF5cyBvZiAwLVJUVCBzZWN0aW9uLCB3aXRoIHNvbWUgYWRkaXRpb25h
bCBkaXNjdXNzaW9uIGFib3V0IHdoeSB0aGUgZXhpc3RpbmcgYWR2aWNlIGlzIHVubGlrZWx5IHRv
IGJlIGZvbGxvd2VkLCBhbmQgd2h5IGNvbnNpc3RlbnQgaW50ZXJvcGVyYWJpbGl0eSBtYXR0ZXJz
IGhlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlVuZm9ydHVuYXRlbHksIEkgd2Fzbid0IGF3YXJlIHVudGlsIEZyaWRheSB0aGF0
IHRoaXMgcmV2aWV3IHdvdWxkIGJlIGNvbWluZyBzbyBsYXRlIGluIHRoZSBUTEQxLjMgZHJhZnQg
cHJvY2VzcywgYW5kIG15IGFwb2xvZ2llcyBmb3IgdGhhdC4gSSBhbSBub3cgcGxhbm5pbmcgdG8g
YXR0ZW5kIHRoZSBmdXR1cmUgV0cgaW4tcGVyc29uIG1lZXRpbmdzIGFuZCBsb29rIGZvcndhcmQg
dG8gc2VlaW5nIG1hbnkgb2YNCiB5b3UgdGhlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiM4ODg4ODgiPkNvbG08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0Bp
ZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f
bGlzdGluZm9fdGxzJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFt
cDtyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmYW1wO209XzJCRUNmOU9mVzFyMWFSV3JMX3BTYlFl
S01zaHlPbTJOSVZXRjRHR0JJMCZhbXA7cz02R0lvY0d6VzZ3UEs0RUFscURMSWlyTnZzdVFqN2dX
aFlHX096Uk9SMnFZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_MWHPR15MB11825419AF296AE7EC26F3BDAFEA0MWHPR15MB1182namp_--


From nobody Thu May  4 14:38:10 2017
Return-Path: 
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 4AACF12945C for ; Thu,  4 May 2017 14:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 w09FisWzODXv for ; Thu,  4 May 2017 14:38:05 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AD5129535 for ; Thu,  4 May 2017 14:38:02 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id 8so6882934ybw.1 for ; Thu, 04 May 2017 14:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Q4ZSrJauuFd9kzBMnNSqC8jGbh+rclSoBPQ7jP3x+Q=; b=l2jci7hb865ihEFr1BPWyjqQmSgih3PCm7JGo87c7yWlLUknIFubYD8SoXvJ9sSbWx WgoqDHCBPSjm2Rbu8gx3pMTYT/icG1aurD1JOvujuoALpq8rjUZJPwytWOZvxzGuIWIj o8zgiKhUtWSWXI7O3kEbDtdoQVnHr5xgCCvRyKXrwUrUjItP7mF/l4MNnOa6lEYFvsbA dyI3B71TzDp1gdF8272Lm09ReXb+XbmO4VABhVZSrfXAwbiOqZKYhyAFeRO/AiXtiMxc Q7222Tk8H5b36erytor4HIyfguhcJW5iyiQI+onX/CRyG0bOibyBeELFw7Xn33PJ1Wmw 1izA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Q4ZSrJauuFd9kzBMnNSqC8jGbh+rclSoBPQ7jP3x+Q=; b=odeSwu/SEfBe53A4FMQ+iuI/mYkbK9Asis2OcyA6J2ZbgST3pO1kN5DUtR0Ow9FXQy rHkqEsrNDRqOe8DypR8t2raCHA+nC4Q/zlgOdFxhLxQDpy6YfAsy2XbLPu2d4dlc0Ac6 8JBaWJh2AvY3pxjd348qJzibX6rPUu1PQ+PNDcONqiMbPvapJfpAy2n9QfN03FDv4LDy mLl+7EkBqwAb/8Ad2gkU8Fhy++ani+103FWwW7L/pAo8w7A5TNsZEl2+G9y7LatfbDsZ h6ZqF45rZdlNYpdffNcno5qyHk1rrrSOFQl0a5VMVobTIhk4wMerbbOc6OAIRxsxb2xw 5gnA==
X-Gm-Message-State: AN3rC/6ObHeoSfsQKo84JG6kjv8X7d6iexEV3A8Qn6bklaGsnqYXnhNN 90+z1JADUEiNXBhgEHV+QUgsIeYg2g==
X-Received: by 10.37.174.24 with SMTP id a24mr36578484ybj.50.1493933881200; Thu, 04 May 2017 14:38:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 4 May 2017 14:37:20 -0700 (PDT)
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Thu, 4 May 2017 14:37:20 -0700
Message-ID: 
To: Kyle Nekritz 
Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045da3584e9e8f054eb996ad
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 21:38:09 -0000

--f403045da3584e9e8f054eb996ad
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:

> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>
>
>
> First, a point of clarification, I think two issues have been conflated i=
n
> this long thread:
>
> 1) Servers rejecting replayed 0-RTT data (using a single use session
> cache/strike register/replay cache/some other method)
>
>
>
> There are definitely cases (i.e. application profiles) where this should
> be done. I think a general case HTTPS server is one. But I don=E2=80=99t =
think this
> is strictly necessary across the board (for every application using 0-RTT
> at all). DNS was brought up earlier in this thread as an example of a
> protocol that is likely quite workable without extra measures to prevent
> replay.
>
>
>
> We already state =E2=80=9CProtocols MUST NOT use 0-RTT data without a pro=
file that
> defines its use.=E2=80=9D. We could also describe methods that may be use=
d to
> provide further replay protection. But I don=E2=80=99t think it=E2=80=99s=
 appropriate to
> make a blanket requirement that *all* application protocols should requir=
e
> it.
>
>
>
> I also consider it quite misleading to say TLS 1.3 is insecure without
> such a recommendation. Uses of TLS can be insecure, that does not mean th=
e
> protocol itself is. It=E2=80=99s insecure to use TLS without properly
> authenticating the server. Some users of TLS do not do this correctly. I=
=E2=80=99d
> actually argue that it is easier to mess this up than it is to mess up a
> 0-RTT deployment (and it can result in worse consequences). That doesn=E2=
=80=99t
> mean we should require a particular method of authentication, for all use=
s
> of TLS.
>

I think this is basically right. In the PR I just posted, I spent most of
my time describing the
mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
I think there's a bunch of room to wordsmith the requirement. Perhaps we
say:

- You can't do 0-RTT without an application profile
- Absent the application profile saying otherwise you SHOULD/MUST do one of
these mitigations?


2) Preventing clients from sending 0-RTT data multiple times (on separate
> connections) using the same PSK (for forward secrecy reasons)
>
>
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior to
> receiving a NST (if they are out of cached PSKs). I=E2=80=99d expect the =
need for
> these retries to be larger with 0-RTT data, particularly when 0-RTT data =
is
> sent without even a transport roundtrip (in the case of TFO or QUIC).
> Servers are definitely not required to accept multiple 0-RTT connections
> using the same PSK, but I don=E2=80=99t think clients should be banned fr=
om
> attempting.
>

I agree, and the PR I provided doesn't attempt to do so.


> 4. I would add to this that we recommend that proxy/CDN implementations
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was i=
n
> Colm's original message).
>
>
>
> I=E2=80=99m not sure that the TLS 1.3 spec is the right place to make
> recommendations for this. I can see several reasonable approaches here, f=
or
> example:
>
> - Adding some kind of application level annotation (for example an HTTP
> header)
>
> - Robustly preventing replay on the 0-RTT hop
>
> - Sending proxied early data with a different TLS ContentType, etc.
>
> I don=E2=80=99t see a need to specifically endorse any particular method =
here.
>

I think Colm has also agreed we shouldn't do this and it's not in my PR.


>
>
>
> There was also a point brought up about the use of ticket_age without
> 0-RTT. I=E2=80=99m not aware of any use for ticket_age other than 0-RTT r=
eplay
> protection. I believe that ticket_age is sent with all PSKs mostly out of
> convenience/consistency. I don=E2=80=99t really have an objection to the =
current
> method, but I also wouldn=E2=80=99t be opposed to moving the ticket age t=
o the
> early data extension, so that it is only sent along with 0-RTT data.
>

I would be OK with this as well. It does seem slightly more elegant.




> It also seems a little under-specified what implementations unable to
> compute a reasonable ticket age should send (for example in the case of a
> device without a real time clock,
>

Right. I have been basically assuming that you can't really do TLS without
a real-time clock, but maybe that's wrong?



> or with an external PSK).
>

This actually is well-specified (though maybe wrong)
"For identities established externally an obfuscated_ticket_age of 0 SHOULD
be used, and servers MUST ignore the value."
https://tlswg.github.io/tls13-spec/#pre-shared-key-extension

-Ekr


> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, May 3, 2017 11:13 PM
> *To:* Colm MacC=C3=A1rthaigh 
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Security review of TLS1.3 0-RTT
>
>
>
> [Deliberately responding to the OP rather than to anyone in particular]
>
>
>
> Hi folks,
>
>
>
> I'm seeing a lot of back and forth about general philosophy and the
>
> wisdom of 0-RTT but I think it would be useful if we focused on what
>
> changes, if any, we need to make to the draft.
>
>
>
> I made some proposals yesterday
>
> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html
> 
> ).
>
>
>
> Specifically:
>
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>
> both session-cache and strike register styles and the merits of each.
>
>
>
> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>
>
>
> 3. Adopt PR#448 (or some variant) so that session-id style implementation=
s
>
> provide PFS.
>
>
>
> 4. I would add to this that we recommend that proxy/CDN implementations
>
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was i=
n
>
> Colm's original message).
>
>
>
> Based on Colm's response, I think these largely hits the points he made
>
> in his original message.
>
>
>
> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>
> What would be most helpful to me as Editor would be if people could revie=
w
>
> these PRs and/or suggest other specific changes that we should make
>
> to the document.
>
>
>
> Thanks,
>
> -Ekr
>
>
>
>
>
>
>
>
>
> On Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthaigh 
> wrote:
>
> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2=
n.
> Thanks to feedback in the room I've now tightened up the findings from th=
e
> review and posted them as an issue on the draft GitHub repo:
>
>
>
> https://github.com/tlswg/tls13-spec/issues/1001
>
>
>
> I'll summarize the summary: Naturally the focus was on forward secrecy an=
d
> replay. On forward secrecy the main finding was that it's not necessary t=
o
> trade off Forward Secrecy and 0-RTT. A single-use session cache can provi=
de
> it, and with the modification that ekr has created in
> https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for
> both pre-auth and post-auth tickets, and it allows clients to build up
> pools of meaningfully distinct tickets.
>
>
>
> There's also an observation there that it should really be that clients
> "MUST" use tickets only once. Any re-use likely discloses the obfuscated
> ticket age, which is intended to be secret. Right now it's a "SHOULD".
>
>
>
> On replay, the main finding is that what's in the draft is not workably
> secure, and the review includes 5 different attacks against 0-RTT data to
> illustrate that. Attacks 1 and 2 show that the kind of replay permitted b=
y
> the draft is very different from the kind of replay permitted by dkg's
> existing downgrade-and-retry attack. I also go over why it very very
> difficult to many applications to achieve that idempotency, and why one
> idempotency pattern actually relies on non-replayable messages.
>
>
>
> Attack 3 shows that idempotency is not sufficient, applications must also
> be free of measurable side-effects, which is not practical.  Attack 4 sho=
ws
> that 0-RTT breaks a common security mechanism: spoofing-resistant
> throttles. Attack 5 shows that 0-RTT replay-ability enables an additional
> form of traffic analysis.
>
>
>
> The recommendation in the review is that implementations "MUST" prevent
> replays of 0-RTT section, with some additional discussion about why the
> existing advice is unlikely to be followed, and why consistent
> interoperability matters here.
>
>
>
> Unfortunately, I wasn't aware until Friday that this review would be
> coming so late in the TLD1.3 draft process, and my apologies for that. I =
am
> now planning to attend the future WG in-person meetings and look forward =
to
> seeing many of you there.
>
>
>
> --
>
> Colm
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
>
>
>

--f403045da3584e9e8f054eb996ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <knekritz@fb.com> wrote:











> 1. A SHOULD-level requirement for server-side 0-RTT defense,=
 explaining both session-cache and strike register styles and the merits of=
 each.


=C2=A0


First, a point of clarification, I think two issues have b=
een conflated in this long thread:


1) Servers rejecting replayed 0-RTT data (using a single use sess=
ion cache/strike register/replay cache/some other method)


=C2=A0


There are definitely cases (i.e. application profiles) where this=
 should be done. I think a general case HTTPS server is one. But I don=E2=
=80=99t think this is strictly necessary across
 the board (for every application using 0-RTT at all). DNS was brought up e=
arlier in this thread as an example of a protocol that is likely quite work=
able without extra measures to prevent replay.



=C2=A0


We already state =E2=80=9CProtocols MUST NOT use 0-RTT data witho=
ut a profile that defines its use.=E2=80=9D. We could also describe methods=
 that may be used to provide further replay protection.
 But I don=E2=80=99t think it=E2=80=99s appropriate to make a blanket requi=
rement that *all* application protocols should require it.


=C2=A0


I also consider it quite misleading to say TLS 1.3 is insecure wi=
thout such a recommendation. Uses of TLS can be insecure, that does not mea=
n the protocol itself is. It=E2=80=99s insecure
 to use TLS without properly authenticating the server. Some users of TLS d=
o not do this correctly. I=E2=80=99d actually argue that it is easier to me=
ss this up than it is to mess up a 0-RTT deployment (and it can result in w=
orse consequences). That doesn=E2=80=99t mean we
 should require a particular method of authentication, for all uses of TLS.=


I think this is bas=
ically right. In the PR I just posted, I spent most of my time describing t=
he
mechanisms and used a SHOULD-level requirement to do one of th=
e mechanisms.
I think there's a bunch of room to wordsmith th=
e requirement. Perhaps we say:

- You can't do =
0-RTT without an application profile
- Absent the application pro=
file saying otherwise you SHOULD/MUST do one of these mitigations?




2) Preventing clients from sending 0-RTT data multiple times (on =
separate connections) using the same PSK (for forward secrecy reasons)


=C2=A0


I think this should be allowed. Otherwise, clients will not be ab=
le to retry 0-RTT requests that fail due to an unknown network error prior =
to receiving a NST (if they are
 out of cached PSKs). I=E2=80=99d expect the need for these retries to be l=
arger with 0-RTT data, particularly when 0-RTT data is sent without even a =
transport roundtrip (in the case of TFO or QUIC). Servers are definitely no=
t required to accept multiple 0-RTT connections
 using the same PSK, but I don=E2=80=99t think clients should be banned fro=
m attempting.
=C2=A0
I ag=
ree, and the PR I provided doesn't attempt to do so.




> 4. I would add to this that we recommend that proxy/CDN impl=
ementations signal which data is 0-RTT and which is 1-RTT to the back-end (=
this was in Colm's original message).


=C2=A0


I=E2=80=99m not sure that the TLS 1.3 spec is the right pl=
ace to make recommendations for this. I can see several reasonable approach=
es here, for example:


- Adding some kind of application level annotation (for example a=
n HTTP header)


- Robustly preventing replay on the 0-RTT hop


- Sending proxied early data with a different TLS ContentType, et=
c.


I don=E2=80=99t see a need to specifically endorse any particular=
 method here.

I thin=
k Colm has also agreed we shouldn't do this and it's not in my PR.<=
/div>



=C2=A0


=C2=A0


There was also a point brought up about the use of ticket_age wit=
hout 0-RTT. I=E2=80=99m not aware of any use for ticket_age other than 0-RT=
T replay protection. I believe that ticket_age
 is sent with all PSKs mostly out of convenience/consistency. I don=E2=80=
=99t really have an objection to the current method, but I also wouldn=E2=
=80=99t be opposed to moving the ticket age to the early data extension, so=
 that it is only sent along with 0-RTT data.

I would be OK with this as well. It does seem slig=
htly more elegant.


=C2=A0
=





It also seems a little under-specified what implementations unabl=
e to compute a reasonable ticket age should send (for example in the case o=
f a device without a real time clock,

Right. I have been basically assuming that you can't =
really do TLS without a real-time clock, but maybe that's wrong?
<=
div>
=C2=A0

 or with an external PSK).

This actually is well-specified (though maybe wrong)
"=
;For identities established externally an obfuscated_ticket_age of 0 SHOULD=
 be used, and servers MUST ignore the value."

-Ekr
=C2=A0



From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Eric Rescorla

Sent: Wednesday, May 3, 2017 11:13 PM

To: Colm MacC=C3=A1rthaigh <colm@allcosts.net>

Cc: tls@ietf.org

Subject: Re: [TLS] Security review of TLS1.3 0-RTT


=C2=A0




[Deliberately responding to the OP rather than to an=
yone in particular]




=C2=A0






Hi folks,






=C2=A0






I'm seeing a lot of back and forth about general=
 philosophy and the






wisdom of 0-RTT but I think it would be useful if we=
 focused on what






changes, if any, we need to make to the draft.=C2=A0=







=C2=A0






I made some proposals yesterday=C2=A0<=
/p>






=C2=A0






Specifically:






1. A SHOULD-level requirement for server-side 0-RTT =
defense, explaining






both session-cache and strike register styles and th=
e merits of each.






=C2=A0






2. Document 0-RTT greasing in draft-ietf-tls-grease<=
u>






=C2=A0






3. Adopt PR#448 (or some variant) so that session-id=
 style implementations






provide PFS.






=C2=A0






4. I would add to this that we recommend that proxy/=
CDN implementations






signal which data is 0-RTT and which is 1-RTT to the=
 back-end (this was in






Colm's original message).






=C2=A0






Based on Colm's response, I think these largely =
hits the points he made






in his original message.






=C2=A0






There's already a PR for #3 and I'll have PR=
s for #1 and #4 tomorrow.






What would be most helpful to me as Editor would be =
if people could review






these PRs and/or suggest other specific changes that=
 we should make






to the document.






=C2=A0






Thanks,






-Ekr






=C2=A0






=C2=A0






=C2=A0






=C2=A0




On Tue, May 2, 2017 at 7:44 AM, Colm MacC=C3=A1rthai=
gh <colm@allcosts=
.net> wrote:






On Sunday at the TLS:DIV workshop I presented a summ=
ary of findings of a security review we did on TLS1.3 0-RTT, as part of imp=
lementing 1.3 in s2n. Thanks to feedback in the room I've now tightened=
 up the findings from the review and posted
 them as an issue on the draft GitHub repo:




=C2=A0







=C2=A0






I'll summarize the summary: Naturally the focus =
was on forward secrecy and replay. On forward secrecy the main finding was =
that it's not necessary to trade off Forward Secrecy and 0-RTT. A singl=
e-use session cache can provide it, and with
 the modification that ekr has created in=C2=A0https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both pre-auth and post-a=
uth tickets, and it allows clients to build up
 pools of meaningfully distinct tickets.






=C2=A0






There's also an observation there that it should=
 really be that clients "MUST" use tickets only once. Any re-use =
likely discloses the obfuscated ticket age, which is intended to be secret.=
 Right now it's a "SHOULD".=C2=A0






=C2=A0






On replay, the main finding is that what's in th=
e draft is not workably secure, and the review includes 5 different attacks=
 against 0-RTT data to illustrate that. Attacks 1 and 2 show that the kind =
of replay permitted by the draft is very
 different from the kind of replay permitted by dkg's existing downgrad=
e-and-retry attack. I also go over why it very very difficult to many appli=
cations to achieve that idempotency, and why one idempotency pattern actual=
ly relies on non-replayable messages.=C2=A0






=C2=A0






Attack 3 shows that idempotency is not sufficient, a=
pplications must also be free of measurable side-effects, which is not prac=
tical.=C2=A0 Attack 4 shows that 0-RTT breaks a common security mechanism: =
spoofing-resistant throttles. Attack 5
 shows that 0-RTT replay-ability enables an additional form of traffic anal=
ysis.=C2=A0






=C2=A0






The recommendation in the review is that implementat=
ions "MUST" prevent replays of 0-RTT section, with some additiona=
l discussion about why the existing advice is unlikely to be followed, and =
why consistent interoperability matters here.=C2=A0






=C2=A0






Unfortunately, I wasn't aware until Friday that =
this review would be coming so late in the TLD1.3 draft process, and my apo=
logies for that. I am now planning to attend the future WG in-person meetin=
gs and look forward to seeing many of
 you there.=C2=A0










=C2=A0=
<=
/span>




-- =





Colm












_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls







=C2=A0












--f403045da3584e9e8f054eb996ad--


From nobody Thu May  4 14:58:25 2017
Return-Path: 
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 1812C128B37 for ; Thu,  4 May 2017 14:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 CM1mIcQeIO8n for ; Thu,  4 May 2017 14:58:22 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00EF127286 for ; Thu,  4 May 2017 14:58:22 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 7B854A00491D; Thu,  4 May 2017 14:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yJnJ0M6uwVClEc V7TnTwiVwlub4=; b=bu6pEvmcum21SZAKiVUut+wA23tbD0Eh9INbUvP6kIQvxE 5bhLepZJlqxRuEVugH6XxoxMn3aFXd/3Xf77OFfOrkcwEFpHHlGsGRvayB3ld1i7 xCxyvh04UhgG4xT1hvYescZUuV2XTb3Mgb0XIiPTVKtclee3HdhT3NBufBTLA=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 22FFCA00491B; Thu,  4 May 2017 14:58:22 -0700 (PDT)
Date: Thu, 4 May 2017 16:58:19 -0500
From: Nico Williams 
To: Eric Rescorla 
Cc: Kyle Nekritz , "tls@ietf.org" 
Message-ID: <20170504215818.GZ10188@localhost>
References:    
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 21:58:24 -0000

On Thu, May 04, 2017 at 02:37:20PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
> > [...]
> 
> I think this is basically right. In the PR I just posted, I spent most of
> my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
> 
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one of
> these mitigations?

There's a number of ways to handle this.

One is to say that 0-rtt cannot be enabled by default, and that enabling
it requires an API call or application profile that puts the onus of
understanding the ramifications on the application developer.

The thing to keep in mind is that this RFC can give guidance to TLS
implementors, and to authors of Internet protocols using TLS.  It can't
really give guidance to authors of non-Internet protocols using TLS:
they might never look at the RFC.  So the guidance here has to be for
the available audience.  For TLS implementors the guidance should be to
make the 0-rtt footgun clear to consuming applications.

Nico
-- 


From nobody Thu May  4 14:59:09 2017
Return-Path: 
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 0B39D127333; Thu,  4 May 2017 14:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 1n2Y54K8Oo0j; Thu,  4 May 2017 14:59:05 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3834128B37; Thu,  4 May 2017 14:59:04 -0700 (PDT)
Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1d6Ols-00062O-4Q; Thu, 04 May 2017 23:59:03 +0200
To: ietf@ietf.org
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com>
Cc: "tls@ietf.org" 
From: Simon Friedberger 
Message-ID: <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org>
Date: Thu, 4 May 2017 23:58:47 +0200
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: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 21:59:07 -0000

Nits:

	RFC 4279 reference is missing.

	"TLS 1.3 and above version, " should probably be "TLS 1.3 and above" or "TLS 1.3 and higher versions"

On 04/05/17 18:41, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>    Security (TLS)'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-05-18. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines several new cipher suites for the Transport
>    Layer Security (TLS) protocol.  The cipher suites are all based on
>    the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>    (ECDHE_PSK) key exchange together with the Authenticated Encryption
>    with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>    provides light and efficient authentication, ECDHE provides perfect
>    forward secrecy, and AES-GCM and AES-CCM provides encryption and
>    integrity protection.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Thu May  4 15:00:18 2017
Return-Path: 
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 C64F1129AF2 for ; Thu,  4 May 2017 15:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0UdHVzkYReaQ for ; Thu,  4 May 2017 15:00:14 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625A6129508 for ; Thu,  4 May 2017 15:00:14 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id k74so22659423qke.1 for ; Thu, 04 May 2017 15:00:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kTgIwn8wpU7C7DYateKJmma+nszfUL0lWas6H5Coarw=; b=mOkd79c0AGHHtZIK1tKZEtglXeW/1O2tKhAxxAL1OUJre2PBy0cGPkbNIfaB8wdnyx O+jFQpmvv0ZaCA0l7+H3ox2ahGhlBctzGAGEJULIBc8hEXqB8PurHxiWydmU/B/eAMxH Ssjr3gEFvVn6COM+q3MLE7ZfW0fWSwTnW0hmIPI9BcsV/lTBHcV9vRm80jZWjADI1za/ iHL4B7SasOlT4UW0hyhuAeaA8cowOW/nXufL3yHRSpk3e+csK6hzUjX0IVH5YQ3PRBHP 3x9Q8D4DspGliC7VpoKH6NSjNBheVrvperf3NynTlVCg6zTJ/9b4PPc/jmDHWLbAVsQ7 Q2nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kTgIwn8wpU7C7DYateKJmma+nszfUL0lWas6H5Coarw=; b=Lfha6GGdOxV8EosfEmWrR0IXCM6meuxwUfaP8bYIHIKf3+SWKdWeTJLSHbzVukqLr/ GKOMDBAirRArtRecgAjxYhuy1kCufcqMCvA2aLQfPoNx10HGgIVCb2AXya1gsfA2oU0r sXnmhcekvTsDG+M1JwO6b6/yegWvqfnDbabduKj8nWYNoo5Uc0VrQdNuNE5CvSQozWoj mHPql64ZHD8w8S+GGtZa3Hh6cqUvWOH6k8NJ5dMwFE/P69kLg/Nf+9/1AABi+whe18aP LDhUuOj7UfLYUi1mBii1Y740jM24FfGaiHLzNuiVEulW0Cx18XlMcLR9yupE7ah+P+xw v+sQ==
X-Gm-Message-State: AODbwcDDfgTx74IKnu0aVuY9r0Zy26bgjCRtglb+OWZQrFSC6BcCG1OY GK091dUgFHrAX8c016o9xah4Dsyyg+Mv
X-Received: by 10.55.135.132 with SMTP id j126mr10022040qkd.266.1493935213610;  Thu, 04 May 2017 15:00:13 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.12.172.151 with HTTP; Thu, 4 May 2017 15:00:13 -0700 (PDT)
In-Reply-To: 
References:    
From: Erik Nygren 
Date: Thu, 4 May 2017 18:00:13 -0400
X-Google-Sender-Auth: NNK8mhZoSQnUtjDhKuWx2EmDAYI
Message-ID: 
To: Eric Rescorla 
Cc: Kyle Nekritz , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c07631eb98dbd054eb9e5d4
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 22:00:17 -0000

--94eb2c07631eb98dbd054eb9e5d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla  wrote:

>
>
>
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
>
>> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explainin=
g
>> both session-cache and strike register styles and the merits of each.
>>
>>
>>
>> First, a point of clarification, I think two issues have been conflated
>> in this long thread:
>>
>> 1) Servers rejecting replayed 0-RTT data (using a single use session
>> cache/strike register/replay cache/some other method)
>>
>>
>>
>> There are definitely cases (i.e. application profiles) where this should
>> be done. I think a general case HTTPS server is one. But I don=E2=80=99t=
 think this
>> is strictly necessary across the board (for every application using 0-RT=
T
>> at all). DNS was brought up earlier in this thread as an example of a
>> protocol that is likely quite workable without extra measures to prevent
>> replay.
>>
>>
>>
>> We already state =E2=80=9CProtocols MUST NOT use 0-RTT data without a pr=
ofile
>> that defines its use.=E2=80=9D. We could also describe methods that may =
be used to
>> provide further replay protection. But I don=E2=80=99t think it=E2=80=99=
s appropriate to
>> make a blanket requirement that *all* application protocols should requi=
re
>> it.
>>
>>
>>
>> I also consider it quite misleading to say TLS 1.3 is insecure without
>> such a recommendation. Uses of TLS can be insecure, that does not mean t=
he
>> protocol itself is. It=E2=80=99s insecure to use TLS without properly
>> authenticating the server. Some users of TLS do not do this correctly. I=
=E2=80=99d
>> actually argue that it is easier to mess this up than it is to mess up a
>> 0-RTT deployment (and it can result in worse consequences). That doesn=
=E2=80=99t
>> mean we should require a particular method of authentication, for all us=
es
>> of TLS.
>>
>
> I think this is basically right. In the PR I just posted, I spent most of
> my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanism=
s.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one
> of these mitigations?
>

I generally agree with Kyle here (and also added a few minor comments to
the PR).
I think we should be clear where the responsibilities generally lie as
well, for example:

"The onus is on clients not to send messages in 0-RTT data which are not
safe to have replayed and which they would not be willing to retry across
multiple 1-RTT connections. The onus is on servers to protect themselves
against attacks employing 0-RTT data replication."

The server responsibility is a general property TLS can maintain while the
client responsibility requires an application profile to define.

        Erik

--94eb2c07631eb98dbd054eb9e5d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, May 4, 2017 at 5:37 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <=
knekritz@fb.com>=
; wrote:











> 1. A SHOULD-level requirement for server-side 0-RTT defense,=
 explaining both session-cache and strike register styles and the merits of=
 each.


=C2=A0


First, a point of clarification, I think two issues have b=
een conflated in this long thread:


1) Servers rejecting replayed 0-RTT data (using a single use sess=
ion cache/strike register/replay cache/some other method)


=C2=A0


There are definitely cases (i.e. application profiles) where this=
 should be done. I think a general case HTTPS server is one. But I don=E2=
=80=99t think this is strictly necessary across
 the board (for every application using 0-RTT at all). DNS was brought up e=
arlier in this thread as an example of a protocol that is likely quite work=
able without extra measures to prevent replay.



=C2=A0


We already state =E2=80=9CProtocols MUST NOT use 0-RTT data witho=
ut a profile that defines its use.=E2=80=9D. We could also describe methods=
 that may be used to provide further replay protection.
 But I don=E2=80=99t think it=E2=80=99s appropriate to make a blanket requi=
rement that *all* application protocols should require it.


=C2=A0


I also consider it quite misleading to say TLS 1.3 is insecure wi=
thout such a recommendation. Uses of TLS can be insecure, that does not mea=
n the protocol itself is. It=E2=80=99s insecure
 to use TLS without properly authenticating the server. Some users of TLS d=
o not do this correctly. I=E2=80=99d actually argue that it is easier to me=
ss this up than it is to mess up a 0-RTT deployment (and it can result in w=
orse consequences). That doesn=E2=80=99t mean we
 should require a particular method of authentication, for all uses of TLS.=


I think this=
 is basically right. In the PR I just posted, I spent most of my time descr=
ibing the
mechanisms and used a SHOULD-level requirement to do on=
e of the mechanisms.
I think there's a bunch of room to words=
mith the requirement. Perhaps we say:

- You can=
9;t do 0-RTT without an application profile
- Absent the applicat=
ion profile saying otherwise you SHOULD/MUST do one of these mitigations?

I generally agree wi=
th Kyle here (and also added a few minor comments to the PR).=C2=A0 
I think we should be clear where the responsibilities generally lie=
 as well, for example:

"The onus is on clients not to send mess=
ages in 0-RTT data which are not
 safe to have replayed and which they would not be willing to retry=20
across multiple 1-RTT connections.  The onus is on servers to protect=20
themselves against attacks employing 0-RTT data replication."

<=
/div>
The server responsibility is a general property TLS can maintain =
while the client responsibility requires an application profile to define.=
=C2=A0 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


--94eb2c07631eb98dbd054eb9e5d4--


From nobody Thu May  4 15:04:04 2017
Return-Path: 
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 01F34127286 for ; Thu,  4 May 2017 15:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 McM0k-nvr8ED for ; Thu,  4 May 2017 15:04:01 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A94F129469 for ; Thu,  4 May 2017 15:04:00 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id s22so7020248ybe.3 for ; Thu, 04 May 2017 15:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nkixfKtJqTf0zCCoJG25HMrUfBVtTng61f9CyfoolF8=; b=p6M8GDun6pCFuHbbhG+0ASrg6KCoCXd8EFLrr2SKxzx2qli7+GKk148EFE9cc1keqH 3ynzKqivdr3156AxH+ZRFOznD+0MoY/bP2uI8x0goBCOWp/pHTWgE37h3hD0SlOmLgCU N0iJPY75DXPNpWjcuGYI/NQuAeXPMwzMgA2ZJwN6krpT/CY+WMQB7+RqEftFwvmfOX9D bQ2OU2i5Pzgsy2N8jXE2PyUzWnJYrlDf/oi/HtCpyPadXNebZKIvqjgm0XX9h4qtwQuC T7HZoG5SXl8y3X2rQ5+BdnuaqVUXf8j51vqFOrECHgLlia2DwLQRU5mLI2mjlzfoJSm4 bwUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nkixfKtJqTf0zCCoJG25HMrUfBVtTng61f9CyfoolF8=; b=Q2Xno6Fu4a90c/Ot13OoSVuWoGCsOi41qH9JVlESkgTdRPevEWsbmpEirY5Q+ZhGII uCkeoAKi85gjEWWFcU64PObfqpsz/HlLj1Oz9aufEZZGGJGYAgkyDLhDZlfgXsZaAPaj bJvnWexqptX3NZkaPihr2n215tF3k7u234IaNtL0Hb9zjkFGeIPwee3rmaTsJeXa9NF6 qBq76vWLG0V3o5oSIu4RhF3FLWYfGwtS24JoKtGpFfsgOV9y43K+KL1vlwYc6SBqUICX xTL5A3zlBg4swCMwbr3XHbSACwaSzJdfx+4lqDzcX0fSL8YZrS44qHCl0agH5agsOB/9 RUMQ==
X-Gm-Message-State: AN3rC/797JD+UQvlXxPCddI+DOGEOPvU7dZxpQFwwoBXTerMYXD2OeIi Wew3yAJ5SqfjsT6K2o43D6h6mKDXZQO0
X-Received: by 10.37.161.196 with SMTP id a62mr37467093ybi.9.1493935439832; Thu, 04 May 2017 15:03:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 4 May 2017 15:03:19 -0700 (PDT)
In-Reply-To: 
References:     
From: Eric Rescorla 
Date: Thu, 4 May 2017 15:03:19 -0700
Message-ID: 
To: Erik Nygren 
Cc: Kyle Nekritz , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045c5632358deb054eb9f3be
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 22:04:03 -0000

--f403045c5632358deb054eb9f3be
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 3:00 PM, Erik Nygren  wrote:

> On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla  wrote:
>
>>
>>
>>
>> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
>>
>>> > 1. A SHOULD-level requirement for server-side 0-RTT defense,
>>> explaining both session-cache and strike register styles and the merits=
 of
>>> each.
>>>
>>>
>>>
>>> First, a point of clarification, I think two issues have been conflated
>>> in this long thread:
>>>
>>> 1) Servers rejecting replayed 0-RTT data (using a single use session
>>> cache/strike register/replay cache/some other method)
>>>
>>>
>>>
>>> There are definitely cases (i.e. application profiles) where this shoul=
d
>>> be done. I think a general case HTTPS server is one. But I don=E2=80=99=
t think this
>>> is strictly necessary across the board (for every application using 0-R=
TT
>>> at all). DNS was brought up earlier in this thread as an example of a
>>> protocol that is likely quite workable without extra measures to preven=
t
>>> replay.
>>>
>>>
>>>
>>> We already state =E2=80=9CProtocols MUST NOT use 0-RTT data without a p=
rofile
>>> that defines its use.=E2=80=9D. We could also describe methods that may=
 be used to
>>> provide further replay protection. But I don=E2=80=99t think it=E2=80=
=99s appropriate to
>>> make a blanket requirement that *all* application protocols should requ=
ire
>>> it.
>>>
>>>
>>>
>>> I also consider it quite misleading to say TLS 1.3 is insecure without
>>> such a recommendation. Uses of TLS can be insecure, that does not mean =
the
>>> protocol itself is. It=E2=80=99s insecure to use TLS without properly
>>> authenticating the server. Some users of TLS do not do this correctly. =
I=E2=80=99d
>>> actually argue that it is easier to mess this up than it is to mess up =
a
>>> 0-RTT deployment (and it can result in worse consequences). That doesn=
=E2=80=99t
>>> mean we should require a particular method of authentication, for all u=
ses
>>> of TLS.
>>>
>>
>> I think this is basically right. In the PR I just posted, I spent most o=
f
>> my time describing the
>> mechanisms and used a SHOULD-level requirement to do one of the
>> mechanisms.
>> I think there's a bunch of room to wordsmith the requirement. Perhaps we
>> say:
>>
>> - You can't do 0-RTT without an application profile
>> - Absent the application profile saying otherwise you SHOULD/MUST do one
>> of these mitigations?
>>
>
> I generally agree with Kyle here (and also added a few minor comments to
> the PR).
> I think we should be clear where the responsibilities generally lie as
> well, for example:
>
> "The onus is on clients not to send messages in 0-RTT data which are not
> safe to have replayed and which they would not be willing to retry across
> multiple 1-RTT connections. The onus is on servers to protect themselves
> against attacks employing 0-RTT data replication."
>
> The server responsibility is a general property TLS can maintain while th=
e
> client responsibility requires an application profile to define.
>

These seem like good changes. I will work to incorporate them.

-Ekr


>
>         Erik
>
>

--f403045c5632358deb054eb9f3be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 3:00 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
On Thu,=
 May 4, 2017 at 5:37 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">



On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <knekr=
itz@fb.com> wrote:











> 1. A SHOULD-level requirement for server-side 0-RTT defense,=
 explaining both session-cache and strike register styles and the merits of=
 each.


=C2=A0


First, a point of clarification, I think two issues have b=
een conflated in this long thread:


1) Servers rejecting replayed 0-RTT data (using a single use sess=
ion cache/strike register/replay cache/some other method)


=C2=A0


There are definitely cases (i.e. application profiles) where this=
 should be done. I think a general case HTTPS server is one. But I don=E2=
=80=99t think this is strictly necessary across
 the board (for every application using 0-RTT at all). DNS was brought up e=
arlier in this thread as an example of a protocol that is likely quite work=
able without extra measures to prevent replay.



=C2=A0


We already state =E2=80=9CProtocols MUST NOT use 0-RTT data witho=
ut a profile that defines its use.=E2=80=9D. We could also describe methods=
 that may be used to provide further replay protection.
 But I don=E2=80=99t think it=E2=80=99s appropriate to make a blanket requi=
rement that *all* application protocols should require it.


=C2=A0


I also consider it quite misleading to say TLS 1.3 is insecure wi=
thout such a recommendation. Uses of TLS can be insecure, that does not mea=
n the protocol itself is. It=E2=80=99s insecure
 to use TLS without properly authenticating the server. Some users of TLS d=
o not do this correctly. I=E2=80=99d actually argue that it is easier to me=
ss this up than it is to mess up a 0-RTT deployment (and it can result in w=
orse consequences). That doesn=E2=80=99t mean we
 should require a particular method of authentication, for all uses of TLS.=


I think this=
 is basically right. In the PR I just posted, I spent most of my time descr=
ibing the
mechanisms and used a SHOULD-level requirement to do on=
e of the mechanisms.
I think there's a bunch of room to words=
mith the requirement. Perhaps we say:

- You can=
9;t do 0-RTT without an application profile
- Absent the applicat=
ion profile saying otherwise you SHOULD/MUST do one of these mitigations?

I generally a=
gree with Kyle here (and also added a few minor comments to the PR).=C2=A0 =

I think we should be clear where the responsibilities genera=
lly lie as well, for example:

"The onus is on clients not to se=
nd messages in 0-RTT data which are not
 safe to have replayed and which they would not be willing to retry=20
across multiple 1-RTT connections.  The onus is on servers to protect=20
themselves against attacks employing 0-RTT data replication."

<=
/div>
The server responsibility is a general property TLS can maintain =
while the client responsibility requires an application profile to define.=
=C2=A0 

These s=
eem like good changes. I will work to incorporate them.

-Ekr
=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Erik






--f403045c5632358deb054eb9f3be--


From nobody Thu May  4 15:04:25 2017
Return-Path: 
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 1DBE0129469 for ; Thu,  4 May 2017 15:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level: 
X-Spam-Status: No, score=-0.721 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=lvHHU8Sl; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ODKhPAg+
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 TgJQgoUAf2Lf for ; Thu,  4 May 2017 15:04:13 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2DB129AEB for ; Thu,  4 May 2017 15:04:12 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v44M3m6h022102; Thu, 4 May 2017 15:04:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=mIG0flS3rjN17JXsfls+JjaU+yDjwtS8lF/SNDOnBzg=; b=lvHHU8Sl4GmkaCAzh7lK2r3G6Ixn8aYlH/IHFSFR+s2ZIpVupHAkCSWfO41JYMNiRGgL Lv3346CCz6XtbeAcm341Lngo01x9SkvHrcDwHRe612ptB9jEYgUMEcFh0CDzhUlxv6HQ 0gCHessjdoGkHsFMk4WDVCesSjcxG5/FL6c= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2a89rcrrck-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 04 May 2017 15:04:09 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 4 May 2017 15:04:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=mIG0flS3rjN17JXsfls+JjaU+yDjwtS8lF/SNDOnBzg=; b=ODKhPAg+n/o99IHqycrvJfV8E00lqZpGsakCMk229Tu6wSPBUyfX9YWxjx8m5QzMJwMmjlMhNpGJ8vh8tv4e/UQcgdz4qntu20a3aGwJ6X2mynRi7tLQ/ew+CVUDb0Kv91MuAt5Ifqys7Vj2tesHeASs02E/DfnLGLe4mHZHCqQ=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 22:04:05 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.1061.022; Thu, 4 May 2017 22:04:05 +0000
From: Kyle Nekritz 
To: Eric Rescorla 
CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "tls@ietf.org" 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NWfzhsEfLgEUy3mG3N+R1DLqHjghwAgADwDPCAAERoAIAAA4ig
Date: Thu, 4 May 2017 22:04:05 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=fb.com;
x-originating-ip: [2620:10d:c091:200::2:713]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 7:bdwNxr9IhWyba6FQR5yAWvC4fvq5jYS4JTnS6c4OEbvbTH7NfOPqlSpuSTrXYRIEqswMEMoxHZe4t9FVG0gY1FnU6mFm5jaoEaM7FOXCEtCAhyvw7veFfdhP7wEUCgjOLJe3cdMpwNo8ektjvsVu+INH+kh3ho+g4C3FNeWfKfbmXd+EXRl0gag5wdJ9vE4d6L+e8s9V3Ge+ISutuPlPJ9ncSJY1tOjcDWdbstRHjfNY41gVxwTQCFFNMz9ASixnEfir7SvpqTfp2jMjjo4j9B4rCnyxLJ7dEBx74DQn6xWL/Uiw6cvPqFfPd/eP18aIF4cXEw8Js7WR3Mr/exfQeA==; 20:3esukrEztrMIX7pHyLJRmUgSgqud6PUyjiRiuFKd/hLfts6whW/v9/j54MWPype0RRRUkr0obwZFdDQ9zNQrEhyxVk+GMEn7w3PApDKyenMgJoo89/Ln78fhxxF4KRcYgDqSJypOgRqvEg+Yw4O9Iz7XdJMQv/Qjq9bgHkM10xQ=
x-ms-office365-filtering-correlation-id: 32c98b57-de53-40cf-0666-08d493397b41
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1182; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(166708455590820)(192374486261705)(67672495146484)(21748063052155)(64217206974132)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148); SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182; 
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(24454002)(377454003)(2906002)(77096006)(3660700001)(53546009)(3280700002)(25786009)(99286003)(54356999)(86362001)(76176999)(50986999)(19609705001)(4326008)(38730400002)(110136004)(189998001)(6246003)(93886004)(6506006)(55016002)(54906002)(33656002)(7110500001)(6306002)(6436002)(606005)(53936002)(54896002)(9686003)(7696004)(7906003)(236005)(74316002)(2950100002)(2900100001)(8936002)(7736002)(6916009)(102836003)(5660300001)(6116002)(15650500001)(122556002)(81166006)(478600001)(2420400007)(8676002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182C6745F7581005DD447A9AFEA0MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 22:04:05.3748 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_14:, , signatures=0
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 22:04:24 -0000

--_000_MWHPR15MB1182C6745F7581005DD447A9AFEA0MWHPR15MB1182namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WWVwLCBJIHRoaW5rIHlvdXIgUFIgaXMgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4NCg0KPiBJIGhh
dmUgYmVlbiBiYXNpY2FsbHkgYXNzdW1pbmcgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5IGRvIFRMUyB3
aXRob3V0IGEgcmVhbC10aW1lIGNsb2NrLCBidXQgbWF5YmUgdGhhdCdzIHdyb25nPw0KDQpXZWxs
LCBpdOKAmXMgcG9zc2libGUsIGFsdGhvdWdoIEkgZG8gbm90IGtub3cgaWYgYW55b25lIGFjdHVh
bGx5IGRvZXMgKGFuZCBvZiBjb3Vyc2UgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiB3b3VsZCBiZSBh
IGxpdHRsZSBjaGFsbGVuZ2luZykuIE1heWJlIHNvbWVvbmUgZnJvbSB0aGUgZW1iZWRkZWQgY3Jv
d2QgY2FuIGVubGlnaHRlbiB1cy4NCg0KPiAiRm9yIGlkZW50aXRpZXMgZXN0YWJsaXNoZWQgZXh0
ZXJuYWxseSBhbiBvYmZ1c2NhdGVkX3RpY2tldF9hZ2Ugb2YgMCBTSE9VTEQgYmUgdXNlZCwgYW5k
IHNlcnZlcnMgTVVTVCBpZ25vcmUgdGhlIHZhbHVlLiINCg0KQWgsIEkgaGFkIG1pc3NlZCB0aGF0
LiBJIHRoaW5rIHRoZSBNVVNUIG1pZ2h0IGJlIGEgbGl0dGxlIHN0cm9uZyB0aGVyZSwgZXZlbiB3
aXRob3V0IGRpcmVjdCBpbnZvbHZlbWVudCBvZiB0aGUgc2VydmVyIGluIGlzc3VpbmcgdGhlIGV4
dGVybmFsIFBTSyB0aGUgdGlja2V0IGFnZSBjYW4gc3RpbGwgYmUgdXNlZnVsLCBmb3IgZXhhbXBs
ZSB1c2luZyBhIHNpbWlsYXIgbWV0aG9kIHdlIHVzZSB3aXRoIFplcm8gUHJvdG9jb2wgKFRpbWUt
Ym91bmQgMC1SVFQgZGF0YSBzZWN0aW9uIG9mIGh0dHBzOi8vY29kZS5mYWNlYm9vay5jb20vcG9z
dHMvNjA4ODU0OTc5MzA3MTI1L2J1aWxkaW5nLXplcm8tcHJvdG9jb2wtZm9yLWZhc3Qtc2VjdXJl
LW1vYmlsZS1jb25uZWN0aW9ucy8gKS4NCg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVr
ckBydGZtLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXkgNCwgMjAxNyA1OjM3IFBNDQpUbzogS3ls
ZSBOZWtyaXR6IDxrbmVrcml0ekBmYi5jb20+DQpDYzogQ29sbSBNYWNDw6FydGhhaWdoIDxjb2xt
QGFsbGNvc3RzLm5ldD47IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFNlY3VyaXR5
IHJldmlldyBvZiBUTFMxLjMgMC1SVFQNCg0KDQoNCk9uIFRodSwgTWF5IDQsIDIwMTcgYXQgMjoy
NyBQTSwgS3lsZSBOZWtyaXR6IDxrbmVrcml0ekBmYi5jb208bWFpbHRvOmtuZWtyaXR6QGZiLmNv
bT4+IHdyb3RlOg0KPiAxLiBBIFNIT1VMRC1sZXZlbCByZXF1aXJlbWVudCBmb3Igc2VydmVyLXNp
ZGUgMC1SVFQgZGVmZW5zZSwgZXhwbGFpbmluZyBib3RoIHNlc3Npb24tY2FjaGUgYW5kIHN0cmlr
ZSByZWdpc3RlciBzdHlsZXMgYW5kIHRoZSBtZXJpdHMgb2YgZWFjaC4NCg0KRmlyc3QsIGEgcG9p
bnQgb2YgY2xhcmlmaWNhdGlvbiwgSSB0aGluayB0d28gaXNzdWVzIGhhdmUgYmVlbiBjb25mbGF0
ZWQgaW4gdGhpcyBsb25nIHRocmVhZDoNCjEpIFNlcnZlcnMgcmVqZWN0aW5nIHJlcGxheWVkIDAt
UlRUIGRhdGEgKHVzaW5nIGEgc2luZ2xlIHVzZSBzZXNzaW9uIGNhY2hlL3N0cmlrZSByZWdpc3Rl
ci9yZXBsYXkgY2FjaGUvc29tZSBvdGhlciBtZXRob2QpDQoNClRoZXJlIGFyZSBkZWZpbml0ZWx5
IGNhc2VzIChpLmUuIGFwcGxpY2F0aW9uIHByb2ZpbGVzKSB3aGVyZSB0aGlzIHNob3VsZCBiZSBk
b25lLiBJIHRoaW5rIGEgZ2VuZXJhbCBjYXNlIEhUVFBTIHNlcnZlciBpcyBvbmUuIEJ1dCBJIGRv
buKAmXQgdGhpbmsgdGhpcyBpcyBzdHJpY3RseSBuZWNlc3NhcnkgYWNyb3NzIHRoZSBib2FyZCAo
Zm9yIGV2ZXJ5IGFwcGxpY2F0aW9uIHVzaW5nIDAtUlRUIGF0IGFsbCkuIEROUyB3YXMgYnJvdWdo
dCB1cCBlYXJsaWVyIGluIHRoaXMgdGhyZWFkIGFzIGFuIGV4YW1wbGUgb2YgYSBwcm90b2NvbCB0
aGF0IGlzIGxpa2VseSBxdWl0ZSB3b3JrYWJsZSB3aXRob3V0IGV4dHJhIG1lYXN1cmVzIHRvIHBy
ZXZlbnQgcmVwbGF5Lg0KDQpXZSBhbHJlYWR5IHN0YXRlIOKAnFByb3RvY29scyBNVVNUIE5PVCB1
c2UgMC1SVFQgZGF0YSB3aXRob3V0IGEgcHJvZmlsZSB0aGF0IGRlZmluZXMgaXRzIHVzZS7igJ0u
IFdlIGNvdWxkIGFsc28gZGVzY3JpYmUgbWV0aG9kcyB0aGF0IG1heSBiZSB1c2VkIHRvIHByb3Zp
ZGUgZnVydGhlciByZXBsYXkgcHJvdGVjdGlvbi4gQnV0IEkgZG9u4oCZdCB0aGluayBpdOKAmXMg
YXBwcm9wcmlhdGUgdG8gbWFrZSBhIGJsYW5rZXQgcmVxdWlyZW1lbnQgdGhhdCAqYWxsKiBhcHBs
aWNhdGlvbiBwcm90b2NvbHMgc2hvdWxkIHJlcXVpcmUgaXQuDQoNCkkgYWxzbyBjb25zaWRlciBp
dCBxdWl0ZSBtaXNsZWFkaW5nIHRvIHNheSBUTFMgMS4zIGlzIGluc2VjdXJlIHdpdGhvdXQgc3Vj
aCBhIHJlY29tbWVuZGF0aW9uLiBVc2VzIG9mIFRMUyBjYW4gYmUgaW5zZWN1cmUsIHRoYXQgZG9l
cyBub3QgbWVhbiB0aGUgcHJvdG9jb2wgaXRzZWxmIGlzLiBJdOKAmXMgaW5zZWN1cmUgdG8gdXNl
IFRMUyB3aXRob3V0IHByb3Blcmx5IGF1dGhlbnRpY2F0aW5nIHRoZSBzZXJ2ZXIuIFNvbWUgdXNl
cnMgb2YgVExTIGRvIG5vdCBkbyB0aGlzIGNvcnJlY3RseS4gSeKAmWQgYWN0dWFsbHkgYXJndWUg
dGhhdCBpdCBpcyBlYXNpZXIgdG8gbWVzcyB0aGlzIHVwIHRoYW4gaXQgaXMgdG8gbWVzcyB1cCBh
IDAtUlRUIGRlcGxveW1lbnQgKGFuZCBpdCBjYW4gcmVzdWx0IGluIHdvcnNlIGNvbnNlcXVlbmNl
cykuIFRoYXQgZG9lc27igJl0IG1lYW4gd2Ugc2hvdWxkIHJlcXVpcmUgYSBwYXJ0aWN1bGFyIG1l
dGhvZCBvZiBhdXRoZW50aWNhdGlvbiwgZm9yIGFsbCB1c2VzIG9mIFRMUy4NCg0KSSB0aGluayB0
aGlzIGlzIGJhc2ljYWxseSByaWdodC4gSW4gdGhlIFBSIEkganVzdCBwb3N0ZWQsIEkgc3BlbnQg
bW9zdCBvZiBteSB0aW1lIGRlc2NyaWJpbmcgdGhlDQptZWNoYW5pc21zIGFuZCB1c2VkIGEgU0hP
VUxELWxldmVsIHJlcXVpcmVtZW50IHRvIGRvIG9uZSBvZiB0aGUgbWVjaGFuaXNtcy4NCkkgdGhp
bmsgdGhlcmUncyBhIGJ1bmNoIG9mIHJvb20gdG8gd29yZHNtaXRoIHRoZSByZXF1aXJlbWVudC4g
UGVyaGFwcyB3ZSBzYXk6DQoNCi0gWW91IGNhbid0IGRvIDAtUlRUIHdpdGhvdXQgYW4gYXBwbGlj
YXRpb24gcHJvZmlsZQ0KLSBBYnNlbnQgdGhlIGFwcGxpY2F0aW9uIHByb2ZpbGUgc2F5aW5nIG90
aGVyd2lzZSB5b3UgU0hPVUxEL01VU1QgZG8gb25lIG9mIHRoZXNlIG1pdGlnYXRpb25zPw0KDQoN
CjIpIFByZXZlbnRpbmcgY2xpZW50cyBmcm9tIHNlbmRpbmcgMC1SVFQgZGF0YSBtdWx0aXBsZSB0
aW1lcyAob24gc2VwYXJhdGUgY29ubmVjdGlvbnMpIHVzaW5nIHRoZSBzYW1lIFBTSyAoZm9yIGZv
cndhcmQgc2VjcmVjeSByZWFzb25zKQ0KDQpJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFsbG93ZWQu
IE90aGVyd2lzZSwgY2xpZW50cyB3aWxsIG5vdCBiZSBhYmxlIHRvIHJldHJ5IDAtUlRUIHJlcXVl
c3RzIHRoYXQgZmFpbCBkdWUgdG8gYW4gdW5rbm93biBuZXR3b3JrIGVycm9yIHByaW9yIHRvIHJl
Y2VpdmluZyBhIE5TVCAoaWYgdGhleSBhcmUgb3V0IG9mIGNhY2hlZCBQU0tzKS4gSeKAmWQgZXhw
ZWN0IHRoZSBuZWVkIGZvciB0aGVzZSByZXRyaWVzIHRvIGJlIGxhcmdlciB3aXRoIDAtUlRUIGRh
dGEsIHBhcnRpY3VsYXJseSB3aGVuIDAtUlRUIGRhdGEgaXMgc2VudCB3aXRob3V0IGV2ZW4gYSB0
cmFuc3BvcnQgcm91bmR0cmlwIChpbiB0aGUgY2FzZSBvZiBURk8gb3IgUVVJQykuIFNlcnZlcnMg
YXJlIGRlZmluaXRlbHkgbm90IHJlcXVpcmVkIHRvIGFjY2VwdCBtdWx0aXBsZSAwLVJUVCBjb25u
ZWN0aW9ucyB1c2luZyB0aGUgc2FtZSBQU0ssIGJ1dCBJIGRvbuKAmXQgdGhpbmsgY2xpZW50cyBz
aG91bGQgYmUgYmFubmVkIGZyb20gYXR0ZW1wdGluZy4NCg0KSSBhZ3JlZSwgYW5kIHRoZSBQUiBJ
IHByb3ZpZGVkIGRvZXNuJ3QgYXR0ZW1wdCB0byBkbyBzby4NCg0KDQo+IDQuIEkgd291bGQgYWRk
IHRvIHRoaXMgdGhhdCB3ZSByZWNvbW1lbmQgdGhhdCBwcm94eS9DRE4gaW1wbGVtZW50YXRpb25z
IHNpZ25hbCB3aGljaCBkYXRhIGlzIDAtUlRUIGFuZCB3aGljaCBpcyAxLVJUVCB0byB0aGUgYmFj
ay1lbmQgKHRoaXMgd2FzIGluIENvbG0ncyBvcmlnaW5hbCBtZXNzYWdlKS4NCg0KSeKAmW0gbm90
IHN1cmUgdGhhdCB0aGUgVExTIDEuMyBzcGVjIGlzIHRoZSByaWdodCBwbGFjZSB0byBtYWtlIHJl
Y29tbWVuZGF0aW9ucyBmb3IgdGhpcy4gSSBjYW4gc2VlIHNldmVyYWwgcmVhc29uYWJsZSBhcHBy
b2FjaGVzIGhlcmUsIGZvciBleGFtcGxlOg0KLSBBZGRpbmcgc29tZSBraW5kIG9mIGFwcGxpY2F0
aW9uIGxldmVsIGFubm90YXRpb24gKGZvciBleGFtcGxlIGFuIEhUVFAgaGVhZGVyKQ0KLSBSb2J1
c3RseSBwcmV2ZW50aW5nIHJlcGxheSBvbiB0aGUgMC1SVFQgaG9wDQotIFNlbmRpbmcgcHJveGll
ZCBlYXJseSBkYXRhIHdpdGggYSBkaWZmZXJlbnQgVExTIENvbnRlbnRUeXBlLCBldGMuDQpJIGRv
buKAmXQgc2VlIGEgbmVlZCB0byBzcGVjaWZpY2FsbHkgZW5kb3JzZSBhbnkgcGFydGljdWxhciBt
ZXRob2QgaGVyZS4NCg0KSSB0aGluayBDb2xtIGhhcyBhbHNvIGFncmVlZCB3ZSBzaG91bGRuJ3Qg
ZG8gdGhpcyBhbmQgaXQncyBub3QgaW4gbXkgUFIuDQoNCg0KDQpUaGVyZSB3YXMgYWxzbyBhIHBv
aW50IGJyb3VnaHQgdXAgYWJvdXQgdGhlIHVzZSBvZiB0aWNrZXRfYWdlIHdpdGhvdXQgMC1SVFQu
IEnigJltIG5vdCBhd2FyZSBvZiBhbnkgdXNlIGZvciB0aWNrZXRfYWdlIG90aGVyIHRoYW4gMC1S
VFQgcmVwbGF5IHByb3RlY3Rpb24uIEkgYmVsaWV2ZSB0aGF0IHRpY2tldF9hZ2UgaXMgc2VudCB3
aXRoIGFsbCBQU0tzIG1vc3RseSBvdXQgb2YgY29udmVuaWVuY2UvY29uc2lzdGVuY3kuIEkgZG9u
4oCZdCByZWFsbHkgaGF2ZSBhbiBvYmplY3Rpb24gdG8gdGhlIGN1cnJlbnQgbWV0aG9kLCBidXQg
SSBhbHNvIHdvdWxkbuKAmXQgYmUgb3Bwb3NlZCB0byBtb3ZpbmcgdGhlIHRpY2tldCBhZ2UgdG8g
dGhlIGVhcmx5IGRhdGEgZXh0ZW5zaW9uLCBzbyB0aGF0IGl0IGlzIG9ubHkgc2VudCBhbG9uZyB3
aXRoIDAtUlRUIGRhdGEuDQoNCkkgd291bGQgYmUgT0sgd2l0aCB0aGlzIGFzIHdlbGwuIEl0IGRv
ZXMgc2VlbSBzbGlnaHRseSBtb3JlIGVsZWdhbnQuDQoNCg0KDQpJdCBhbHNvIHNlZW1zIGEgbGl0
dGxlIHVuZGVyLXNwZWNpZmllZCB3aGF0IGltcGxlbWVudGF0aW9ucyB1bmFibGUgdG8gY29tcHV0
ZSBhIHJlYXNvbmFibGUgdGlja2V0IGFnZSBzaG91bGQgc2VuZCAoZm9yIGV4YW1wbGUgaW4gdGhl
IGNhc2Ugb2YgYSBkZXZpY2Ugd2l0aG91dCBhIHJlYWwgdGltZSBjbG9jaywNCg0KUmlnaHQuIEkg
aGF2ZSBiZWVuIGJhc2ljYWxseSBhc3N1bWluZyB0aGF0IHlvdSBjYW4ndCByZWFsbHkgZG8gVExT
IHdpdGhvdXQgYSByZWFsLXRpbWUgY2xvY2ssIGJ1dCBtYXliZSB0aGF0J3Mgd3Jvbmc/DQoNCg0K
b3Igd2l0aCBhbiBleHRlcm5hbCBQU0spLg0KDQpUaGlzIGFjdHVhbGx5IGlzIHdlbGwtc3BlY2lm
aWVkICh0aG91Z2ggbWF5YmUgd3JvbmcpDQoiRm9yIGlkZW50aXRpZXMgZXN0YWJsaXNoZWQgZXh0
ZXJuYWxseSBhbiBvYmZ1c2NhdGVkX3RpY2tldF9hZ2Ugb2YgMCBTSE9VTEQgYmUgdXNlZCwgYW5k
IHNlcnZlcnMgTVVTVCBpZ25vcmUgdGhlIHZhbHVlLiINCmh0dHBzOi8vdGxzd2cuZ2l0aHViLmlv
L3RsczEzLXNwZWMvI3ByZS1zaGFyZWQta2V5LWV4dGVuc2lvbjxodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rsc3dnLmdpdGh1Yi5pb190bHMxMy0y
RHNwZWNfLTIzcHJlLTJEc2hhcmVkLTJEa2V5LTJEZXh0ZW5zaW9uJmQ9RHdNRmFRJmM9NVZEMFJU
dE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmbT0wMEQzNGVxeW9icVlz
bkgtMHgyc1FkQzhYbjFHQ3FIUUJGUHFQZVhFMGdnJnM9cGFjaEdMSlFFckpHOG5BSzVPS0o0TDNE
YTcwYklPMUJRbHl0ZGl1dWFOcyZlPT4NCg0KLUVrcg0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg
T2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMywgMjAxNyAxMToxMyBQTQ0K
VG86IENvbG0gTWFjQ8OhcnRoYWlnaCA8Y29sbUBhbGxjb3N0cy5uZXQ8bWFpbHRvOmNvbG1AYWxs
Y29zdHMubmV0Pj4NCkNjOiB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1Ympl
Y3Q6IFJlOiBbVExTXSBTZWN1cml0eSByZXZpZXcgb2YgVExTMS4zIDAtUlRUDQoNCltEZWxpYmVy
YXRlbHkgcmVzcG9uZGluZyB0byB0aGUgT1AgcmF0aGVyIHRoYW4gdG8gYW55b25lIGluIHBhcnRp
Y3VsYXJdDQoNCkhpIGZvbGtzLA0KDQpJJ20gc2VlaW5nIGEgbG90IG9mIGJhY2sgYW5kIGZvcnRo
IGFib3V0IGdlbmVyYWwgcGhpbG9zb3BoeSBhbmQgdGhlDQp3aXNkb20gb2YgMC1SVFQgYnV0IEkg
dGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIGlmIHdlIGZvY3VzZWQgb24gd2hhdA0KY2hhbmdlcywg
aWYgYW55LCB3ZSBuZWVkIHRvIG1ha2UgdG8gdGhlIGRyYWZ0Lg0KDQpJIG1hZGUgc29tZSBwcm9w
b3NhbHMgeWVzdGVyZGF5DQooaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90
bHMvY3VycmVudC9tc2cyMzA4OC5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl90bHNf
Y3VycmVudF9tc2cyMzA4OC5odG1sJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZy
PWwyajRCamtPMExjM3U0Q0gyejdqUHcmbT1fMkJFQ2Y5T2ZXMXIxYVJXckxfcFNiUWVLTXNoeU9t
Mk5JVldGNEdHQkkwJnM9WGdIYlV3VDZ1cEFzT2luNFQ2UDhlUHM4aTBaRnNuRC1fQk52dWVlcTgz
RSZlPT4pLg0KDQpTcGVjaWZpY2FsbHk6DQoxLiBBIFNIT1VMRC1sZXZlbCByZXF1aXJlbWVudCBm
b3Igc2VydmVyLXNpZGUgMC1SVFQgZGVmZW5zZSwgZXhwbGFpbmluZw0KYm90aCBzZXNzaW9uLWNh
Y2hlIGFuZCBzdHJpa2UgcmVnaXN0ZXIgc3R5bGVzIGFuZCB0aGUgbWVyaXRzIG9mIGVhY2guDQoN
CjIuIERvY3VtZW50IDAtUlRUIGdyZWFzaW5nIGluIGRyYWZ0LWlldGYtdGxzLWdyZWFzZQ0KDQoz
LiBBZG9wdCBQUiM0NDggKG9yIHNvbWUgdmFyaWFudCkgc28gdGhhdCBzZXNzaW9uLWlkIHN0eWxl
IGltcGxlbWVudGF0aW9ucw0KcHJvdmlkZSBQRlMuDQoNCjQuIEkgd291bGQgYWRkIHRvIHRoaXMg
dGhhdCB3ZSByZWNvbW1lbmQgdGhhdCBwcm94eS9DRE4gaW1wbGVtZW50YXRpb25zDQpzaWduYWwg
d2hpY2ggZGF0YSBpcyAwLVJUVCBhbmQgd2hpY2ggaXMgMS1SVFQgdG8gdGhlIGJhY2stZW5kICh0
aGlzIHdhcyBpbg0KQ29sbSdzIG9yaWdpbmFsIG1lc3NhZ2UpLg0KDQpCYXNlZCBvbiBDb2xtJ3Mg
cmVzcG9uc2UsIEkgdGhpbmsgdGhlc2UgbGFyZ2VseSBoaXRzIHRoZSBwb2ludHMgaGUgbWFkZQ0K
aW4gaGlzIG9yaWdpbmFsIG1lc3NhZ2UuDQoNClRoZXJlJ3MgYWxyZWFkeSBhIFBSIGZvciAjMyBh
bmQgSSdsbCBoYXZlIFBScyBmb3IgIzEgYW5kICM0IHRvbW9ycm93Lg0KV2hhdCB3b3VsZCBiZSBt
b3N0IGhlbHBmdWwgdG8gbWUgYXMgRWRpdG9yIHdvdWxkIGJlIGlmIHBlb3BsZSBjb3VsZCByZXZp
ZXcNCnRoZXNlIFBScyBhbmQvb3Igc3VnZ2VzdCBvdGhlciBzcGVjaWZpYyBjaGFuZ2VzIHRoYXQg
d2Ugc2hvdWxkIG1ha2UNCnRvIHRoZSBkb2N1bWVudC4NCg0KVGhhbmtzLA0KLUVrcg0KDQoNCg0K
DQpPbiBUdWUsIE1heSAyLCAyMDE3IGF0IDc6NDQgQU0sIENvbG0gTWFjQ8OhcnRoYWlnaCA8Y29s
bUBhbGxjb3N0cy5uZXQ8bWFpbHRvOmNvbG1AYWxsY29zdHMubmV0Pj4gd3JvdGU6DQpPbiBTdW5k
YXkgYXQgdGhlIFRMUzpESVYgd29ya3Nob3AgSSBwcmVzZW50ZWQgYSBzdW1tYXJ5IG9mIGZpbmRp
bmdzIG9mIGEgc2VjdXJpdHkgcmV2aWV3IHdlIGRpZCBvbiBUTFMxLjMgMC1SVFQsIGFzIHBhcnQg
b2YgaW1wbGVtZW50aW5nIDEuMyBpbiBzMm4uIFRoYW5rcyB0byBmZWVkYmFjayBpbiB0aGUgcm9v
bSBJJ3ZlIG5vdyB0aWdodGVuZWQgdXAgdGhlIGZpbmRpbmdzIGZyb20gdGhlIHJldmlldyBhbmQg
cG9zdGVkIHRoZW0gYXMgYW4gaXNzdWUgb24gdGhlIGRyYWZ0IEdpdEh1YiByZXBvOg0KDQpodHRw
czovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9pc3N1ZXMvMTAwMQ0KDQpJJ2xsIHN1bW1h
cml6ZSB0aGUgc3VtbWFyeTogTmF0dXJhbGx5IHRoZSBmb2N1cyB3YXMgb24gZm9yd2FyZCBzZWNy
ZWN5IGFuZCByZXBsYXkuIE9uIGZvcndhcmQgc2VjcmVjeSB0aGUgbWFpbiBmaW5kaW5nIHdhcyB0
aGF0IGl0J3Mgbm90IG5lY2Vzc2FyeSB0byB0cmFkZSBvZmYgRm9yd2FyZCBTZWNyZWN5IGFuZCAw
LVJUVC4gQSBzaW5nbGUtdXNlIHNlc3Npb24gY2FjaGUgY2FuIHByb3ZpZGUgaXQsIGFuZCB3aXRo
IHRoZSBtb2RpZmljYXRpb24gdGhhdCBla3IgaGFzIGNyZWF0ZWQgaW4gaHR0cHM6Ly9naXRodWIu
Y29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC85OTggLCBzdWNoIGEgY2FjaGUgd29ya3MgZm9yIGJv
dGggcHJlLWF1dGggYW5kIHBvc3QtYXV0aCB0aWNrZXRzLCBhbmQgaXQgYWxsb3dzIGNsaWVudHMg
dG8gYnVpbGQgdXAgcG9vbHMgb2YgbWVhbmluZ2Z1bGx5IGRpc3RpbmN0IHRpY2tldHMuDQoNClRo
ZXJlJ3MgYWxzbyBhbiBvYnNlcnZhdGlvbiB0aGVyZSB0aGF0IGl0IHNob3VsZCByZWFsbHkgYmUg
dGhhdCBjbGllbnRzICJNVVNUIiB1c2UgdGlja2V0cyBvbmx5IG9uY2UuIEFueSByZS11c2UgbGlr
ZWx5IGRpc2Nsb3NlcyB0aGUgb2JmdXNjYXRlZCB0aWNrZXQgYWdlLCB3aGljaCBpcyBpbnRlbmRl
ZCB0byBiZSBzZWNyZXQuIFJpZ2h0IG5vdyBpdCdzIGEgIlNIT1VMRCIuDQoNCk9uIHJlcGxheSwg
dGhlIG1haW4gZmluZGluZyBpcyB0aGF0IHdoYXQncyBpbiB0aGUgZHJhZnQgaXMgbm90IHdvcmth
Ymx5IHNlY3VyZSwgYW5kIHRoZSByZXZpZXcgaW5jbHVkZXMgNSBkaWZmZXJlbnQgYXR0YWNrcyBh
Z2FpbnN0IDAtUlRUIGRhdGEgdG8gaWxsdXN0cmF0ZSB0aGF0LiBBdHRhY2tzIDEgYW5kIDIgc2hv
dyB0aGF0IHRoZSBraW5kIG9mIHJlcGxheSBwZXJtaXR0ZWQgYnkgdGhlIGRyYWZ0IGlzIHZlcnkg
ZGlmZmVyZW50IGZyb20gdGhlIGtpbmQgb2YgcmVwbGF5IHBlcm1pdHRlZCBieSBka2cncyBleGlz
dGluZyBkb3duZ3JhZGUtYW5kLXJldHJ5IGF0dGFjay4gSSBhbHNvIGdvIG92ZXIgd2h5IGl0IHZl
cnkgdmVyeSBkaWZmaWN1bHQgdG8gbWFueSBhcHBsaWNhdGlvbnMgdG8gYWNoaWV2ZSB0aGF0IGlk
ZW1wb3RlbmN5LCBhbmQgd2h5IG9uZSBpZGVtcG90ZW5jeSBwYXR0ZXJuIGFjdHVhbGx5IHJlbGll
cyBvbiBub24tcmVwbGF5YWJsZSBtZXNzYWdlcy4NCg0KQXR0YWNrIDMgc2hvd3MgdGhhdCBpZGVt
cG90ZW5jeSBpcyBub3Qgc3VmZmljaWVudCwgYXBwbGljYXRpb25zIG11c3QgYWxzbyBiZSBmcmVl
IG9mIG1lYXN1cmFibGUgc2lkZS1lZmZlY3RzLCB3aGljaCBpcyBub3QgcHJhY3RpY2FsLiAgQXR0
YWNrIDQgc2hvd3MgdGhhdCAwLVJUVCBicmVha3MgYSBjb21tb24gc2VjdXJpdHkgbWVjaGFuaXNt
OiBzcG9vZmluZy1yZXNpc3RhbnQgdGhyb3R0bGVzLiBBdHRhY2sgNSBzaG93cyB0aGF0IDAtUlRU
IHJlcGxheS1hYmlsaXR5IGVuYWJsZXMgYW4gYWRkaXRpb25hbCBmb3JtIG9mIHRyYWZmaWMgYW5h
bHlzaXMuDQoNClRoZSByZWNvbW1lbmRhdGlvbiBpbiB0aGUgcmV2aWV3IGlzIHRoYXQgaW1wbGVt
ZW50YXRpb25zICJNVVNUIiBwcmV2ZW50IHJlcGxheXMgb2YgMC1SVFQgc2VjdGlvbiwgd2l0aCBz
b21lIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbiBhYm91dCB3aHkgdGhlIGV4aXN0aW5nIGFkdmljZSBp
cyB1bmxpa2VseSB0byBiZSBmb2xsb3dlZCwgYW5kIHdoeSBjb25zaXN0ZW50IGludGVyb3BlcmFi
aWxpdHkgbWF0dGVycyBoZXJlLg0KDQpVbmZvcnR1bmF0ZWx5LCBJIHdhc24ndCBhd2FyZSB1bnRp
bCBGcmlkYXkgdGhhdCB0aGlzIHJldmlldyB3b3VsZCBiZSBjb21pbmcgc28gbGF0ZSBpbiB0aGUg
VExEMS4zIGRyYWZ0IHByb2Nlc3MsIGFuZCBteSBhcG9sb2dpZXMgZm9yIHRoYXQuIEkgYW0gbm93
IHBsYW5uaW5nIHRvIGF0dGVuZCB0aGUgZnV0dXJlIFdHIGluLXBlcnNvbiBtZWV0aW5ncyBhbmQg
bG9vayBmb3J3YXJkIHRvIHNlZWluZyBtYW55IG9mIHlvdSB0aGVyZS4NCg0KLS0NCkNvbG0NCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls
aW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190
bHMmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9bDJqNEJqa08wTGMzdTRDSDJ6
N2pQdyZtPV8yQkVDZjlPZlcxcjFhUldyTF9wU2JRZUtNc2h5T20yTklWV0Y0R0dCSTAmcz02R0lv
Y0d6VzZ3UEs0RUFscURMSWlyTnZzdVFqN2dXaFlHX096Uk9SMnFZJmU9Pg0KDQoNCg==

--_000_MWHPR15MB1182C6745F7581005DD447A9AFEA0MWHPR15MB1182namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21z
by1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXttc28tc3R5bGUtbmFt
ZTpnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx
LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ZZXAsIEkgdGhpbmsgeW91ciBQ
UiBpcyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEkgaGF2ZSBi
ZWVuIGJhc2ljYWxseSBhc3N1bWluZyB0aGF0IHlvdSBjYW4ndCByZWFsbHkgZG8gVExTIHdpdGhv
dXQgYSByZWFsLXRpbWUgY2xvY2ssIGJ1dCBtYXliZSB0aGF0J3Mgd3Jvbmc/PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPldlbGwsIGl04oCZcyBwb3NzaWJsZSwgYWx0aG91Z2ggSSBkbyBub3Qga25vdyBpZiBhbnlv
bmUgYWN0dWFsbHkgZG9lcyAoYW5kIG9mIGNvdXJzZSBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIHdv
dWxkIGJlIGEgbGl0dGxlIGNoYWxsZW5naW5nKS4gTWF5YmUgc29tZW9uZSBmcm9tIHRoZSBlbWJl
ZGRlZCBjcm93ZA0KIGNhbiBlbmxpZ2h0ZW4gdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgJnF1b3Q7
Rm9yIGlkZW50aXRpZXMgZXN0YWJsaXNoZWQgZXh0ZXJuYWxseSBhbiBvYmZ1c2NhdGVkX3RpY2tl
dF9hZ2Ugb2YgMCBTSE9VTEQgYmUgdXNlZCwgYW5kIHNlcnZlcnMgTVVTVCBpZ25vcmUgdGhlIHZh
bHVlLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BaCwgSSBoYWQgbWlzc2VkIHRoYXQuIEkgdGhpbmsg
dGhlIE1VU1QgbWlnaHQgYmUgYSBsaXR0bGUgc3Ryb25nIHRoZXJlLCBldmVuIHdpdGhvdXQgZGly
ZWN0IGludm9sdmVtZW50IG9mIHRoZSBzZXJ2ZXIgaW4gaXNzdWluZyB0aGUgZXh0ZXJuYWwgUFNL
IHRoZSB0aWNrZXQgYWdlIGNhbiBzdGlsbCBiZQ0KIHVzZWZ1bCwgZm9yIGV4YW1wbGUgdXNpbmcg
YSBzaW1pbGFyIG1ldGhvZCB3ZSB1c2Ugd2l0aCBaZXJvIFByb3RvY29sIChUaW1lLWJvdW5kIDAt
UlRUIGRhdGEgc2VjdGlvbiBvZg0KPGEgaHJlZj0iaHR0cHM6Ly9jb2RlLmZhY2Vib29rLmNvbS9w
b3N0cy82MDg4NTQ5NzkzMDcxMjUvYnVpbGRpbmctemVyby1wcm90b2NvbC1mb3ItZmFzdC1zZWN1
cmUtbW9iaWxlLWNvbm5lY3Rpb25zLyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+
aHR0cHM6Ly9jb2RlLmZhY2Vib29rLmNvbS9wb3N0cy82MDg4NTQ5NzkzMDcxMjUvYnVpbGRpbmct
emVyby1wcm90b2NvbC1mb3ItZmFzdC1zZWN1cmUtbW9iaWxlLWNvbm5lY3Rpb25zLzwvc3Bhbj48
L2E+ICkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt
ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFJlc2NvcmxhIFtt
YWlsdG86ZWtyQHJ0Zm0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgNCwg
MjAxNyA1OjM3IFBNPGJyPg0KPGI+VG86PC9iPiBLeWxlIE5la3JpdHogJmx0O2tuZWtyaXR6QGZi
LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IENvbG0gTWFjQ8OhcnRoYWlnaCAmbHQ7Y29sbUBhbGxj
b3N0cy5uZXQmZ3Q7OyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNd
IFNlY3VyaXR5IHJldmlldyBvZiBUTFMxLjMgMC1SVFQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBUaHUsIE1heSA0LCAyMDE3IGF0IDI6MjcgUE0sIEt5bGUgTmVrcml0eiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmtuZWtyaXR6QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtuZWtyaXR6QGZiLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp
biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow
aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDEuIEEgU0hPVUxELWxldmVsIHJlcXVpcmVtZW50
IGZvciBzZXJ2ZXItc2lkZSAwLVJUVCBkZWZlbnNlLCBleHBsYWluaW5nIGJvdGggc2Vzc2lvbi1j
YWNoZSBhbmQgc3RyaWtlIHJlZ2lzdGVyDQogc3R5bGVzIGFuZCB0aGUgbWVyaXRzIG9mIGVhY2gu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5GaXJzdCwgYSBwb2ludCBvZiBjbGFyaWZpY2F0aW9uLCBJIHRo
aW5rIHR3byBpc3N1ZXMgaGF2ZSBiZWVuIGNvbmZsYXRlZCBpbiB0aGlzIGxvbmcgdGhyZWFkOjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4xKSBTZXJ2ZXJzIHJlamVjdGluZyByZXBsYXllZCAwLVJUVCBkYXRhICh1c2luZyBhIHNp
bmdsZSB1c2Ugc2Vzc2lvbiBjYWNoZS9zdHJpa2UgcmVnaXN0ZXIvcmVwbGF5IGNhY2hlL3NvbWUg
b3RoZXINCiBtZXRob2QpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZSBhcmUgZGVmaW5pdGVseSBj
YXNlcyAoaS5lLiBhcHBsaWNhdGlvbiBwcm9maWxlcykgd2hlcmUgdGhpcyBzaG91bGQgYmUgZG9u
ZS4gSSB0aGluayBhIGdlbmVyYWwgY2FzZSBIVFRQUyBzZXJ2ZXINCiBpcyBvbmUuIEJ1dCBJIGRv
buKAmXQgdGhpbmsgdGhpcyBpcyBzdHJpY3RseSBuZWNlc3NhcnkgYWNyb3NzIHRoZSBib2FyZCAo
Zm9yIGV2ZXJ5IGFwcGxpY2F0aW9uIHVzaW5nIDAtUlRUIGF0IGFsbCkuIEROUyB3YXMgYnJvdWdo
dCB1cCBlYXJsaWVyIGluIHRoaXMgdGhyZWFkIGFzIGFuIGV4YW1wbGUgb2YgYSBwcm90b2NvbCB0
aGF0IGlzIGxpa2VseSBxdWl0ZSB3b3JrYWJsZSB3aXRob3V0IGV4dHJhIG1lYXN1cmVzIHRvIHBy
ZXZlbnQgcmVwbGF5Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBhbHJlYWR5IHN0YXRlIOKAnFBy
b3RvY29scyBNVVNUIE5PVCB1c2UgMC1SVFQgZGF0YSB3aXRob3V0IGEgcHJvZmlsZSB0aGF0IGRl
ZmluZXMgaXRzIHVzZS7igJ0uIFdlIGNvdWxkIGFsc28gZGVzY3JpYmUNCiBtZXRob2RzIHRoYXQg
bWF5IGJlIHVzZWQgdG8gcHJvdmlkZSBmdXJ0aGVyIHJlcGxheSBwcm90ZWN0aW9uLiBCdXQgSSBk
b27igJl0IHRoaW5rIGl04oCZcyBhcHByb3ByaWF0ZSB0byBtYWtlIGEgYmxhbmtldCByZXF1aXJl
bWVudCB0aGF0ICphbGwqIGFwcGxpY2F0aW9uIHByb3RvY29scyBzaG91bGQgcmVxdWlyZSBpdC48
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWxzbyBjb25zaWRlciBpdCBxdWl0ZSBtaXNsZWFkaW5nIHRv
IHNheSBUTFMgMS4zIGlzIGluc2VjdXJlIHdpdGhvdXQgc3VjaCBhIHJlY29tbWVuZGF0aW9uLiBV
c2VzIG9mIFRMUyBjYW4gYmUNCiBpbnNlY3VyZSwgdGhhdCBkb2VzIG5vdCBtZWFuIHRoZSBwcm90
b2NvbCBpdHNlbGYgaXMuIEl04oCZcyBpbnNlY3VyZSB0byB1c2UgVExTIHdpdGhvdXQgcHJvcGVy
bHkgYXV0aGVudGljYXRpbmcgdGhlIHNlcnZlci4gU29tZSB1c2VycyBvZiBUTFMgZG8gbm90IGRv
IHRoaXMgY29ycmVjdGx5LiBJ4oCZZCBhY3R1YWxseSBhcmd1ZSB0aGF0IGl0IGlzIGVhc2llciB0
byBtZXNzIHRoaXMgdXAgdGhhbiBpdCBpcyB0byBtZXNzIHVwIGEgMC1SVFQgZGVwbG95bWVudA0K
IChhbmQgaXQgY2FuIHJlc3VsdCBpbiB3b3JzZSBjb25zZXF1ZW5jZXMpLiBUaGF0IGRvZXNu4oCZ
dCBtZWFuIHdlIHNob3VsZCByZXF1aXJlIGEgcGFydGljdWxhciBtZXRob2Qgb2YgYXV0aGVudGlj
YXRpb24sIGZvciBhbGwgdXNlcyBvZiBUTFMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
dGhpbmsgdGhpcyBpcyBiYXNpY2FsbHkgcmlnaHQuIEluIHRoZSBQUiBJIGp1c3QgcG9zdGVkLCBJ
IHNwZW50IG1vc3Qgb2YgbXkgdGltZSBkZXNjcmliaW5nIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWVjaGFuaXNtcyBhbmQgdXNlZCBhIFNI
T1VMRC1sZXZlbCByZXF1aXJlbWVudCB0byBkbyBvbmUgb2YgdGhlIG1lY2hhbmlzbXMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRo
ZXJlJ3MgYSBidW5jaCBvZiByb29tIHRvIHdvcmRzbWl0aCB0aGUgcmVxdWlyZW1lbnQuIFBlcmhh
cHMgd2Ugc2F5OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4tIFlvdSBjYW4ndCBkbyAwLVJUVCB3aXRob3V0IGFuIGFwcGxpY2F0aW9uIHByb2Zp
bGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g
QWJzZW50IHRoZSBhcHBsaWNhdGlvbiBwcm9maWxlIHNheWluZyBvdGhlcndpc2UgeW91IFNIT1VM
RC9NVVNUIGRvIG9uZSBvZiB0aGVzZSBtaXRpZ2F0aW9ucz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Mikg
UHJldmVudGluZyBjbGllbnRzIGZyb20gc2VuZGluZyAwLVJUVCBkYXRhIG11bHRpcGxlIHRpbWVz
IChvbiBzZXBhcmF0ZSBjb25uZWN0aW9ucykgdXNpbmcgdGhlIHNhbWUgUFNLIChmb3IgZm9yd2Fy
ZA0KIHNlY3JlY3kgcmVhc29ucyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhpcyBzaG91
bGQgYmUgYWxsb3dlZC4gT3RoZXJ3aXNlLCBjbGllbnRzIHdpbGwgbm90IGJlIGFibGUgdG8gcmV0
cnkgMC1SVFQgcmVxdWVzdHMgdGhhdCBmYWlsIGR1ZSB0byBhbiB1bmtub3duDQogbmV0d29yayBl
cnJvciBwcmlvciB0byByZWNlaXZpbmcgYSBOU1QgKGlmIHRoZXkgYXJlIG91dCBvZiBjYWNoZWQg
UFNLcykuIEnigJlkIGV4cGVjdCB0aGUgbmVlZCBmb3IgdGhlc2UgcmV0cmllcyB0byBiZSBsYXJn
ZXIgd2l0aCAwLVJUVCBkYXRhLCBwYXJ0aWN1bGFybHkgd2hlbiAwLVJUVCBkYXRhIGlzIHNlbnQg
d2l0aG91dCBldmVuIGEgdHJhbnNwb3J0IHJvdW5kdHJpcCAoaW4gdGhlIGNhc2Ugb2YgVEZPIG9y
IFFVSUMpLiBTZXJ2ZXJzIGFyZSBkZWZpbml0ZWx5DQogbm90IHJlcXVpcmVkIHRvIGFjY2VwdCBt
dWx0aXBsZSAwLVJUVCBjb25uZWN0aW9ucyB1c2luZyB0aGUgc2FtZSBQU0ssIGJ1dCBJIGRvbuKA
mXQgdGhpbmsgY2xpZW50cyBzaG91bGQgYmUgYmFubmVkIGZyb20gYXR0ZW1wdGluZy48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSwgYW5kIHRoZSBQUiBJIHByb3ZpZGVkIGRvZXNu
J3QgYXR0ZW1wdCB0byBkbyBzby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA0LiBJIHdvdWxkIGFk
ZCB0byB0aGlzIHRoYXQgd2UgcmVjb21tZW5kIHRoYXQgcHJveHkvQ0ROIGltcGxlbWVudGF0aW9u
cyBzaWduYWwgd2hpY2ggZGF0YSBpcyAwLVJUVCBhbmQgd2hpY2ggaXMNCiAxLVJUVCB0byB0aGUg
YmFjay1lbmQgKHRoaXMgd2FzIGluIENvbG0ncyBvcmlnaW5hbCBtZXNzYWdlKS48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPknigJltIG5vdCBzdXJlIHRoYXQgdGhlIFRMUyAxLjMgc3BlYyBpcyB0aGUgcmln
aHQgcGxhY2UgdG8gbWFrZSByZWNvbW1lbmRhdGlvbnMgZm9yIHRoaXMuIEkgY2FuIHNlZSBzZXZl
cmFsIHJlYXNvbmFibGUNCiBhcHByb2FjaGVzIGhlcmUsIGZvciBleGFtcGxlOjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tIEFk
ZGluZyBzb21lIGtpbmQgb2YgYXBwbGljYXRpb24gbGV2ZWwgYW5ub3RhdGlvbiAoZm9yIGV4YW1w
bGUgYW4gSFRUUCBoZWFkZXIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0gUm9idXN0bHkgcHJldmVudGluZyByZXBsYXkgb24g
dGhlIDAtUlRUIGhvcDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4tIFNlbmRpbmcgcHJveGllZCBlYXJseSBkYXRhIHdpdGggYSBk
aWZmZXJlbnQgVExTIENvbnRlbnRUeXBlLCBldGMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVk
IHRvIHNwZWNpZmljYWxseSBlbmRvcnNlIGFueSBwYXJ0aWN1bGFyIG1ldGhvZCBoZXJlLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIENvbG0gaGFzIGFsc28gYWdyZWVkIHdlIHNo
b3VsZG4ndCBkbyB0aGlzIGFuZCBpdCdzIG5vdCBpbiBteSBQUi48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgd2FzIGFsc28gYSBwb2ludCBicm91Z2h0IHVw
IGFib3V0IHRoZSB1c2Ugb2YgdGlja2V0X2FnZSB3aXRob3V0IDAtUlRULiBJ4oCZbSBub3QgYXdh
cmUgb2YgYW55IHVzZSBmb3IgdGlja2V0X2FnZQ0KIG90aGVyIHRoYW4gMC1SVFQgcmVwbGF5IHBy
b3RlY3Rpb24uIEkgYmVsaWV2ZSB0aGF0IHRpY2tldF9hZ2UgaXMgc2VudCB3aXRoIGFsbCBQU0tz
IG1vc3RseSBvdXQgb2YgY29udmVuaWVuY2UvY29uc2lzdGVuY3kuIEkgZG9u4oCZdCByZWFsbHkg
aGF2ZSBhbiBvYmplY3Rpb24gdG8gdGhlIGN1cnJlbnQgbWV0aG9kLCBidXQgSSBhbHNvIHdvdWxk
buKAmXQgYmUgb3Bwb3NlZCB0byBtb3ZpbmcgdGhlIHRpY2tldCBhZ2UgdG8gdGhlIGVhcmx5IGRh
dGEgZXh0ZW5zaW9uLA0KIHNvIHRoYXQgaXQgaXMgb25seSBzZW50IGFsb25nIHdpdGggMC1SVFQg
ZGF0YS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBiZSBPSyB3aXRoIHRoaXMg
YXMgd2VsbC4gSXQgZG9lcyBzZWVtIHNsaWdodGx5IG1vcmUgZWxlZ2FudC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5JdCBhbHNvIHNlZW1zIGEgbGl0dGxlIHVuZGVyLXNwZWNpZmllZCB3aGF0IGltcGxl
bWVudGF0aW9ucyB1bmFibGUgdG8gY29tcHV0ZSBhIHJlYXNvbmFibGUgdGlja2V0IGFnZSBzaG91
bGQgc2VuZA0KIChmb3IgZXhhbXBsZSBpbiB0aGUgY2FzZSBvZiBhIGRldmljZSB3aXRob3V0IGEg
cmVhbCB0aW1lIGNsb2NrLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdodC4gSSBoYXZl
IGJlZW4gYmFzaWNhbGx5IGFzc3VtaW5nIHRoYXQgeW91IGNhbid0IHJlYWxseSBkbyBUTFMgd2l0
aG91dCBhIHJlYWwtdGltZSBjbG9jaywgYnV0IG1heWJlIHRoYXQncyB3cm9uZz88bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+b3Igd2l0aCBhbiBleHRlcm5hbCBQU0spLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGlzIGFjdHVhbGx5IGlzIHdlbGwtc3BlY2lmaWVkICh0aG91Z2ggbWF5YmUgd3Jvbmcp
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVv
dDtGb3IgaWRlbnRpdGllcyBlc3RhYmxpc2hlZCBleHRlcm5hbGx5IGFuIG9iZnVzY2F0ZWRfdGlj
a2V0X2FnZSBvZiAwIFNIT1VMRCBiZSB1c2VkLCBhbmQgc2VydmVycyBNVVNUIGlnbm9yZSB0aGUg
dmFsdWUuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3Rsc3dnLmdpdGh1Yi5pb190bHMxMy0yRHNwZWNfLTIzcHJlLTJEc2hhcmVk
LTJEa2V5LTJEZXh0ZW5zaW9uJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIz
TVV3JmFtcDtyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmYW1wO209MDBEMzRlcXlvYnFZc25ILTB4
MnNRZEM4WG4xR0NxSFFCRlBxUGVYRTBnZyZhbXA7cz1wYWNoR0xKUUVySkc4bkFLNU9LSjRMM0Rh
NzBiSU8xQlFseXRkaXV1YU5zJmFtcDtlPSI+aHR0cHM6Ly90bHN3Zy5naXRodWIuaW8vdGxzMTMt
c3BlYy8jcHJlLXNoYXJlZC1rZXktZXh0ZW5zaW9uPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86PC9zcGFuPjxhIGhy
ZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFdl
ZG5lc2RheSwgTWF5IDMsIDIwMTcgMTE6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IENvbG0gTWFjQ8Oh
cnRoYWlnaCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjb2xtQGFsbGNvc3RzLm5ldCIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Y29sbUBhbGxjb3N0cy5uZXQ8L3NwYW4+PC9h
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnRsc0Bp
ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IFtUTFNdIFNlY3VyaXR5IHJldmlldyBvZiBUTFMxLjMgMC1SVFQ8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W0RlbGliZXJhdGVseSByZXNwb25kaW5nIHRvIHRo
ZSBPUCByYXRoZXIgdGhhbiB0byBhbnlvbmUgaW4gcGFydGljdWxhcl08bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBzZWVpbmcg
YSBsb3Qgb2YgYmFjayBhbmQgZm9ydGggYWJvdXQgZ2VuZXJhbCBwaGlsb3NvcGh5IGFuZCB0aGU8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+d2lz
ZG9tIG9mIDAtUlRUIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB3ZSBmb2N1c2Vk
IG9uIHdoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Y2hhbmdlcywgaWYgYW55LCB3ZSBuZWVkIHRvIG1ha2UgdG8gdGhlIGRyYWZ0LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+SSBtYWRlIHNvbWUgcHJvcG9zYWxzIHllc3RlcmRheSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oPGEgaHJlZj0iaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf
bWFpbC0yRGFyY2hpdmVfd2ViX3Rsc19jdXJyZW50X21zZzIzMDg4Lmh0bWwmYW1wO2Q9RHdNRmFR
JmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQ
dyZhbXA7bT1fMkJFQ2Y5T2ZXMXIxYVJXckxfcFNiUWVLTXNoeU9tMk5JVldGNEdHQkkwJmFtcDtz
PVhnSGJVd1Q2dXBBc09pbjRUNlA4ZVBzOGkwWkZzbkQtX0JOdnVlZXE4M0UmYW1wO2U9IiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3Vy
cmVudC9tc2cyMzA4OC5odG1sPC9hPikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TcGVjaWZpY2FsbHk6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuIEEgU0hPVUxELWxldmVsIHJl
cXVpcmVtZW50IGZvciBzZXJ2ZXItc2lkZSAwLVJUVCBkZWZlbnNlLCBleHBsYWluaW5nPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJvdGggc2Vz
c2lvbi1jYWNoZSBhbmQgc3RyaWtlIHJlZ2lzdGVyIHN0eWxlcyBhbmQgdGhlIG1lcml0cyBvZiBl
YWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Mi4gRG9jdW1lbnQgMC1SVFQgZ3JlYXNpbmcgaW4gZHJhZnQtaWV0Zi10bHMtZ3JlYXNl
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4zLiBBZG9wdCBQUiM0NDggKG9yIHNvbWUgdmFyaWFudCkgc28gdGhhdCBzZXNzaW9uLWlkIHN0
eWxlIGltcGxlbWVudGF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5wcm92aWRlIFBGUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuIEkgd291bGQgYWRkIHRvIHRoaXMgdGhh
dCB3ZSByZWNvbW1lbmQgdGhhdCBwcm94eS9DRE4gaW1wbGVtZW50YXRpb25zPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnNpZ25hbCB3aGljaCBk
YXRhIGlzIDAtUlRUIGFuZCB3aGljaCBpcyAxLVJUVCB0byB0aGUgYmFjay1lbmQgKHRoaXMgd2Fz
IGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkNvbG0ncyBvcmlnaW5hbCBtZXNzYWdlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhc2VkIG9uIENvbG0ncyByZXNwb25zZSwgSSB0
aGluayB0aGVzZSBsYXJnZWx5IGhpdHMgdGhlIHBvaW50cyBoZSBtYWRlPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmluIGhpcyBvcmlnaW5hbCBt
ZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+VGhlcmUncyBhbHJlYWR5IGEgUFIgZm9yICMzIGFuZCBJJ2xsIGhhdmUgUFJzIGZv
ciAjMSBhbmQgIzQgdG9tb3Jyb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPldoYXQgd291bGQgYmUgbW9zdCBoZWxwZnVsIHRvIG1lIGFzIEVk
aXRvciB3b3VsZCBiZSBpZiBwZW9wbGUgY291bGQgcmV2aWV3PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZXNlIFBScyBhbmQvb3Igc3VnZ2Vz
dCBvdGhlciBzcGVjaWZpYyBjaGFuZ2VzIHRoYXQgd2Ugc2hvdWxkIG1ha2U8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dG8gdGhlIGRvY3VtZW50
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgTWF5IDIsIDIwMTcgYXQgNzo0NCBBTSwgQ29sbSBN
YWNDw6FydGhhaWdoICZsdDs8YSBocmVmPSJtYWlsdG86Y29sbUBhbGxjb3N0cy5uZXQiIHRhcmdl
dD0iX2JsYW5rIj5jb2xtQGFsbGNvc3RzLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW5kYXkgYXQgdGhlIFRMUzpESVYgd29ya3No
b3AgSSBwcmVzZW50ZWQgYSBzdW1tYXJ5IG9mIGZpbmRpbmdzIG9mIGEgc2VjdXJpdHkgcmV2aWV3
IHdlIGRpZCBvbiBUTFMxLjMgMC1SVFQsIGFzIHBhcnQgb2YgaW1wbGVtZW50aW5nIDEuMyBpbiBz
Mm4uIFRoYW5rcyB0byBmZWVkYmFjayBpbiB0aGUgcm9vbQ0KIEkndmUgbm93IHRpZ2h0ZW5lZCB1
cCB0aGUgZmluZGluZ3MgZnJvbSB0aGUgcmV2aWV3IGFuZCBwb3N0ZWQgdGhlbSBhcyBhbiBpc3N1
ZSBvbiB0aGUgZHJhZnQgR2l0SHViIHJlcG86PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3Rs
czEzLXNwZWMvaXNzdWVzLzEwMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20v
dGxzd2cvdGxzMTMtc3BlYy9pc3N1ZXMvMTAwMTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbGwgc3VtbWFyaXplIHRoZSBzdW1t
YXJ5OiBOYXR1cmFsbHkgdGhlIGZvY3VzIHdhcyBvbiBmb3J3YXJkIHNlY3JlY3kgYW5kIHJlcGxh
eS4gT24gZm9yd2FyZCBzZWNyZWN5IHRoZSBtYWluIGZpbmRpbmcgd2FzIHRoYXQgaXQncyBub3Qg
bmVjZXNzYXJ5IHRvIHRyYWRlIG9mZiBGb3J3YXJkIFNlY3JlY3kgYW5kDQogMC1SVFQuIEEgc2lu
Z2xlLXVzZSBzZXNzaW9uIGNhY2hlIGNhbiBwcm92aWRlIGl0LCBhbmQgd2l0aCB0aGUgbW9kaWZp
Y2F0aW9uIHRoYXQgZWtyIGhhcyBjcmVhdGVkIGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRo
dWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC85OTgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzk5ODwvYT4gLCBzdWNoIGEgY2FjaGUg
d29ya3MgZm9yIGJvdGggcHJlLWF1dGgNCiBhbmQgcG9zdC1hdXRoIHRpY2tldHMsIGFuZCBpdCBh
bGxvd3MgY2xpZW50cyB0byBidWlsZCB1cCBwb29scyBvZiBtZWFuaW5nZnVsbHkgZGlzdGluY3Qg
dGlja2V0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlRoZXJlJ3MgYWxzbyBhbiBvYnNlcnZhdGlvbiB0aGVyZSB0aGF0IGl0IHNob3Vs
ZCByZWFsbHkgYmUgdGhhdCBjbGllbnRzICZxdW90O01VU1QmcXVvdDsgdXNlIHRpY2tldHMgb25s
eSBvbmNlLiBBbnkgcmUtdXNlIGxpa2VseSBkaXNjbG9zZXMgdGhlIG9iZnVzY2F0ZWQgdGlja2V0
IGFnZSwgd2hpY2ggaXMgaW50ZW5kZWQgdG8NCiBiZSBzZWNyZXQuIFJpZ2h0IG5vdyBpdCdzIGEg
JnF1b3Q7U0hPVUxEJnF1b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gcmVwbGF5LCB0aGUgbWFpbiBmaW5kaW5nIGlz
IHRoYXQgd2hhdCdzIGluIHRoZSBkcmFmdCBpcyBub3Qgd29ya2FibHkgc2VjdXJlLCBhbmQgdGhl
IHJldmlldyBpbmNsdWRlcyA1IGRpZmZlcmVudCBhdHRhY2tzIGFnYWluc3QgMC1SVFQgZGF0YSB0
byBpbGx1c3RyYXRlIHRoYXQuIEF0dGFja3MgMSBhbmQNCiAyIHNob3cgdGhhdCB0aGUga2luZCBv
ZiByZXBsYXkgcGVybWl0dGVkIGJ5IHRoZSBkcmFmdCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHRo
ZSBraW5kIG9mIHJlcGxheSBwZXJtaXR0ZWQgYnkgZGtnJ3MgZXhpc3RpbmcgZG93bmdyYWRlLWFu
ZC1yZXRyeSBhdHRhY2suIEkgYWxzbyBnbyBvdmVyIHdoeSBpdCB2ZXJ5IHZlcnkgZGlmZmljdWx0
IHRvIG1hbnkgYXBwbGljYXRpb25zIHRvIGFjaGlldmUgdGhhdCBpZGVtcG90ZW5jeSwgYW5kIHdo
eSBvbmUNCiBpZGVtcG90ZW5jeSBwYXR0ZXJuIGFjdHVhbGx5IHJlbGllcyBvbiBub24tcmVwbGF5
YWJsZSBtZXNzYWdlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0dGFjayAzIHNob3dzIHRoYXQgaWRlbXBvdGVuY3kgaXMg
bm90IHN1ZmZpY2llbnQsIGFwcGxpY2F0aW9ucyBtdXN0IGFsc28gYmUgZnJlZSBvZiBtZWFzdXJh
YmxlIHNpZGUtZWZmZWN0cywgd2hpY2ggaXMgbm90IHByYWN0aWNhbC4mbmJzcDsgQXR0YWNrIDQg
c2hvd3MgdGhhdCAwLVJUVCBicmVha3MgYSBjb21tb24NCiBzZWN1cml0eSBtZWNoYW5pc206IHNw
b29maW5nLXJlc2lzdGFudCB0aHJvdHRsZXMuIEF0dGFjayA1IHNob3dzIHRoYXQgMC1SVFQgcmVw
bGF5LWFiaWxpdHkgZW5hYmxlcyBhbiBhZGRpdGlvbmFsIGZvcm0gb2YgdHJhZmZpYyBhbmFseXNp
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlRoZSByZWNvbW1lbmRhdGlvbiBpbiB0aGUgcmV2aWV3IGlzIHRoYXQgaW1wbGVt
ZW50YXRpb25zICZxdW90O01VU1QmcXVvdDsgcHJldmVudCByZXBsYXlzIG9mIDAtUlRUIHNlY3Rp
b24sIHdpdGggc29tZSBhZGRpdGlvbmFsIGRpc2N1c3Npb24gYWJvdXQgd2h5IHRoZSBleGlzdGlu
ZyBhZHZpY2UgaXMgdW5saWtlbHkgdG8gYmUNCiBmb2xsb3dlZCwgYW5kIHdoeSBjb25zaXN0ZW50
IGludGVyb3BlcmFiaWxpdHkgbWF0dGVycyBoZXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VW5mb3J0dW5hdGVseSwgSSB3
YXNuJ3QgYXdhcmUgdW50aWwgRnJpZGF5IHRoYXQgdGhpcyByZXZpZXcgd291bGQgYmUgY29taW5n
IHNvIGxhdGUgaW4gdGhlIFRMRDEuMyBkcmFmdCBwcm9jZXNzLCBhbmQgbXkgYXBvbG9naWVzIGZv
ciB0aGF0LiBJIGFtIG5vdyBwbGFubmluZyB0byBhdHRlbmQgdGhlIGZ1dHVyZQ0KIFdHIGluLXBl
cnNvbiBtZWV0aW5ncyBhbmQgbG9vayBmb3J3YXJkIHRvIHNlZWluZyBtYW55IG9mIHlvdSB0aGVy
ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNvbG08
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t
Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRM
U0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3
dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJU
dE5sVGgzeWNkNDFiM01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFtcDttPV8yQkVD
ZjlPZlcxcjFhUldyTF9wU2JRZUtNc2h5T20yTklWV0Y0R0dCSTAmYW1wO3M9NkdJb2NHelc2d1BL
NEVBbHFETElpck52c3VRajdnV2hZR19PelJPUjJxWSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_MWHPR15MB1182C6745F7581005DD447A9AFEA0MWHPR15MB1182namp_--


From nobody Thu May  4 15:04:49 2017
Return-Path: 
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 A2F15129AE9 for ; Thu,  4 May 2017 15:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 BBbTHNaXdboV for ; Thu,  4 May 2017 15:04:46 -0700 (PDT)
Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [209.118.176.138]) by ietfa.amsl.com (Postfix) with SMTP id 66AF1129B3F for ; Thu,  4 May 2017 15:04:28 -0700 (PDT)
Received: from [192.168.1.3] ([208.85.33.68]) by Mail.Yoyodyne.COM via Internet for  (and others);  Thu, 4 May 2017 15:04:24 PDT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Derrell Piper 
In-Reply-To: 
Date: Thu, 4 May 2017 16:04:26 -0600
Cc: Eric Roscorla , "tls@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:     
To: Erik Nygren 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 22:04:48 -0000

Sure, those are fine weasel words.  But do we really want to allow into =
this protocol something that can be misused with security implications =
in a protocol that=E2=80=99s attempting to solve a security problem?  I =
really don=E2=80=99t know.  I=E2=80=99m inclined to say, =E2=80=98no=E2=80=
=99 though.  For all those same reasons that IPsec provides replay =
detection, I think TLS should too.

Derrell

> On May 4, 2017, at 4:00 PM, Erik Nygren  wrote:
>=20
> "The onus is on clients not to send messages in 0-RTT data which are =
not safe to have replayed and which they would not be willing to retry =
across multiple 1-RTT connections. The onus is on servers to protect =
themselves against attacks employing 0-RTT data replication."
>=20
> The server responsibility is a general property TLS can maintain while =
the client responsibility requires an application profile to define. =20


From nobody Thu May  4 16:26:53 2017
Return-Path: 
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 C05F91243FE for ; Thu,  4 May 2017 16:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 YO2laAp07smd for ; Thu,  4 May 2017 16:26:50 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5DF129A99 for ; Thu,  4 May 2017 16:26:50 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id s22so7354499ybe.3 for ; Thu, 04 May 2017 16:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f9WOlkDPbjUpuq83aZbZBi3Lxz0ucjYiEyHXsYIcWdM=; b=bSOCVOGdbZMgeG/TUSZPiTJ0objkKYg4ipIC8Ku9Pba3Gs210aoJM47bu6mY1oQaz2 G8uxTEjDoVH3NAGWX/UsXB/NY+weovoqF+mP6SwIPrdPE7djoxBEFsDq/dlK1ri0ykrf zsb1xcZFx4+3rLiwfSNDvIvmhK4qNpfNx59CRR4a7qcox6Zb8AroIx8O96WIe8vAoIha iOyeCQ4aVTybk6f8Rdtiotw/xmMVgiDrKn6mkP3cQgIIjrb9xl8Az5wG4JJn9N4JKU8+ O43JNRgTbuvWrzIZ4BBe3Cz4vScTb4hBw96k8ryBs8hR6QVi2fSwvhcVkTVnpEXz9JMD BD4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f9WOlkDPbjUpuq83aZbZBi3Lxz0ucjYiEyHXsYIcWdM=; b=CRUor8uFctRfpgMyX6um5vcjSQcqem4YxXlX9meN2IYM/W6Ws8dJ407683QjEgtDml QrsFbYt7QsGz4SjyvZ1snp3/TL1V5ulaNF/6YbGV+2/i9zDF+N2fgXHaKSLpgv0iIxO3 yOV89PthiUvd/8+yq0faFEDa9kwOb5erF06pFo9uO3hfSIIg3hmJF4HilKpnXNM0BCxL /rczLxaSTK4MYKNUUhKXoGvfPOxwZWsga+G96xU1pHMfXUoekCvhwScYL19pX5Ew/ZVA Yccq1Ixru79QSYvJfay5zwwgJt4/g7kn1BjWpkFu8jHqlK1N+JWz1kRsc858n5T61r6L uUkg==
X-Gm-Message-State: AN3rC/7eS9M+xa/zwvCuqCs0iEH/ffLY/wY0l+bBl2zWM4Hw7/p88SIf fOfPJORzDFsX8+BfwlJHmyDGYFamJQ==
X-Received: by 10.37.16.212 with SMTP id 203mr23436063ybq.90.1493940409739; Thu, 04 May 2017 16:26:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 16:26:48 -0700 (PDT)
In-Reply-To: 
References:   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 16:26:48 -0700
Message-ID: 
To: Kyle Nekritz 
Cc: Eric Rescorla , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c0ff04704eea054ebb1b3b
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 23:26:52 -0000

--001a11c0ff04704eea054ebb1b3b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:

>
> There are definitely cases (i.e. application profiles) where this should
> be done. I think a general case HTTPS server is one. But I don=E2=80=99t =
think this
> is strictly necessary across the board (for every application using 0-RTT
> at all). DNS was brought up earlier in this thread as an example of a
> protocol that is likely quite workable without extra measures to prevent
> replay.
>

I thought some more about DNS since yesterday and I'm not sure it is
workable. How would we protect DNS against attack 4 (cache replay) -
couldn't it lead to disclosure of what the request was for? When used
against caches I mean, which is common, and DNS-over-TLS is designed mainly
for privacy, so that actually seems like a show-stopper.


> I also consider it quite misleading to say TLS 1.3 is insecure without
> such a recommendation. Uses of TLS can be insecure, that does not mean th=
e
> protocol itself is. It=E2=80=99s insecure to use TLS without properly
> authenticating the server. Some users of TLS do not do this correctly. I=
=E2=80=99d
> actually argue that it is easier to mess this up than it is to mess up a
> 0-RTT deployment (and it can result in worse consequences). That doesn=E2=
=80=99t
> mean we should require a particular method of authentication, for all use=
s
> of TLS.
>

Here's how I think about it. Each of the attacks in the review is more
practical than Lucky13. More practical in the sense that I could do them in
a real-world setting. In my view at least.

Lucky13 was serious enough to prompt us all to accelerate turning of the
MtE cipher suites. Even though this actually made traffic analysis attacks
easier. Collectively we took a look at it and decided it was on too shaky
ground and we considered it insecure. And so the MtE suites went away.

I can't find a way then, in that context, to see replay as anything other
than a straightforward security issue. Replay is bad, it breaks things,
that's why we go to lengths to prevent it, it's not ok to just for get
about that. If TLS allows replay, TLS is insecure. Remembering that TLS is
a transport layer protocol, not an application layer one.

An application can use RC4 at the TLS layer if it provides its own
application-layer encryption, but we don't consider that secure. We don't
look for cases where applications can make special exceptions; because
that's fraught with sharp edges. We make the default secure.

--=20
Colm

--001a11c0ff04704eea054ebb1b3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <knekritz@fb.com> wrote:














There are definitely cases (i.e. application profil=
es) where this should be done. I think a general case HTTPS server is one. =
But I don=E2=80=99t think this is strictly necessary across
 the board (for every application using 0-RTT at all). DNS was brought up e=
arlier in this thread as an example of a protocol that is likely quite work=
able without extra measures to prevent replay.

I thought some more about DNS since yesterday an=
d I'm not sure it is workable. How would we protect DNS against attack =
4 (cache replay) - couldn't it lead to disclosure of what the request w=
as for? When used against caches I mean, which is common, and DNS-over-TLS =
is designed mainly for privacy, so that actually seems like a show-stopper.=
 =C2=A0
=C2=A0


I also consider it quite misleading to say TLS 1.3 =
is insecure without such a recommendation. Uses of TLS can be insecure, tha=
t does not mean the protocol itself is. It=E2=80=99s insecure
 to use TLS without properly authenticating the server. Some users of TLS d=
o not do this correctly. I=E2=80=99d actually argue that it is easier to me=
ss this up than it is to mess up a 0-RTT deployment (and it can result in w=
orse consequences). That doesn=E2=80=99t mean we
 should require a particular method of authentication, for all uses of TLS.=


Here's how I th=
ink about it. Each of the attacks in the review is more practical than Luck=
y13. More practical in the sense that I could do them in a real-world setti=
ng. In my view at least. =C2=A0

Lucky13 was seriou=
s enough to prompt us all to accelerate turning of the MtE cipher suites. E=
ven though this actually made traffic analysis attacks easier. Collectively=
 we took a look at it and decided it was on too shaky ground and we conside=
red it insecure. And so the MtE suites went away.=C2=A0

I can't find a way then, in that context, to see replay as anythi=
ng other than a straightforward security issue. Replay is bad, it breaks th=
ings, that's why we go to lengths to prevent it, it's not ok to jus=
t for get about that. If TLS allows replay, TLS is insecure. Remembering th=
at TLS is a transport layer protocol, not an application layer one.=C2=A0

An application can use RC4 at the TLS layer if it p=
rovides its own application-layer encryption, but we don't consider tha=
t secure. We don't look for cases where applications can make special e=
xceptions; because that's fraught with sharp edges. We make the default=
 secure.=C2=A0

-- 
Colm




--001a11c0ff04704eea054ebb1b3b--


From nobody Thu May  4 16:35:13 2017
Return-Path: 
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 18BC012773A for ; Thu,  4 May 2017 16:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GItH9FkInS1P for ; Thu,  4 May 2017 16:35:11 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C97F1243F3 for ; Thu,  4 May 2017 16:35:11 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id q66so14429465pfi.3 for ; Thu, 04 May 2017 16:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=ZLasDnwYenOSYAtFB2XZPQK+sw5+aDgng9daztE6M9A=; b=lYWvR6GFDRC5eMIOElYzib1paS7X0NLrgTO++apvGoauYpvvgwUis5UrDI4H0YTvZF 0EXmphoLcCEfWNQJurqRTdtyKmd3eag+z3WyPyVyi4w42ha3HqQ8+CBr+ijUjdALXEKW aRzolRyQK7ISmOZlZcZiXVd8B2t0q0oV9lLddrBTo2h05zMhd1tFgyz/3I81W9FyqFXP KIEw7YeYCuGVI1JjAevREGsHYAVNvfICTO7CDwKh+It0uhpj/PsYPNjC8D7orZBqMa6q EhZx2HDJlSlCKgFfZtjtBamHEb/dGL2WutcUwEYw4oqo49iZI9AwpQRbav8Q4VajUBEe e0AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZLasDnwYenOSYAtFB2XZPQK+sw5+aDgng9daztE6M9A=; b=Uxu0qw1ikvYXg/D2dQG6OoalGm0o7ILc/lcKWb36WvOmHXRUw6wvCjTja/yCo8FcVs ASuIO2J6Zf3cWA/Rp3oUQ/HipN9hAOkiWbr2VJMYJcx3ZdcCfo77j4nEkj6NyfYYfZsK Nv2ucar99B+TrNuCaJYWvwgmSQe73QLDxqMJg7dMR1Yje5h9hUs0YgNutWhlKnGyiHTn TT24cGpiUjLhqvww4QYnmeABdHE89TzXIB+i0krs3lVqmfQ4Q+yJr4GVOf9qABwT6JiA ZvNTCMlzDhme87NwRbE5kxPTyFsXHGgrTNkUy/yJyefnxGH6d17hhwLkBrYniXBCNPNM 4rSA==
X-Gm-Message-State: AN3rC/63RjtZdAJ8Lewql6GOTFItfHBna/GrAVissc3K3fBC2f0fjoCW 5XOaq63GfJ2lkAECBPAmCn2Obn2SEfUD
X-Received: by 10.84.236.70 with SMTP id h6mr61070240pln.145.1493940910571; Thu, 04 May 2017 16:35:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.163.12 with HTTP; Thu, 4 May 2017 16:35:10 -0700 (PDT)
From: Watson Ladd 
Date: Thu, 4 May 2017 16:35:10 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 23:35:12 -0000

Dear all,

Applications have always had to deal with the occasional replay,
whether from an impatient user or a broken connection at exactly the
wrong time. But they've generally been rare, so human-in-the-loop
responses work. Order the same book twice? Just return one of them,
and if you get an overdraft fee, ouch, we're sorry, but nothing we can
do.

0-RTT is opt-in per protocol, and what we think of per application.
But it isn't opt-in for web application developers. Once browsers and
servers start shipping, 0-RTT will turn on by accident or deliberately
at various places in the stack.

At the same time idempotency patterns using unique IDs might require
nonidempotent backend requests. But this is an easier problem than if
we had nonidempotent brower requests: backends are much more
controlled.

If you are willing to buffer 0-RTT until completion before going to
the thing that makes the response, you can handle this problem for the
responsemaker. This will work for most applications I can think of,
and you need to handle large, drawn out requests anyway. This sounds
like it would work as a solution, but I am sure there are details I
haven't discovered yet.

In conclusion I think there is some thought that needs to go into
handling 0-RTT on the web, but it is manageable. I don't know about
other protocols, but they don't have the same kinds of problem as the
web does with lots of request passing around. Given the benefits here,
I think people will really want 0-RTT, and we are going to have to
figure out how to live with it.

Sincerely,
Watson Ladd


From nobody Thu May  4 16:38:45 2017
Return-Path: 
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 3D4C3127077 for ; Thu,  4 May 2017 16:38:44 -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] 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 91rJZ8t2S-Gs for ; Thu,  4 May 2017 16:38:43 -0700 (PDT)
Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [209.118.176.138]) by ietfa.amsl.com (Postfix) with SMTP id 4510C1243F3 for ; Thu,  4 May 2017 16:38:43 -0700 (PDT)
Received: from [192.168.1.3] ([208.85.33.68]) by Mail.Yoyodyne.COM via Internet for  (and others);  Thu, 4 May 2017 16:38:42 PDT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Derrell Piper 
In-Reply-To: 
Date: Thu, 4 May 2017 17:38:38 -0600
Cc: "tls@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ADD8F4F-464A-4FAF-A810-19F9FEB42E34@electric-loft.org>
References: 
To: Watson Ladd 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 23:38:44 -0000

> On May 4, 2017, at 5:35 PM, Watson Ladd  wrote:
>=20
> 0-RTT is opt-in per protocol

=E2=80=A6and at the end of the day, that=E2=80=99s the only reason I=E2=80=
=99d agree to this.

Derrell=


From nobody Thu May  4 16:47:47 2017
Return-Path: 
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 B5C0412704B for ; Thu,  4 May 2017 16:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 J34uwgtasgKs for ; Thu,  4 May 2017 16:47:44 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36FF1205F1 for ; Thu,  4 May 2017 16:47:43 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id 203so14256628ywe.0 for ; Thu, 04 May 2017 16:47:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=chIqkXTULZnVg/mHYpEZPl1jBmcUvTDEfl9RNDS1mqQ=; b=InJnzY54RCJyscPQwG7VE3L9Qe4WsEqjK2ToMcOzpcepiCTDcezTPMrf8tP20rnQum 4ZxLJJJm0PwmFasteMUhP+CnG8qkMyyZi6Yk02h2lHWrlc9iabsQKs7AHKK7KChOfgSs GfYFv6wZU6nm59LYEQSCmWQ1f9zMrpYU8BfqlFCyooyNSb23TfugGLau0fmamwAMD4MI YULQnI+Obme25gonh7NuLhw6XqetOM/92Rh1myNCrGxR+tcCa+aNI0h1JtQSBuodb5F1 r4HjwDwxBYZ3HdQJTMJf2oNei0E5JQoXScrg1VRm+fgLa49dVLbTpkuCU9/B+cgs43sN uZCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=chIqkXTULZnVg/mHYpEZPl1jBmcUvTDEfl9RNDS1mqQ=; b=hUCZgJliW6Zo534Fy9OCfCeKrkyvy6VHHfni5pDVW4QSAqeyxWyleydisF/JUN1uEr s3xtxVgmN73M7KNS4UghGxqgCM5h4MWgjvXdWOkQcu6gBgG3TfMzoBRwhtACaKHf/r8/ wSCK8ykr0fpbXju0hUGHIfrZ2Y8hWcsoXt8sJqj/CeIWrNBp9DcKz99+p1Z2E+P5Xr56 hmoKA5d8HWWiGjh0Ogl5sQefybn7gXFdWTcLBmaiD4VtU0Tv19oX2zQanQh89AxWw5We XopdWCBFCVpQksSneZnlAVedDYelEz0XJFiUMrX6d7yvJeRazxwzGYNoZtneensD+VR7 yaKA==
X-Gm-Message-State: AN3rC/6RLo1KNEyNTgBBFeBw0fxBRwA3WZbUmc5cPy6cPLagzDOzro9V pNQnNeZlLqUrp6ITeKSrntQ+wOhTCA==
X-Received: by 10.129.104.69 with SMTP id d66mr6637424ywc.74.1493941663065; Thu, 04 May 2017 16:47:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Thu, 4 May 2017 16:47:42 -0700 (PDT)
In-Reply-To: 
References: 
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Thu, 4 May 2017 16:47:42 -0700
Message-ID: 
To: Watson Ladd 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11490b9a24b337054ebb66f8
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 23:47:46 -0000

--001a11490b9a24b337054ebb66f8
Content-Type: text/plain; charset=UTF-8

On Thu, May 4, 2017 at 4:35 PM, Watson Ladd  wrote:

> Dear all,
>
> Applications have always had to deal with the occasional replay,
> whether from an impatient user or a broken connection at exactly the
> wrong time.


Unfortunately this isn't the case :( Not all applications are user-driven
in that way, and some are very careful about how they retry. In the review
I go through the example of an update to an eventually consistent data
store. In that case, the application will typically try to update and if
that update times-out, it will wait a time period, check for a conflict or
a success, and only then retry.  At no point is a replay, normal or
expected.

One could argue that Zero-RTT is not for applications like this, but why
not? They certainly do benefit from the speed-up. And so in the review I go
through reasons why it is likely that they will use it anyway, ranging from
how subtle and hard the review is, to inadvertent enabling of the feature
on something like an L4 TLS proxy which has no awareness of the underlying
protocol.

But they've generally been rare, so human-in-the-loop
> responses work. Order the same book twice? Just return one of them,
> and if you get an overdraft fee, ouch, we're sorry, but nothing we can
> do.
>
> 0-RTT is opt-in per protocol, and what we think of per application.
> But it isn't opt-in for web application developers. Once browsers and
> servers start shipping, 0-RTT will turn on by accident or deliberately
> at various places in the stack.
>

+1!


> At the same time idempotency patterns using unique IDs might require
> nonidempotent backend requests. But this is an easier problem than if
> we had nonidempotent brower requests: backends are much more
> controlled.
>
> If you are willing to buffer 0-RTT until completion before going to
> the thing that makes the response, you can handle this problem for the
> responsemaker. This will work for most applications I can think of,
> and you need to handle large, drawn out requests anyway. This sounds
> like it would work as a solution, but I am sure there are details I
> haven't discovered yet.
>

I think you're right; and we could enforce in TLS by encrypting 0-RTT under
a key that isn't transmitted until 1-RTT. But this would also defeat the
point of the speed-up; especially for CDNs. It really does speed things up
for them to be able to send the request to the origin right away.


> In conclusion I think there is some thought that needs to go into
> handling 0-RTT on the web, but it is manageable. I don't know about
> other protocols, but they don't have the same kinds of problem as the
> web does with lots of request passing around. Given the benefits here,
> I think people will really want 0-RTT, and we are going to have to
> figure out how to live with it.
>

+1 I think it's manageable too. Just have servers check for dupes :)

-- 
Colm

--001a11490b9a24b337054ebb66f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 4:35 PM, Watson Ladd <watsonbladd@gmail.com=
> wrote:
Dear all,



Applications have always had to deal with the occasional replay,

whether from an impatient user or a broken connection at exactly the

wrong time. 

Unfortunately this isn't t=
he case :( Not all applications are user-driven in that way, and some are v=
ery careful about how they retry. In the review I go through the example of=
 an update to an eventually consistent data store. In that case, the applic=
ation will typically try to update and if that update times-out, it will wa=
it a time period, check for a conflict or a success, and only then retry.=
=C2=A0 At no point is a replay, normal or expected.=C2=A0

One could argue that Zero-RTT is not for applications like this, bu=
t why not? They certainly do benefit from the speed-up. And so in the revie=
w I go through reasons why it is likely that they will use it anyway, rangi=
ng from how subtle and hard the review is, to inadvertent enabling of the f=
eature on something like an L4 TLS proxy which has no awareness of the unde=
rlying protocol.=C2=A0

B=
ut they've generally been rare, so human-in-the-loop

responses work. Order the same book twice? Just return one of them,

and if you get an overdraft fee, ouch, we're sorry, but nothing we can<=
br>
do.



0-RTT is opt-in per protocol, and what we think of per application.

But it isn't opt-in for web application developers. Once browsers and
servers start shipping, 0-RTT will turn on by accident or deliberately

at various places in the stack.

+1!
=C2=A0

At the same time idempotency patterns using unique IDs might require

nonidempotent backend requests. But this is an easier problem than if

we had nonidempotent brower requests: backends are much more

controlled.



If you are willing to buffer 0-RTT until completion before going to

the thing that makes the response, you can handle this problem for the

responsemaker. This will work for most applications I can think of,

and you need to handle large, drawn out requests anyway. This sounds

like it would work as a solution, but I am sure there are details I

haven't discovered yet.

I think you=
're right; and we could enforce in TLS by encrypting 0-RTT under a key =
that isn't transmitted until 1-RTT. But this would also defeat the poin=
t of the speed-up; especially for CDNs. It really does speed things up for =
them to be able to send the request to the origin right away.=C2=A0
=C2=A0

In conclusion I think there is some thought that needs to go into

handling 0-RTT on the web, but it is manageable. I don't know about

other protocols, but they don't have the same kinds of problem as the
web does with lots of request passing around. Given the benefits here,

I think people will really want 0-RTT, and we are going to have to

figure out how to live with it.

+1 I th=
ink it's manageable too. Just have servers check for dupes :)=C2=A0

-- 
Colm




--001a11490b9a24b337054ebb66f8--


From nobody Thu May  4 16:58:18 2017
Return-Path: 
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 84E3012704B for ; Thu,  4 May 2017 16:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 VY22RPERqW3k for ; Thu,  4 May 2017 16:58:16 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7651205F1 for ; Thu,  4 May 2017 16:58:16 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id E1A92A00491C; Thu,  4 May 2017 16:58:15 -0700 (PDT)
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 95349A00491B; Thu,  4 May 2017 16:58:15 -0700 (PDT)
Date: Thu, 4 May 2017 18:58:12 -0500
From: Nico Williams 
To: Watson Ladd 
Cc: "tls@ietf.org" 
Message-ID: <20170504235812.GA10188@localhost>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 23:58:17 -0000

On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote:
> 0-RTT is opt-in per protocol, and what we think of per application.

Yes.

> But it isn't opt-in for web application developers. Once browsers and
> servers start shipping, 0-RTT will turn on by accident or deliberately
> at various places in the stack.

It should be up to servers whether a request is allowed with 0-rtt.

If the server doesn't allow a given 0-rtt request and causes the client
to do one round trip, does it matter that the client tried with 0-rtt?
What can an attacker do?  Can they replay that 0-rtt request?  Surely
not, since the server didn't take it.  And presumably other servers in
the same cluster will make the same decision.

> In conclusion I think there is some thought that needs to go into
> handling 0-RTT on the web, but it is manageable. I don't know about
> other protocols, but they don't have the same kinds of problem as the
> web does with lots of request passing around. Given the benefits here,
> I think people will really want 0-RTT, and we are going to have to
> figure out how to live with it.

Yes.

In particular there has to be a way, either in-TLS, or at the
application layer, to force an extra round-trip to confirm that the
0-rtt data was not an unintended replay.

Nico
-- 


From nobody Thu May  4 17:18:35 2017
Return-Path: 
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 1C63A127B57 for ; Thu,  4 May 2017 17:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Y244FRF2SymI for ; Thu,  4 May 2017 17:18:33 -0700 (PDT)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4288127873 for ; Thu,  4 May 2017 17:18:33 -0700 (PDT)
Received: by mail-pf0-x243.google.com with SMTP id v14so3939434pfd.3 for ; Thu, 04 May 2017 17:18:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WlAKm6gY9F3oXJ01eehek38qsPplsAo5wQ+OUaKYn0E=; b=ijvuCNSwNnyMZWvVxs7d4N1bD47xBqKSxgejcEqw8RA1kDVekbcJd/GlShZ+2xNGFs Or76lzT0gGttCd0sygQ3zdo9gR/80LmNYwdgjE9jRf9ZKliDjkpJPN5ULeB9UGPLxSL6 jrrdv5H1ja6ZveZmaiLaLR8v0GCjwQuudVlO7TACoPe/RKgqlmU5vr79JkDBtX680e+5 PDhHPdg9EWDcjC7LDsZy1+y55Lv9DZWEWMSCXUQzr7llhDmzJ822RoSQZcKe0a6vlIlN wSyvtZssOsBNigG7Ls6GtqNFIBhdz4WNY0Oosu9b7wV+mhV39XPoofVcK2mrkfTrNw0U K1cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WlAKm6gY9F3oXJ01eehek38qsPplsAo5wQ+OUaKYn0E=; b=ePRatF6BrHCIAr/eui+sKYAYK5DKH1mWsXWoNLHcvgdYN23JMzjU2Si+vEpJoKBRp/ dYc6J0QksCh8FKYY3WH4ntsBuJGTkfC/CwyqBhlANFcX3lP8r9zBqeaUTsVctN1LH/UG o4EoWNaIN6xxTWhsqGOABhph/eVHOGu0pZjZSr5oiN84/OwyL/502KNmukcACdCcId9M GYhsBHZeWXoQ+R6+jO/5a2WnP/aZhpPeMCjMqEcAmpNmqHeCc5z8u3GZGpyzSxnldGjY BL2wfS0wU5vmDGLInEn6TcF/zctuyCQ2be1pbkk6u575+kCqInFp403a6Hq8YplMMkTA ymDA==
X-Gm-Message-State: AN3rC/4rcxFCtU7IjHKf7R2CApPoD3efsFb0SgAVm66mo5gwJo/jCuPV O1CafHw0zzNfUJR3KbIV0ylpiqekpQ==
X-Received: by 10.99.112.68 with SMTP id a4mr130706pgn.198.1493943513187; Thu, 04 May 2017 17:18:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.163.12 with HTTP; Thu, 4 May 2017 17:18:32 -0700 (PDT)
In-Reply-To: <20170504235812.GA10188@localhost>
References:  <20170504235812.GA10188@localhost>
From: Watson Ladd 
Date: Thu, 4 May 2017 17:18:32 -0700
Message-ID: 
To: Nico Williams 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 00:18:35 -0000

On Thu, May 4, 2017 at 4:58 PM, Nico Williams  wrote:
> On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote:
>> 0-RTT is opt-in per protocol, and what we think of per application.
>
> Yes.
>
>> But it isn't opt-in for web application developers. Once browsers and
>> servers start shipping, 0-RTT will turn on by accident or deliberately
>> at various places in the stack.
>
> It should be up to servers whether a request is allowed with 0-rtt.

Which server?  It's possible that the backhauls from the server the
TLS connection is made to to the server actually responding to the
request do not distinguish 0-RTT from other data. Opportunity for
administrative bloopers is immense: even if the responding server
rejects 0-RTT, the server proxying requests won't necessarily know
that inline as it is reusing the connection.


>
>> In conclusion I think there is some thought that needs to go into
>> handling 0-RTT on the web, but it is manageable. I don't know about
>> other protocols, but they don't have the same kinds of problem as the
>> web does with lots of request passing around. Given the benefits here,
>> I think people will really want 0-RTT, and we are going to have to
>> figure out how to live with it.
>
> Yes.
>
> In particular there has to be a way, either in-TLS, or at the
> application layer, to force an extra round-trip to confirm that the
> 0-rtt data was not an unintended replay.

One can always reject... unless I am misunderstanding the suggestion.
>
> Nico
> --



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.


From nobody Thu May  4 18:31:59 2017
Return-Path: 
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 C1C44128BA2 for ; Thu,  4 May 2017 18:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bSZQMqwfQr5E for ; Thu,  4 May 2017 18:31:56 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FFB126557 for ; Thu,  4 May 2017 18:31:56 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id j29so23838182qtj.1 for ; Thu, 04 May 2017 18:31:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iaCGUUGnxPBijKvLOPlOl+XoPcLIp4NKcvKY6Hi3TuE=; b=AH+uFrPGyb+nWbJm2Ks8yVScsdCab4BR53NnJaJfHNrfH1PN4kBkKmcBu001Wj/7o6 vTyuoP8OCUMjn8N9a5SJU+nMT5ZZWETpTUUJJ02nf6iyvZZMONdbXoKavK7tpzM7IqW7 klTX6CyYEri2M2L4+pACwcIqlFsrbOuIdM7up8M+Xwpe0A9Fmf1ACpecq1Z6v2I/2sI0 ObGixCkEG5aMtJEke56e5kCAvid3aixyVLOarI2XDLQDXc1pZFtuCsX9Z/8Ec+94cG+f ZOveVlakLueRT5ciknMqzlzIYSwha6ZfaCTks30b5MBiHg7Qpc8KfyTPTjWKuoC8GGuH KtlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iaCGUUGnxPBijKvLOPlOl+XoPcLIp4NKcvKY6Hi3TuE=; b=eQ+DtBUxZME3FpTaR6gOVnj58XkvfrcLP5rWIKs+raHH0+NcdH6l+3zifTL8mGEPkG s3xGX2Z/ZYJJSsZw2Jdhrx37bPwFHxzt2BBK9lSjiMiO1Zw4lJcs8YqFwXOeTTaORQ+v 5znLJ4PmmCmdyd/DYI5jWNr8oirUk6gaGlXticM02iLiWEQJS0L55CEUcCZ9QxIkic2k Zhm1wrRX+YISjD2ORuWAtnobSFz6TliY+axtozfPaOKDUGQ9CLtny7oFBGOUXFchazY2 eb/pYHKPSG3gtrn2YGtufzFSPmDMmsehVtVHu55RtzraKCTN6lnn4F2CEp9IgGhHRjHn +BUw==
X-Gm-Message-State: AN3rC/6DTl8PTKxzyF2okjOYoMculzphK70DjlsQrGvNxrVvLSnhda4i g+MCIfcEjyGOozIhey3ykJvae3ogBQ==
X-Received: by 10.200.45.187 with SMTP id p56mr10080598qta.208.1493947915606;  Thu, 04 May 2017 18:31:55 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.12.172.151 with HTTP; Thu, 4 May 2017 18:31:55 -0700 (PDT)
In-Reply-To: 
References:  <20170504235812.GA10188@localhost> 
From: Erik Nygren 
Date: Thu, 4 May 2017 21:31:55 -0400
X-Google-Sender-Auth: PkmFaMzlu6MFwl6kKmVrt-wDZkg
Message-ID: 
To: Watson Ladd 
Cc: Nico Williams , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113fdb0ad2b76d054ebcdaa1
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 01:31:58 -0000

--001a113fdb0ad2b76d054ebcdaa1
Content-Type: text/plain; charset=UTF-8

On Thu, May 4, 2017 at 8:18 PM, Watson Ladd  wrote:

> >
> > It should be up to servers whether a request is allowed with 0-rtt.
>
> Which server?  It's possible that the backhauls from the server the
> TLS connection is made to to the server actually responding to the
> request do not distinguish 0-RTT from other data. Opportunity for
> administrative bloopers is immense: even if the responding server
> rejects 0-RTT, the server proxying requests won't necessarily know
> that inline as it is reusing the connection.
>

+1

By the time the client has sent 0-RTT data the complexity mess
has already and it may be too late to avoid some of the potential
vulnerabilities.

Just as an example of a type of attack:  attacker replays 0-RTT messages.
If the server accepts some (sends larger responses) and rejects others
(sends smaller
responses) than that tells you something about the messages
and the attacker you can tell which client requests might have been
replay-safe
and which ones were not.

      Erik

--001a113fdb0ad2b76d054ebcdaa1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, May 4, 2017 at 8:18 PM, Watson Ladd <watsonbladd@gmail.com>=
 wrote:
>

> It should be up to servers whether a request is allowed with 0-rtt.


Which server?=C2=A0 It's possible that the backhauls from the se=
rver the

TLS connection is made to to the server actually responding to the

request do not distinguish 0-RTT from other data. Opportunity for

administrative bloopers is immense: even if the responding server

rejects 0-RTT, the server proxying requests won't necessarily know

that inline as it is reusing the connection.

+1
By the time the client has sent 0-RTT data the complexity m=
ess
has already and it may be too late to avoid some of the potential
vulnerabilities.

Just as an example of a type=
 of attack:=C2=A0 attacker replays 0-RTT messages.
If the server accepts=
 some (sends larger responses) and rejects others (sends smaller
respons=
es) than that tells you something about the messages
and the attacker yo=
u can tell which client requests might have been replay-safe
and which o=
nes were not.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

=






--001a113fdb0ad2b76d054ebcdaa1--


From nobody Thu May  4 20:23:03 2017
Return-Path: 
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 DBD7C127843 for ; Thu,  4 May 2017 20:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 PiYIM6KyEkG8 for ; Thu,  4 May 2017 20:23:00 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDDB1277BB for ; Thu,  4 May 2017 20:22:57 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v453MuhI004617; Thu, 4 May 2017 23:22:56 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Watson Ladd 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Idempotency and the application developer
Thread-Index: AQHSxS8sLEgtZLcRiU6gEs91lLXuBqHlVnWA
Date: Fri, 5 May 2017 03:22:56 +0000
Message-ID: <68D0AF2E-2F8E-4793-8E0D-1DD348E69001@ll.mit.edu>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.26.146.68]
Content-Type: multipart/signed; boundary="Apple-Mail=_22515DEF-39F5-42FC-A6BA-F08DC7D606FC"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-05_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705050033
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 03:23:02 -0000

--Apple-Mail=_22515DEF-39F5-42FC-A6BA-F08DC7D606FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On May 4, 2017, at 19:35, Watson Ladd  wrote:
>=20
> Dear all,
>=20
> Applications have always had to deal with the occasional replay,
> whether from an impatient user or a broken connection at exactly the
> wrong time. But they've generally been rare, so human-in-the-loop
> responses work. Order the same book twice? Just return one of them,
> and if you get an overdraft fee, ouch, we're sorry, but nothing we can
> do.

Very few applications have been designed with deliberate malicious =
=E2=80=9Cintelligent=E2=80=9D interference in mind. Probably none among =
those that delegate their communications security to a =E2=80=9Csecurity =
protocol=E2=80=9D such as TLS or IPsec. After all, a big selling point =
of using (somebody else=E2=80=99s) security protocol/implementation is =
that the security responsibilities are =E2=80=9Coutsourced=E2=80=9D to =
that other layer/entity/.

Haven=E2=80=99t you heard this: =E2=80=9CI don=E2=80=99t know how to =
secure my pipe, and I don=E2=80=99t have to - I use TLS for that=E2=80=9D.=


So far the consequences have been rather mild, not much worse than what =
Watson showed as examples to illustrate his point. But it is changing, =
and not for the better.
=20
Summary: it is not good to deliberately ignore malicious replays.=

--Apple-Mail=_22515DEF-39F5-42FC-A6BA-F08DC7D606FC
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITXzCCBLww
ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc
KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif
Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP
Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa
HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll
Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN
/c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC
AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0
dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E
LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow
gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS
AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI
hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu
MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF
/M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT
kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi
pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba
vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV
BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw
EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18
tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o
vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li
hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+
yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9
dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y
EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG
SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G
CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA
A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM
JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni
gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua
94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q
FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE6jCCA9KgAwIBAgIKSUBIdwAAAAC3
lzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE3MDQwNzE5MzYy
NFoXDTIwMDQwNjE5MzYyNFowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1
ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8OK5RGbI6mDfMw/2HPG57y1TdKRaQ
wlj5iSXC4gDgtv34L93tRDUTjA27kFG5HOrWar2c37RMkVX7nFR9TfGZh66CSe7Lj7ZMZ3wNyodJ
qptavXaVDjSuqp6sPJGQFZNr/pIA2g/3uUOq/igeInptaYb3eDsTwt4fv4G3iLp5Z/4bd26LDJlt
FZnEqOsLsQ3xfkAAaht55x+jl1QNm7+Vfe4RVeInASY7xZu9dQUJChc46p7sVcV9/exjYIkOeeG9
QB6i4CJK4vHbyF2qG+IqZfeYFjXWy3Eq7a7YrgqAl81Xs4Bpjsn9zPlFlwmHNVUBJTgShUqlkFvq
Kjcw0FDpAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUWa29JQeRiwuEcAGFzsv/xdyErcAwDgYDVR0P
AQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm
oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G
CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG
G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD
g+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBs
bC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZI
hvcNAQELBQADggEBAIjee93wr/GEbKbqkXc5krqRGzwcj6/NhW9rmX+MwXqm63OL+/H159UXdIQC
qdd1uovIOcK8y/gXjlJOJ6ol54aixafqsz3ozZ+eIUvphrxRVTxR8vVb17QnPxOQE0Mx9N1uRS+H
ps7XgDS628KYfzxMb12+2WriuwyMVAVl+lCBF1S4ZO/0NBx/wVyEu8Hi73kHC93/4HC1c4bwoExA
AjY+twm7VBY8eTpvV/604iDf1NdKtCb5l1fFZkyZnQ5ZDKONBehGsRGF0eWBUDCopoYTu8nbcRoc
vRGM+ZLFtPLh5xlpjrO2E+CE6Bjx948aoJJCXqHf7BeKxlbazvl2RaIwggTtMIID1aADAgECAgoz
OJSPAAAAAG6WMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu
Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcNMTYw
MTE0MTczMDM5WhcNMTkwMTEzMTczMDM5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExp
bmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVy
aS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOMUNoaJvTuYcF01pUw2
mP37iIlr4r0BxM3fL6JTXKC28cbhyi14MF/vtk3W7B236Wh1bQLxfIbjey5J+k2n+jAs5QSUVqAC
c+ocC8BQjCyXkCPOdykk/7vxSLi7fhow2x10/5Bm70cjZCD4/p4wPbmOSPJtP11AzFdmk7ahMHOe
VaNggi11mErUNZmohHRq3ufZiMJJCxk1fSUngnCu2MdgWtg+edkLR/UHYztXnghLzrcITJ+7lei2
hnHxi4fBikpIWrzRISHpwwMt1N7VkCNbGydvIoLriut5K3IjY9U324FZ346V4aggCNWiCkwoqLSl
JEdwK7APAZ6SlBW5sr0CAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTxT8WImaJstmXb4pw1tVYTY9mK
mzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0f
BCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcB
AQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggr
BgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisG
AQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd
JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwGQYDVR0R
BBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAt
AFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAFu6+z2bSBLlTwkm5Vz6q21XYFZDSMN6lelh8//E3ytVJ
xE8d7ZIxRoUfk4xGGF4YmR2iBZU2cyuMfFB+l9zTPzKi2UPfHBcQ1ZRjkyhCakQYHaSwWqAx3XbV
urNHdZjzgtyix+jDQyimVezya87tOejPAz4+0ZmzSamnY/MGS9Z01uzav/vBck/r+kt3nM+/LBE2
FOChV7Vo3iK8iRTyy+QoyCC/llo6yidpbwlLp1Ria++TRC8MlEhA1FHTOlCk4qn7hX9eExlGHFAn
cONVOOH1D+kcqbsBEWEWvdAAnqhwKPLMsXmKyxrVWyHHsSUEiTRxeF6nqYswuoY1fdrMCTGCAskw
ggLFAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx
DDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMwIKSUBIdwAAAAC3lzAJBgUrDgMCGgUA
oIIBPzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDUwMzIy
NTZaMCMGCSqGSIb3DQEJBDEWBBQ4Q8KmZ0dmL8sDXxfgU/MRaJxWuzBuBgkrBgEEAYI3EAQxYTBf
MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL
EwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM4lI8AAAAAbpYwcAYLKoZIhvcNAQkQAgsxYaBf
MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL
EwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQEBBQAEggEA
sjp8Isnoal3wOxlXnqX5OfXYkyeCf/tNzQNwrW0vbhpZ0KIevGVgs1j2HPKoEKi1+6e2SGsPQ2RD
fzE6id4RCG+zPA4MkDswVmrs//9mbzt38GTxYmZlIKH4lubZRYW4MjMZQkb1tCCLAr/a9xFaxVqn
PxsfrLFKicgHUNyfS+pgbDN9d+FnSyDo4l/pSZxiCtbP7XvbYtGVFkcb31sXKyA7o5rPcfw8QI4a
/wfgjg6MrwXYzar91vhljVod26C6dOI6I5Sha0hUC1akaPw67/Ts+sZ5h9hEXEPsmBs76ZBbbxwE
IHYtMkycXanMHhRDo0TXnsMADLaavBqfnlf72wAAAAAAAA==

--Apple-Mail=_22515DEF-39F5-42FC-A6BA-F08DC7D606FC--


From nobody Thu May  4 20:37:00 2017
Return-Path: 
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 AE72A12741D for ; Thu,  4 May 2017 20:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 XXd1pskE9okG for ; Thu,  4 May 2017 20:36:57 -0700 (PDT)
Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7AF127599 for ; Thu,  4 May 2017 20:36:57 -0700 (PDT)
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id B0808C009F49; Thu,  4 May 2017 20:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=I6zDF0D6J/0GA7 AzDHddgmaAVOo=; b=PiVUjJgdk0rMGVnjXuVNmOgjPEqyOz9hp1qpAcOUS8414O 8rHanGWgu9jdO4jPa6trGZOX1bEKKy2yUVpNIe9pZ0N9PxtmTTf0HFGROFB16y6i 4RZOS56IQlAPDgjGkFs6LAf3xWKRq8H07/Dd6NuY1CwLWDrG9+ayR+GHfOgYg=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 62978C009F46; Thu,  4 May 2017 20:36:56 -0700 (PDT)
Date: Thu, 4 May 2017 22:36:53 -0500
From: Nico Williams 
To: Watson Ladd 
Cc: "tls@ietf.org" 
Message-ID: <20170505033652.GB10188@localhost>
References:  <20170504235812.GA10188@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 03:36:59 -0000

On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
> On Thu, May 4, 2017 at 4:58 PM, Nico Williams  wrote:
> > On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote:
> >> 0-RTT is opt-in per protocol, and what we think of per application.
> >
> > Yes.
> >
> >> But it isn't opt-in for web application developers. Once browsers and
> >> servers start shipping, 0-RTT will turn on by accident or deliberately
> >> at various places in the stack.
> >
> > It should be up to servers whether a request is allowed with 0-rtt.
> 
> Which server?  It's possible that the backhauls from the server the
> TLS connection is made to to the server actually responding to the
> request do not distinguish 0-RTT from other data. Opportunity for
> administrative bloopers is immense: even if the responding server
> rejects 0-RTT, the server proxying requests won't necessarily know
> that inline as it is reusing the connection.

The one that terminates TLS.  If that's a reverse proxy, then it has to
know or not allow 0-rtt.  That means that by default reverse proxies
can't accept 0-rtt, and they have to know a lot about the application in
order to accept it (or else let the server know that 0-rtt was used and
let the server give the client an appropriate error if that's not
acceptable).

Nico
-- 


From nobody Thu May  4 21:11:34 2017
Return-Path: 
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 A7443127B52 for ; Thu,  4 May 2017 21:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level: 
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 yo-BOFuOVI4v for ; Thu,  4 May 2017 21:11:31 -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 1D45812741D for ; Thu,  4 May 2017 21:11:31 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 87489496C40; Fri,  5 May 2017 04:11:30 +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 7160A496C1D; Fri,  5 May 2017 04:11:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493957490; bh=RMYw1w5TrM0vbIdPyeDKSFdujJY0o9dNxvPAXKLB5EM=; l=2673; h=To:References:Cc:From:Date:In-Reply-To:From; b=UmudTN/aS/ctGt4a7KdhPeBSY+/asT4oNBkSCV+TN8MHM9mWHMgoIy/AapFce2cNQ ES50VIkbeFTF7HHwaf13DLanPGG2TaGEeANaYi6gtHf2/i/a751O6G18Hn6f5td32m HvRrQ2kfATmbtpy3gr8YzqTKaak3/2Bd8x82V7zo=
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 0CA3C1E0A5; Fri,  5 May 2017 04:11:29 +0000 (GMT)
To: Nico Williams , Watson Ladd 
References:  <20170504235812.GA10188@localhost>  <20170505033652.GB10188@localhost>
Cc: "tls@ietf.org" 
From: Benjamin Kaduk 
Message-ID: <3fc4304b-0540-ad4d-6220-15d33cf06645@akamai.com>
Date: Thu, 4 May 2017 23:11:29 -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: <20170505033652.GB10188@localhost>
Content-Type: multipart/alternative; boundary="------------C884CC01DF8A2EE1AFDBBF3A"
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 04:11:33 -0000

This is a multi-part message in MIME format.
--------------C884CC01DF8A2EE1AFDBBF3A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

5/04/2017 10:36 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
>>
>> Which server?  It's possible that the backhauls from the server the
>> TLS connection is made to to the server actually responding to the
>> request do not distinguish 0-RTT from other data. Opportunity for
>> administrative bloopers is immense: even if the responding server
>> rejects 0-RTT, the server proxying requests won't necessarily know
>> that inline as it is reusing the connection.
> The one that terminates TLS.  If that's a reverse proxy, then it has to
> know or not allow 0-rtt.  That means that by default reverse proxies
> can't accept 0-rtt, and they have to know a lot about the application in
> order to accept it (or else let the server know that 0-rtt was used and
> let the server give the client an appropriate error if that's not
> acceptable).
>

I'm very skeptical that this position would survive into real-world
deployments.

-Ben

--------------C884CC01DF8A2EE1AFDBBF3A
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    5/04/2017 10:36 PM, Nico Williams wrote:

    

      
On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:


      


        
Which server?  It's possible that the backhauls from the server the
TLS connection is made to to the server actually responding to the
request do not distinguish 0-RTT from other data. Opportunity for
administrative bloopers is immense: even if the responding server
rejects 0-RTT, the server proxying requests won't necessarily know
that inline as it is reusing the connection.


      

      
The one that terminates TLS.  If that's a reverse proxy, then it has to
know or not allow 0-rtt.  That means that by default reverse proxies
can't accept 0-rtt, and they have to know a lot about the application in
order to accept it (or else let the server know that 0-rtt was used and
let the server give the client an appropriate error if that's not
acceptable).



    

    

    I'm very skeptical that this position would survive into real-world
    deployments.

    

    -Ben

  


--------------C884CC01DF8A2EE1AFDBBF3A--


From nobody Thu May  4 21:14:04 2017
Return-Path: 
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 9F4B8128C84 for ; Thu,  4 May 2017 21:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 xEe9lawIsQxz for ; Thu,  4 May 2017 21:14:02 -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 55CF012741D for ; Thu,  4 May 2017 21:14:02 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1A392496C68; Fri,  5 May 2017 04:14:02 +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 044F9496C1D; Fri,  5 May 2017 04:14:02 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493957642; bh=hzgIdaoIzb7AOZzB8CRt5d3bFeUwoqY1713r9YtiyYs=; l=1959; h=To:References:Cc:From:Date:In-Reply-To:From; b=P1zyDqaoEd/mFPgDYZK6lsmzOjeyYYFdP/5wD6aZV+OEttRuC88y9woJpiOoBjj7s 584pngHbOHVpr5Zb82b1Z62K3Scco6preI2MSnFyy42mHm2Ct2vdqTdP3C29GMh3sE wfXIMcqgrGFiuYCt6IXceeuAQafvM5Reyz3zYit0=
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 928CC1E0EB; Fri,  5 May 2017 04:14:01 +0000 (GMT)
To: Watson Ladd , Nico Williams 
References:  <20170504235812.GA10188@localhost> 
Cc: "tls@ietf.org" 
From: Benjamin Kaduk 
Message-ID: 
Date: Thu, 4 May 2017 23:14:01 -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: 
Content-Type: multipart/alternative; boundary="------------9BC827290D6E9F344E46BAC2"
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 04:14:04 -0000

This is a multi-part message in MIME format.
--------------9BC827290D6E9F344E46BAC2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/04/2017 07:18 PM, Watson Ladd wrote:
> On Thu, May 4, 2017 at 4:58 PM, Nico Williams  wrote:
>>
>> In particular there has to be a way, either in-TLS, or at the
>> application layer, to force an extra round-trip to confirm that the
>> 0-rtt data was not an unintended replay.
> One can always reject... unless I am misunderstanding the suggestion.
>

I'm pretty sure Nico still wants data-dependent reject, which is not
workable in the general case.  (See the discussion of reverse proxies.)

-Ben

--------------9BC827290D6E9F344E46BAC2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/04/2017 07:18 PM, Watson Ladd wrote:

    

      
On Thu, May 4, 2017 at 4:58 PM, Nico Williams <nico@cryptonector.com> wrote:


      


      

      

        
In particular there has to be a way, either in-TLS, or at the
application layer, to force an extra round-trip to confirm that the
0-rtt data was not an unintended replay.


      

      
One can always reject... unless I am misunderstanding the suggestion.


      

    

    

    I'm pretty sure Nico still wants data-dependent reject, which is not
    workable in the general case.  (See the discussion of reverse
    proxies.)

    

    -Ben

  


--------------9BC827290D6E9F344E46BAC2--


From nobody Thu May  4 21:22:52 2017
Return-Path: 
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 C2CA9127B52 for ; Thu,  4 May 2017 21:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 11qBitoDl7UT for ; Thu,  4 May 2017 21:22:49 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 476A212773A for ; Thu,  4 May 2017 21:22:49 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A62B243342B; Fri,  5 May 2017 04:22:48 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8656143342A; Fri,  5 May 2017 04:22:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493958168; bh=7k07ddUzgY6rSyHUrqksnB+s40dgAD2bwyNjygGz/40=; l=3877; h=To:References:From:Date:In-Reply-To:From; b=Q6DyS0DUNQ0UgtTTbMYd6lqeij2I75C8XOSMVfC1+rQ38HdtSB7oaFHujkD++X9qY KsJJkT5C5VGwKOvpYJEJUYPuOldWlIDR3AwME2XTjV9yxIr0UVYMtJoqUU2ejCx3wj n9goz0nmt9aSsXo/HDLMbf9/V2oQgOz83OP/gQqc=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 568C91FD30; Fri,  5 May 2017 04:22:48 +0000 (GMT)
To: Watson Ladd , "tls@ietf.org" 
References: 
From: Benjamin Kaduk 
Message-ID: <830b5237-d3d1-2f3b-3e8d-a4cc75870fd9@akamai.com>
Date: Thu, 4 May 2017 23:22:47 -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: 
Content-Type: multipart/alternative; boundary="------------FEF34F7237C829AFBFE4B398"
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 04:22:51 -0000

This is a multi-part message in MIME format.
--------------FEF34F7237C829AFBFE4B398
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/04/2017 06:35 PM, Watson Ladd wrote:
> If you are willing to buffer 0-RTT until completion before going to
> the thing that makes the response, you can handle this problem for the
> responsemaker. This will work for most applications I can think of,
> and you need to handle large, drawn out requests anyway. This sounds
> like it would work as a solution, but I am sure there are details I
> haven't discovered yet.

The server is allowed to buffer the 0-RTT data while processing it and
delay a response until the handshake is completed, yes.  (I think this
is the "way to force 1-RTT at the application layer" that Nico wants.) 
It removes the latency benefits of 0-RTT [for that request] and might be
annoying to implement with APIs that only give you a single data stream
(but probably not too bad), but the application layer at the server has
the capability to solve these idempotency/replay problems. 
Unfortunately, we are the TLS layer and cannot assume that we control or
can cooperate with the application.  Which leads right back to the
"application profile is required" bit, of course.

-Ben

> In conclusion I think there is some thought that needs to go into
> handling 0-RTT on the web, but it is manageable. I don't know about
> other protocols, but they don't have the same kinds of problem as the
> web does with lots of request passing around. Given the benefits here,
> I think people will really want 0-RTT, and we are going to have to
> figure out how to live with it.
>


--------------FEF34F7237C829AFBFE4B398
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/04/2017 06:35 PM, Watson Ladd wrote:

    

      
If you are willing to buffer 0-RTT until completion before going to
the thing that makes the response, you can handle this problem for the
responsemaker. This will work for most applications I can think of,
and you need to handle large, drawn out requests anyway. This sounds
like it would work as a solution, but I am sure there are details I
haven't discovered yet.


    

    

    The server is allowed to buffer the 0-RTT data while processing it
    and delay a response until the handshake is completed, yes.  (I
    think this is the "way to force 1-RTT at the application layer" that
    Nico wants.)  It removes the latency benefits of 0-RTT [for that
    request] and might be annoying to implement with APIs that only give
    you a single data stream (but probably not too bad), but the
    application layer at the server has the capability to solve these
    idempotency/replay problems.  Unfortunately, we are the TLS layer
    and cannot assume that we control or can cooperate with the
    application.  Which leads right back to the "application profile is
    required" bit, of course.

    

    -Ben

    

    

      
In conclusion I think there is some thought that needs to go into
handling 0-RTT on the web, but it is manageable. I don't know about
other protocols, but they don't have the same kinds of problem as the
web does with lots of request passing around. Given the benefits here,
I think people will really want 0-RTT, and we are going to have to
figure out how to live with it.



    

    

  


--------------FEF34F7237C829AFBFE4B398--


From nobody Thu May  4 21:53:07 2017
Return-Path: 
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 10D6E1293F9 for ; Thu,  4 May 2017 21:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 OTqPCJjm76aE for ; Thu,  4 May 2017 21:53:04 -0700 (PDT)
Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6233129406 for ; Thu,  4 May 2017 21:53:02 -0700 (PDT)
Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 193CE6000A60B; Thu,  4 May 2017 21:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tk8u9/iyb6qvcW S8QHvzLbIv3y4=; b=aOx6OisZUrRvYrWVshFlIWHpnJsWiEEnnZtMKdp6aNsJB+ c19Pz7zt4WYz1K6UpTsuumjRiKlyaByzJ3kch24UEKxdCRKDgRA2bUCAxJF7NNmy WW/plhM/5/u9dWeIL/NILPVcbvsED82QIiV4T3jj/muLyYXjm2BdjJb8vvzsI=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id ACAC160002A24; Thu,  4 May 2017 21:53:01 -0700 (PDT)
Date: Thu, 4 May 2017 23:52:59 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: Watson Ladd , "tls@ietf.org" 
Message-ID: <20170505045254.GC10188@localhost>
References:  <20170504235812.GA10188@localhost>  <20170505033652.GB10188@localhost> <3fc4304b-0540-ad4d-6220-15d33cf06645@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3fc4304b-0540-ad4d-6220-15d33cf06645@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 04:53:06 -0000

On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote:
> 5/04/2017 10:36 PM, Nico Williams wrote:
> > On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
> >>
> >> Which server?  It's possible that the backhauls from the server the
> >> TLS connection is made to to the server actually responding to the
> >> request do not distinguish 0-RTT from other data. Opportunity for
> >> administrative bloopers is immense: even if the responding server
> >> rejects 0-RTT, the server proxying requests won't necessarily know
> >> that inline as it is reusing the connection.
> > The one that terminates TLS.  If that's a reverse proxy, then it has to
> > know or not allow 0-rtt.  That means that by default reverse proxies
> > can't accept 0-rtt, and they have to know a lot about the application in
> > order to accept it (or else let the server know that 0-rtt was used and
> > let the server give the client an appropriate error if that's not
> > acceptable).
> 
> I'm very skeptical that this position would survive into real-world
> deployments.

Which part?


From nobody Thu May  4 21:55:14 2017
Return-Path: 
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 744E3129423 for ; Thu,  4 May 2017 21:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 9wzf5AVNIfSz for ; Thu,  4 May 2017 21:55:12 -0700 (PDT)
Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772D4129406 for ; Thu,  4 May 2017 21:55:12 -0700 (PDT)
Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 03BEB6000A60C; Thu,  4 May 2017 21:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uz9MLyU5ubT9SK RS5mdpi0Jmy7M=; b=i2cvNB11bR2nGtDhrtQNwdBUbjx7723WbzSCT2b9O0WKIa Kt/jDyLyB25ruA3zynFO4LR9F4m+6c6NpmI4kbx4BHo3a7IFZq29drr4Z6e3M1tz 2+E/FIfZcqmk4QNEIKzc5X5BKaQCdl+yzUOQfpC9UpkUNFhwVRMqT221JMS8k=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 8EE176000A60B; Thu,  4 May 2017 21:55:11 -0700 (PDT)
Date: Thu, 4 May 2017 23:55:09 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: Watson Ladd , "tls@ietf.org" 
Message-ID: <20170505045508.GD10188@localhost>
References:  <20170504235812.GA10188@localhost>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 04:55:13 -0000

On Thu, May 04, 2017 at 11:14:01PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 07:18 PM, Watson Ladd wrote:
> > On Thu, May 4, 2017 at 4:58 PM, Nico Williams  wrote:
> >> In particular there has to be a way, either in-TLS, or at the
> >> application layer, to force an extra round-trip to confirm that the
> >> 0-rtt data was not an unintended replay.
> > One can always reject... unless I am misunderstanding the suggestion.
> 
> I'm pretty sure Nico still wants data-dependent reject, which is not
> workable in the general case.  (See the discussion of reverse proxies.)

What I want?  I'm saying that 0-rtt requires much care.  Specifically it
requires any of:

 - replay caching
 - not allowing 0-rtt for non-idempotent data (there are several ways to
   "not allow" 0-rtt in this case)

Take your pick.

Nico
-- 


From nobody Thu May  4 22:04:19 2017
Return-Path: 
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 BF8D6129410 for ; Thu,  4 May 2017 22:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level: 
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 0PTiMxZt8LCE for ; Thu,  4 May 2017 22:04:16 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 627CB1293E0 for ; Thu,  4 May 2017 22:04:16 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 115F1200012; Fri,  5 May 2017 05:04:16 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E511B200027; Fri,  5 May 2017 05:04:15 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493960655; bh=Q2weMzlsrpSCaRDzEOiu0M4Qc7Sld8dr4etMCvFB0iU=; l=3575; h=To:References:Cc:From:Date:In-Reply-To:From; b=AsyHI6ArsAv87b/6KJE7gey2SHJKIXjBfCMCGrWQY3Vj5jlOWhhRmPJ3ulHNSbEkB ukkx8ag+n5LGP4uAU5G9+toQhv6TETAMD48fRvLrlvlnQ2vy+7ipChW5af8ce4u2xL 4G1ehY1zDqPXvjiMaiCuuBHvve7yPp+3emHFrH8A=
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 80D151E0AA; Fri,  5 May 2017 05:04:15 +0000 (GMT)
To: Nico Williams 
References:  <20170504235812.GA10188@localhost>  <20170505033652.GB10188@localhost> <3fc4304b-0540-ad4d-6220-15d33cf06645@akamai.com> <20170505045254.GC10188@localhost>
Cc: Watson Ladd , "tls@ietf.org" 
From: Benjamin Kaduk 
Message-ID: <24861825-7e2d-8a97-0b0a-67f176b92d6d@akamai.com>
Date: Fri, 5 May 2017 00:04:14 -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: <20170505045254.GC10188@localhost>
Content-Type: multipart/alternative; boundary="------------668296ECEB2D18DBE5B25B75"
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 05:04:18 -0000

This is a multi-part message in MIME format.
--------------668296ECEB2D18DBE5B25B75
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/04/2017 11:52 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote:
>> 5/04/2017 10:36 PM, Nico Williams wrote:
>>> On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
>>>> Which server?  It's possible that the backhauls from the server the
>>>> TLS connection is made to to the server actually responding to the
>>>> request do not distinguish 0-RTT from other data. Opportunity for
>>>> administrative bloopers is immense: even if the responding server
>>>> rejects 0-RTT, the server proxying requests won't necessarily know
>>>> that inline as it is reusing the connection.
>>> The one that terminates TLS.  If that's a reverse proxy, then it has to
>>> know or not allow 0-rtt.  That means that by default reverse proxies
>>> can't accept 0-rtt, and they have to know a lot about the application in
>>> order to accept it (or else let the server know that 0-rtt was used and
>>> let the server give the client an appropriate error if that's not
>>> acceptable).
>> I'm very skeptical that this position would survive into real-world
>> deployments.
> Which part?

No matter what we way here, there will be reverse proxies deployed on
the internet in the next 5 years that blindly accept 0-RTT knowing
nothing about the application and not letting the server know that 0-RTT
was used.

-Ben

--------------668296ECEB2D18DBE5B25B75
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 05/04/2017 11:52 PM, Nico Williams wrote:

    

      
On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote:


      

        
5/04/2017 10:36 PM, Nico Williams wrote:


        

          
On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:


          

            
Which server?  It's possible that the backhauls from the server the
TLS connection is made to to the server actually responding to the
request do not distinguish 0-RTT from other data. Opportunity for
administrative bloopers is immense: even if the responding server
rejects 0-RTT, the server proxying requests won't necessarily know
that inline as it is reusing the connection.


          

          
The one that terminates TLS.  If that's a reverse proxy, then it has to
know or not allow 0-rtt.  That means that by default reverse proxies
can't accept 0-rtt, and they have to know a lot about the application in
order to accept it (or else let the server know that 0-rtt was used and
let the server give the client an appropriate error if that's not
acceptable).


        

        
I'm very skeptical that this position would survive into real-world
deployments.


      

      
Which part?


    

    

    No matter what we way here, there will be reverse proxies deployed
    on the internet in the next 5 years that blindly accept 0-RTT
    knowing nothing about the application and not letting the server
    know that 0-RTT was used.

    

    -Ben

  


--------------668296ECEB2D18DBE5B25B75--


From nobody Thu May  4 22:04:26 2017
Return-Path: 
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 30AA91293E0 for ; Thu,  4 May 2017 22:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 agFxMPyuBKUC for ; Thu,  4 May 2017 22:04:17 -0700 (PDT)
Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DCF1293F9 for ; Thu,  4 May 2017 22:04:16 -0700 (PDT)
Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 205E26000A60B; Thu,  4 May 2017 22:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=CruxRLy4HJ+8dr vdoSWlogZj6vY=; b=VQ7OBIrCI4dG8Mxchb0Yybv4h843CJB6f81qGTddtxiT6Z 2oIUFjKWb/W9I9zusGQiNMyX8DPWDKj1LIVLNdR0cYstMjT7gvqtyCGl8kPNGBmP ydRrdYPqfkxFD/bdXReV9C1FO5zPcytxS6prHYZOabpGzpfVhNLKK/f2H6VuU=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id B3E3760002A24; Thu,  4 May 2017 22:04:15 -0700 (PDT)
Date: Fri, 5 May 2017 00:04:13 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: Watson Ladd , "tls@ietf.org" 
Message-ID: <20170505050412.GE10188@localhost>
References:  <830b5237-d3d1-2f3b-3e8d-a4cc75870fd9@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <830b5237-d3d1-2f3b-3e8d-a4cc75870fd9@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 05:04:18 -0000

On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 06:35 PM, Watson Ladd wrote:
> > If you are willing to buffer 0-RTT until completion before going to
> > the thing that makes the response, you can handle this problem for the
> > responsemaker. This will work for most applications I can think of,
> > and you need to handle large, drawn out requests anyway. This sounds
> > like it would work as a solution, but I am sure there are details I
> > haven't discovered yet.
> 
> The server is allowed to buffer the 0-RTT data while processing it and
> delay a response until the handshake is completed, yes.  (I think this
> is the "way to force 1-RTT at the application layer" that Nico wants.) 

I'm not up on the details of how 0-rtt works in TLS 1.3.  I don't know
if there's a way for the server to cause a round-trip to occur, nor if
there's a way for the client to then confirm the 0-rtt data in that
round-trip.

I do think having such functionality would be very helpful for cases
where the server runs a) without a replay cache, and b) can accept
idempotent and non-idempotent requests.

I think always requiring a replay cache is not likely to work out in
practice.

> It removes the latency benefits of 0-RTT [for that request] and might be

Because [for that request] there are no benefits of 0-rtt.

> annoying to implement with APIs that only give you a single data stream
> (but probably not too bad), but the application layer at the server has
> the capability to solve these idempotency/replay problems. 
> Unfortunately, we are the TLS layer and cannot assume that we control or
> can cooperate with the application.  Which leads right back to the
> "application profile is required" bit, of course.

Yes, sure, but the application profile rubber has to meet the road.
That usually means that the devil is in the APIs.

An application that wants a "dumb secure socket"... just can't have
0-rtt.

HTTP should be trivial to profile... if only GET weren't abused here and
there.

Nico
-- 


From nobody Thu May  4 22:07:15 2017
Return-Path: 
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 4A0EC129440 for ; Thu,  4 May 2017 22:07:13 -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 eQkooPIZdNhp for ; Thu,  4 May 2017 22:07:10 -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 BA6D0129410 for ; Thu,  4 May 2017 22:07:10 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4EA6C496C1D for ; Fri,  5 May 2017 05:07:10 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 2F472496C12 for ; Fri,  5 May 2017 05:07:10 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493960830; bh=jPljxFTwhOV7+ML6TWGWig1ho5H8gKiyUVn6Oj/8riY=; l=10211; h=References:From:To:Date:In-Reply-To:From; b=G8ZQFP7iaepG6qLBjhzK0iNJQv+L9w/CGybhY4Rj0z46WK1Js6zS9xISaThqXRgrJ bOqZEqfoDNyDFUy3XTmG5chW635AwfVqCJWtoM0DxGzQhHoXas00DNhrUwPZKk4K2n 2ZSqSkLnF30oJ+GTPqWml4ZsCf2GDGaA5JGqGWQ0=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C9B739809E for ; Fri,  5 May 2017 05:07:09 +0000 (GMT)
References:    
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
To: "tls@ietf.org" 
Message-ID: <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>
Date: Fri, 5 May 2017 00:07:09 -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: 
Content-Type: multipart/alternative; boundary="------------D484BFC7DC3C438287F98F4F"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 05:07:13 -0000

This is a multi-part message in MIME format.
--------------D484BFC7DC3C438287F98F4F
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

Trying to consolidate various things into a single mail...

On 05/04/2017 04:37 PM, Eric Rescorla wrote:
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the
> mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps
> we say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do
> one of these mitigations?
>
>

That seems like an inconsistent position to take (don't do this, but if
you ignore me, do this in this fashion).  Advising application profiles
to consider one of those things might be better.



On 05/04/2017 04:27 PM, Kyle Nekritz wrote:
>
> 2) Preventing clients from sending 0-RTT data multiple times (on
> separate connections) using the same PSK (for forward secrecy reasons)
>
>  
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior
> to receiving a NST (if they are out of cached PSKs). I’d expect the
> need for these retries to be larger with 0-RTT data, particularly when
> 0-RTT data is sent without even a transport roundtrip (in the case of
> TFO or QUIC). Servers are definitely not required to accept multiple
> 0-RTT connections using the same PSK, but I don’t think clients should
> be banned from attempting.
>

Obligatory note that if clients are forbidden from reusing a single PSK
for multiple 0-RTT, they can still use it for 1-RTT.



On 05/04/2017 03:24 PM, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:12 PM, Erik Nygren  > wrote:
>
>     On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla      > wrote:
>
>
>         1. A SHOULD-level requirement for server-side 0-RTT defense,
>         explaining
>         both session-cache and strike register styles and the merits
>         of each.
>
>
>     I don't believe this is technically viable for the large-scale
>     server operators most interested in 0-RTT.
>
>
> I think it is (and work at one of the biggest) ... but if even it
> weren't, that would just imply that we can't have 0-RTT at all, not
> that it's ok to ship an insecure version.

I would be okay with that being the case ... but I don't think that's
actually the case.  Some people are going to do 0-RTT in one form or
another, whether or not we specify it here.  I'd rather have something
well-specified that can be used correctly in some cases and is
unfortunately used in more cases than that, then a
less-well-documented-and-analyzed thing used in those same questionable
cases.


On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> P.S. Care to name (another :) one security-related protocol that
> doesn't provide replay protection?

Some of the earlier uses of Kerberos are subject to replay (hence
kerberos implementations can end up providing replay caches to try and
help, which are not perfect and slow to boot).  More modern exchanges
that use GSS acceptor subkeys are not subject to replay, though.


On 05/03/2017 09:31 PM, Martin Thomson wrote:
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear.  Otherwise, beware.  The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactively blessed.

You can still be in trouble if you used the early exporter, e.g., for
token binding.  We had some discussions in the tokbind session in
Chicago that clarified that handshake completion does not retroactively
bless the properties you want from 0-RTT token binding.


-Ben


--------------D484BFC7DC3C438287F98F4F
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Trying to consolidate various things into a single mail...

    

    On 05/04/2017 04:37 PM, Eric Rescorla wrote:

    

      
In the PR I just posted, I spent most of my time describing
        the

      
mechanisms and used a SHOULD-level requirement to do one of
        the mechanisms.

      
I think there's a bunch of room to wordsmith the requirement.
        Perhaps we say:

      


      

      
- You can't do 0-RTT without an application profile

      
- Absent the application profile saying otherwise you
        SHOULD/MUST do one of these mitigations?

      


      

      


      

    

    

    That seems like an inconsistent position to take (don't do this, but
    if you ignore me, do this in this fashion).  Advising application
    profiles to consider one of those things might be better.

    

    

    

    
On 05/04/2017 04:27 PM, Kyle Nekritz
      wrote:

    

    

      
2)
          Preventing clients from sending 0-RTT data multiple times (on
          separate connections) using the same PSK (for forward secrecy
          reasons)

      
 

      
I
          think this should be allowed. Otherwise, clients will not be
          able to retry 0-RTT requests that fail due to an unknown
          network error prior to receiving a NST (if they are out of
          cached PSKs). I’d expect the need for these retries to be
          larger with 0-RTT data, particularly when 0-RTT data is sent
          without even a transport roundtrip (in the case of TFO or
          QUIC). Servers are definitely not required to accept multiple
          0-RTT connections using the same PSK, but I don’t think
          clients should be banned from attempting.

      

    

    

    Obligatory note that if clients are forbidden from reusing a single
    PSK for multiple 0-RTT, they can still use it for 1-RTT.

    

    

    

    
On 05/04/2017 03:24 PM, Colm
      MacCárthaigh wrote:

    

    
On Thu, May 4, 2017 at 12:12 PM, Erik Nygren <erik+ietf@nygren.org>
      wrote:

      

        

          

            
On Wed, May 3, 2017
                at 11:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:

                

                  


                    
1. A SHOULD-level requirement for server-side
                      0-RTT defense, explaining

                    
both session-cache and strike register styles
                      and the merits of each.

                  

                

                


                

              
              
I don't believe this is technically viable for the
                large-scale server operators most interested in 0-RTT.

            

          

        

      

      


      

      
I think it is (and work at one of the biggest) ... but if
        even it weren't, that would just imply that we can't have 0-RTT
        at all, not that it's ok to ship an insecure version.

    

    

    I would be okay with that being the case ... but I don't think
    that's actually the case.  Some people are going to do 0-RTT in one
    form or another, whether or not we specify it here.  I'd rather have
    something well-specified that can be used correctly in some cases
    and is unfortunately used in more cases than that, then a
    less-well-documented-and-analyzed thing used in those same
    questionable cases.

    

    

    
On 05/03/2017 09:33 PM, Blumenthal, Uri
      - 0553 - MITLL wrote:

    

    
P.S. Care to name (another :) one security-related
      protocol that doesn't provide replay protection?

    

    

    Some of the earlier uses of Kerberos are subject to replay (hence
    kerberos implementations can end up providing replay caches to try
    and help, which are not perfect and slow to boot).  More modern
    exchanges that use GSS acceptor subkeys are not subject to replay,
    though.

    

    

    
On 05/03/2017 09:31 PM, Martin Thomson
      wrote:

    

    

      
A clear delineation of security properties exists, if the handshake is
done, then you are in the clear.  Otherwise, beware.  The separation
of the streams doesn't help if you consider the possibility that 0-RTT
data can be retroactively blessed.

    

    

    You can still be in trouble if you used the early exporter, e.g.,
    for token binding.  We had some discussions in the tokbind session
    in Chicago that clarified that handshake completion does not
    retroactively bless the properties you want from 0-RTT token
    binding.

    

    

    -Ben

    

  


--------------D484BFC7DC3C438287F98F4F--


From nobody Thu May  4 22:13:20 2017
Return-Path: 
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 277711293E1 for ; Thu,  4 May 2017 22:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 jJFM5B8IRfXl for ; Thu,  4 May 2017 22:13:16 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE02129443 for ; Thu,  4 May 2017 22:13:15 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id k11so16245410ywb.1 for ; Thu, 04 May 2017 22:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2k5gn0ZKtzhLu+lYsWd/hQbCainUpleVCBdElsG8yWE=; b=rzoIL6bJFDmJ82jEqAR5ynvDsN4Dyu9LfQrFrvpErZvqIkHnDnkplvpo+TwrCyDDTM OD/rUPnGL0bnORbBczvitNJm8kaZmPoA7N5Ssaj7+Jm4IISTWCyLFygqg1y5oom9u7sw PcVr7bFMBg1xRz1ZfV1CJkm/FjftIff8516ic/aI3o93Q1HtRYduhb587cvOInEhsulw ORqVBbmvTkoDThAT5jk+LK32R50b4xauFgruHUokeCrkZUjA3t5oc5/7WCpfMgmSHAjN Yh5qnA5fuC+X+/SXkbPLdAVNTh/rSE7PhmR1K7bhv43eWTzPm0MkqTS+LwNYg4Cmcmq/ W2EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2k5gn0ZKtzhLu+lYsWd/hQbCainUpleVCBdElsG8yWE=; b=cgosqf46vZ+9zPJeXZALgQqyDcnFFErvYISR4Of2frlvTFdecbBVcMw7LvCkW6afv7 D4pilm7mmlDwYAL6tuZ7K1oHrwL+6iH/k6tymcfrhG9t8sSN7+WRUuBXbNcM8LaKRI1i QPQ/jFiFrIRi/nNbh+eNeIpo/tS91+wb5kKBJ4/rn3af+U4k/qX/3HayXiiDPzQxUTmy 6E5JL6i5q4a2OW/TllYqYIrpImk0SUT2KprHH0me7PoK9N2YAfGR5ub8HTHjLYy5UuBD FZl96fRFNpjDJbjOoVBFeRvGTUQtHAZf0IxUT6Ql63NSBvnI9QmdPPrhozsxV4YaNSLM dzCg==
X-Gm-Message-State: AN3rC/42NccPppWAl0UMbg0DJ59HjlBof/aFjM5Rwwhe1/h8l+pm81x5 681gykHH39IIiAwKd+FYljsGm9z6SNdW
X-Received: by 10.13.255.199 with SMTP id p190mr20367537ywf.312.1493961194725;  Thu, 04 May 2017 22:13:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 4 May 2017 22:12:34 -0700 (PDT)
In-Reply-To: <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>
References:     <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>
From: Eric Rescorla 
Date: Thu, 4 May 2017 22:12:34 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c087eea5207bb054ebff224
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 05:13:19 -0000

--94eb2c087eea5207bb054ebff224
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk  wrote:

> Trying to consolidate various things into a single mail...
>
> On 05/04/2017 04:37 PM, Eric Rescorla wrote:
>
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanism=
s.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one
> of these mitigations?
>
>
>
> That seems like an inconsistent position to take (don't do this, but if
> you ignore me, do this in this fashion).  Advising application profiles t=
o
> consider one of those things might be better.
>

That's just incompetent writing by me, I guess.

For 2, I meant "If there is an application profile allowing 0-RTT, but it
doesn't say you don't
need mitigations, then you MUST..."


-Ekr


>
>
>
> On 05/04/2017 04:27 PM, Kyle Nekritz wrote:
>
> 2) Preventing clients from sending 0-RTT data multiple times (on separate
> connections) using the same PSK (for forward secrecy reasons)
>
>
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior to
> receiving a NST (if they are out of cached PSKs). I=E2=80=99d expect the =
need for
> these retries to be larger with 0-RTT data, particularly when 0-RTT data =
is
> sent without even a transport roundtrip (in the case of TFO or QUIC).
> Servers are definitely not required to accept multiple 0-RTT connections
> using the same PSK, but I don=E2=80=99t think clients should be banned fr=
om
> attempting.
>
>
> Obligatory note that if clients are forbidden from reusing a single PSK
> for multiple 0-RTT, they can still use it for 1-RTT.
>
>
>
> On 05/04/2017 03:24 PM, Colm MacC=C3=A1rthaigh wrote:
>
> On Thu, May 4, 2017 at 12:12 PM, Erik Nygren  wrote=
:
>
>> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
>>
>>>
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the merits of each.
>>>
>>
>> I don't believe this is technically viable for the large-scale server
>> operators most interested in 0-RTT.
>>
>
> I think it is (and work at one of the biggest) ... but if even it weren't=
,
> that would just imply that we can't have 0-RTT at all, not that it's ok t=
o
> ship an insecure version.
>
>
> I would be okay with that being the case ... but I don't think that's
> actually the case.  Some people are going to do 0-RTT in one form or
> another, whether or not we specify it here.  I'd rather have something
> well-specified that can be used correctly in some cases and is
> unfortunately used in more cases than that, then a less-well-documented-a=
nd-analyzed
> thing used in those same questionable cases.
>
>
> On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> P.S. Care to name (another :) one security-related protocol that doesn't
> provide replay protection?
>
>
> Some of the earlier uses of Kerberos are subject to replay (hence kerbero=
s
> implementations can end up providing replay caches to try and help, which
> are not perfect and slow to boot).  More modern exchanges that use GSS
> acceptor subkeys are not subject to replay, though.
>
>
> On 05/03/2017 09:31 PM, Martin Thomson wrote:
>
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear.  Otherwise, beware.  The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactively blessed.
>
>
> You can still be in trouble if you used the early exporter, e.g., for
> token binding.  We had some discussions in the tokbind session in Chicago
> that clarified that handshake completion does not retroactively bless the
> properties you want from 0-RTT token binding.
>
>
> -Ben
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c087eea5207bb054ebff224
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk <<=
a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com=
> wrote:

 =20
   =20
 =20
  

    Trying to consolidate various things into a single mail...

    

    On 05/04/2017 04:37 PM, Eric Rescorla wrote:

    

      
In the PR I just posted, I spent most of my time describing
        the

      
mechanisms and used a SHOULD-level requirement to do one of
        the mechanisms.

      
I think there's a bunch of room to wordsmith the requirement=
.
        Perhaps we say:

      


      

      
- You can't do 0-RTT without an application profile

      
- Absent the application profile saying otherwise you
        SHOULD/MUST do one of these mitigations?

      


      

      


      

    

    

    That seems like an inconsistent position to take (don't do this, bu=
t
    if you ignore me, do this in this fashion).=C2=A0 Advising application
    profiles to consider one of those things might be better.

That's just incompetent writing by me, I guess=
.

For 2, I meant "If there is an application =
profile allowing 0-RTT, but it doesn't say you don't
need=
 mitigations, then you MUST..."


-Ekr
=C2=A0


    

    

    
On 05/04/2017 04:27=
 PM, Kyle Nekritz
      wrote:

    

    

      
2)
          Preventing clients from sending 0-RTT data multiple times (on
          separate connections) using the same PSK (for forward secrecy
          reasons)

      
=C2=A0

      
I
          think this should be allowed. Otherwise, clients will not be
          able to retry 0-RTT requests that fail due to an unknown
          network error prior to receiving a NST (if they are out of
          cached PSKs). I=E2=80=99d expect the need for these retries to be
          larger with 0-RTT data, particularly when 0-RTT data is sent
          without even a transport roundtrip (in the case of TFO or
          QUIC). Servers are definitely not required to accept multiple
          0-RTT connections using the same PSK, but I don=E2=80=99t think
          clients should be banned from attempting.
      

    

    

    Obligatory note that if clients are forbidden from reusing a single
    PSK for multiple 0-RTT, they can still use it for 1-RTT.

    

    

    

    
On 05/04/2017 03:24=
 PM, Colm
      MacC=C3=A1rthaigh wrote:

    

    
On Thu, May 4, 2017 at 12:12 PM, Erik Nygren =
<erik+ietf@nygren.org>
      wrote:

      

        

          

            
On Wed, May 3=
, 2017
                at 11:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:<=
br>
                

                  


                    
1. A SHOULD-level requirement for server-side
                      0-RTT defense, explaining

                    
both session-cache and strike register styles
                      and the merits of each.

                  

                

                


                

              
              
I don't believe this is tech=
nically viable for the
                large-scale server operators most interested in 0-RTT.
            

          

        

      

      


      

      
I think it is (and work at one of the biggest) ... but if
        even it weren't, that would just imply that we can't have 0=
-RTT
        at all, not that it's ok to ship an insecure version.

    

    

    I would be okay with that being the case ... but I don't think
    that's actually the case.=C2=A0 Some people are going to do 0-RTT i=
n one
    form or another, whether or not we specify it here.=C2=A0 I'd rathe=
r have
    something well-specified that can be used correctly in some cases
    and is unfortunately used in more cases than that, then a
    less-well-documented-and-analyzed thing used in those same
    questionable cases.

    

    

    
On 05/03/2017 09:33=
 PM, Blumenthal, Uri
      - 0553 - MITLL wrote:

    

    
P.S. Care to name (another :) one security-re=
lated
      protocol that doesn't provide replay protection?

    

    

    Some of the earlier uses of Kerberos are subject to replay (hence
    kerberos implementations can end up providing replay caches to try
    and help, which are not perfect and slow to boot).=C2=A0 More modern
    exchanges that use GSS acceptor subkeys are not subject to replay,
    though.

    

    

    
On 05/03/2017 09:31=
 PM, Martin Thomson
      wrote:

    

    

      
A clear delineation of security properties exists, if the handsh=
ake is
done, then you are in the clear.  Otherwise, beware.  The separation
of the streams doesn't help if you consider the possibility that 0-RTT
data can be retroactively blessed.

    

    

    You can still be in trouble if you used the early exporter, e.g.,
    for token binding.=C2=A0 We had some discussions in the tokbind session
    in Chicago that clarified that handshake completion does not
    retroactively bless the properties you want from 0-RTT token
    binding.

    

    

    -Ben

    

  



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c087eea5207bb054ebff224--


From nobody Thu May  4 22:15:54 2017
Return-Path: 
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 2EC211293E1 for ; Thu,  4 May 2017 22:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 rrFN0MNmGtQP for ; Thu,  4 May 2017 22:15:50 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2343E129445 for ; Thu,  4 May 2017 22:15:48 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 73C4A433421; Fri,  5 May 2017 05:15:47 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5D418433419; Fri,  5 May 2017 05:15:47 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493961347; bh=0imcR2q8QGs+LHFG/haRFfSrfQiB2wn3twTKoPEyRc4=; l=7649; h=To:References:Cc:From:Date:In-Reply-To:From; b=nbhwVUZTuIAE9zB4FqZg7THcxkej1H6tvq4vnjnRLdV8jK89vEBl1beDKMJY9VKUK NtUfumM6Mv8/JQ1FYOzQIDAqGbGDQ6nxcltkTjfmgz5LjaspsszFqW2igVXrUB/gof Fa6/18xGHrnnyR84nmJ2fI71GufSpk291aIIEQGc=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 22EB51FCB3; Fri,  5 May 2017 05:15:47 +0000 (GMT)
To: Nico Williams 
References:  <830b5237-d3d1-2f3b-3e8d-a4cc75870fd9@akamai.com> <20170505050412.GE10188@localhost>
Cc: Watson Ladd , "tls@ietf.org" 
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Fri, 5 May 2017 00:15:46 -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: <20170505050412.GE10188@localhost>
Content-Type: multipart/alternative; boundary="------------69C04C497340E72F8AE287EA"
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 05:15:52 -0000

This is a multi-part message in MIME format.
--------------69C04C497340E72F8AE287EA
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/05/2017 12:04 AM, Nico Williams wrote:
> On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote:
>> On 05/04/2017 06:35 PM, Watson Ladd wrote:
>>> If you are willing to buffer 0-RTT until completion before going to
>>> the thing that makes the response, you can handle this problem for the
>>> responsemaker. This will work for most applications I can think of,
>>> and you need to handle large, drawn out requests anyway. This sounds
>>> like it would work as a solution, but I am sure there are details I
>>> haven't discovered yet.
>> The server is allowed to buffer the 0-RTT data while processing it and
>> delay a response until the handshake is completed, yes.  (I think this
>> is the "way to force 1-RTT at the application layer" that Nico wants.) 
> I'm not up on the details of how 0-rtt works in TLS 1.3.  I don't know
> if there's a way for the server to cause a round-trip to occur, nor if
> there's a way for the client to then confirm the 0-rtt data in that
> round-trip.

The server is blindly carrying data for the application.  The
application can decide to not send any 0.5-RTT data in response to the
0-RTT data, and wait for the regular 1.5-RTT response, if it wants.

> I do think having such functionality would be very helpful for cases
> where the server runs a) without a replay cache, and b) can accept
> idempotent and non-idempotent requests.

If we presume knowledge of (b) then we are forced to consider it at the
application layer; a TLS-layer signal would be pretty awkward to manage,
and an application-layer signal (or delayed response) seems much more
reasonable.

> I think always requiring a replay cache is not likely to work out in
> practice.

I agree.  I don't think we should make a claim that 0-RTT data is
safe/non-replayable by virtue of requiring that servers implement a
replay cache; it's doing consumers a disservice if we expect that there
will be servers that don't implement the strict anti-replay measures.

>> It removes the latency benefits of 0-RTT [for that request] and might be
> Because [for that request] there are no benefits of 0-rtt.
>
>> annoying to implement with APIs that only give you a single data stream
>> (but probably not too bad), but the application layer at the server has
>> the capability to solve these idempotency/replay problems. 
>> Unfortunately, we are the TLS layer and cannot assume that we control or
>> can cooperate with the application.  Which leads right back to the
>> "application profile is required" bit, of course.
> Yes, sure, but the application profile rubber has to meet the road.
> That usually means that the devil is in the APIs.
>
> An application that wants a "dumb secure socket"... just can't have
> 0-rtt.

Yes.

> HTTP should be trivial to profile... if only GET weren't abused here and
> there.
>

You might look at
https://tools.ietf.org/html/draft-nottingham-httpbis-retry-01 , though
I'm no longer confident that's actually the Nottingham document I'm
thinking of :(

-Ben

--------------69C04C497340E72F8AE287EA
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/05/2017 12:04 AM, Nico Williams wrote:

    

      
On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote:


      

        
On 05/04/2017 06:35 PM, Watson Ladd wrote:


        

          
If you are willing to buffer 0-RTT until completion before going to
the thing that makes the response, you can handle this problem for the
responsemaker. This will work for most applications I can think of,
and you need to handle large, drawn out requests anyway. This sounds
like it would work as a solution, but I am sure there are details I
haven't discovered yet.


        

        
The server is allowed to buffer the 0-RTT data while processing it and
delay a response until the handshake is completed, yes.  (I think this
is the "way to force 1-RTT at the application layer" that Nico wants.) 


      

      
I'm not up on the details of how 0-rtt works in TLS 1.3.  I don't know
if there's a way for the server to cause a round-trip to occur, nor if
there's a way for the client to then confirm the 0-rtt data in that
round-trip.


    

    

    The server is blindly carrying data for the application.  The
    application can decide to not send any 0.5-RTT data in response to
    the 0-RTT data, and wait for the regular 1.5-RTT response, if it
    wants.

    

    

      
I do think having such functionality would be very helpful for cases
where the server runs a) without a replay cache, and b) can accept
idempotent and non-idempotent requests.


    

    

    If we presume knowledge of (b) then we are forced to consider it at
    the application layer; a TLS-layer signal would be pretty awkward to
    manage, and an application-layer signal (or delayed response) seems
    much more reasonable.

    

    

      
I think always requiring a replay cache is not likely to work out in
practice.


    

    

    I agree.  I don't think we should make a claim that 0-RTT data is
    safe/non-replayable by virtue of requiring that servers implement a
    replay cache; it's doing consumers a disservice if we expect that
    there will be servers that don't implement the strict anti-replay
    measures.

    

    

      

      

        
It removes the latency benefits of 0-RTT [for that request] and might be


      

      
Because [for that request] there are no benefits of 0-rtt.



      

        
annoying to implement with APIs that only give you a single data stream
(but probably not too bad), but the application layer at the server has
the capability to solve these idempotency/replay problems. 
Unfortunately, we are the TLS layer and cannot assume that we control or
can cooperate with the application.  Which leads right back to the
"application profile is required" bit, of course.


      

      
Yes, sure, but the application profile rubber has to meet the road.
That usually means that the devil is in the APIs.

An application that wants a "dumb secure socket"... just can't have
0-rtt.


    

    

    Yes.

    

    

      
HTTP should be trivial to profile... if only GET weren't abused here and
there.



    

    

    You might look at
    https://tools.ietf.org/html/draft-nottingham-httpbis-retry-01 ,
    though I'm no longer confident that's actually the Nottingham
    document I'm thinking of :(

    

    -Ben

  


--------------69C04C497340E72F8AE287EA--


From nobody Fri May  5 03:22:48 2017
Return-Path: 
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 4E2BE129494 for ; Fri,  5 May 2017 03:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 pus7UKC3ZQ_R for ; Fri,  5 May 2017 03:22:44 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A87B12953F for ; Fri,  5 May 2017 03:22:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1785F601DB; Fri,  5 May 2017 13:22:31 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id T2MeriN-Kgdu; Fri,  5 May 2017 13:22:30 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F236627F; Fri,  5 May 2017 13:22:29 +0300 (EEST)
Date: Fri, 5 May 2017 13:22:28 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Message-ID: <20170505102228.GA10328@LK-Perkele-V2.elisa-laajakaista.fi>
References:     <10986afe-873e-a81d-102b-86fa169b156f@akamai.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 10:22:46 -0000

On Thu, May 04, 2017 at 10:12:34PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk  wrote:
> 
> >
> > That seems like an inconsistent position to take (don't do this, but if
> > you ignore me, do this in this fashion).  Advising application profiles to
> > consider one of those things might be better.
> >
> 
> That's just incompetent writing by me, I guess.
> 
> For 2, I meant "If there is an application profile allowing 0-RTT, but it
> doesn't say you don't
> need mitigations, then you MUST..."

I think the two methods (use-once session database and strike register)
should additionally be formulated so that those have sufficient
atomicity to eliminate 0-RTT replay.

This of course impiles that the scope of 0-RTT is sufficiently small
for synchronization to propagate quickly enough (this probably limits
the scope to a datacenter, but this should not be a problem in
practice).

Then clients should also be restricted to using the same ticket just
once for 0-RTT (absent a application profile), with due atomicity.

Also, I think use of 0-RTT exporters should require atomic session
database or strike register, no matter what application profile says,
as otherwise 0-RTT exporters become insecure.


Obviously, these 0-RTT safeguards don't need to apply to 1-RTT using a
dynamic PSK. That can be reused (obiviously at cost of linkability).


Also, a trick: The first binder makes a good identifier for the
ClientHello for purposes of 0-RTT replay detection.


-Ilari


From nobody Fri May  5 04:31:58 2017
Return-Path: 
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 3005412957C for ; Fri,  5 May 2017 04:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.223
X-Spam-Level: 
X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 7fH03gOXKQNo for ; Fri,  5 May 2017 04:31:55 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E5D12946D for ; Fri,  5 May 2017 04:31:54 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 185254E338; Fri,  5 May 2017 11:31:54 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 185254E338
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 185254E338
Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B792A80685; Fri,  5 May 2017 11:31:53 +0000 (UTC)
From: Hubert Kario 
To: Yoav Nir , tls@ietf.org
Date: Fri, 05 May 2017 13:31:45 +0200
Message-ID: <3956794.ukn8WviHj0@pintsize.usersys.redhat.com>
In-Reply-To: <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com>
References:  <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2138718.eOAQWIEH9Y"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 05 May 2017 11:31:54 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 11:31:56 -0000

--nextPart2138718.eOAQWIEH9Y
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, 4 May 2017 19:59:29 CEST Yoav Nir wrote:
> > 2) In Section 6:
> >    Server implementations SHOULD support all of the following cipher
> >    suites, and client implementations SHOULD support at least one of
> >    them:
> >   =20
> >    o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> >    o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> >    o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> >    o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256


looks like an "E" is missing here


=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart2138718.eOAQWIEH9Y
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZDGKhAAoJEJKo0bgB0vX1Nn8QAIap3QlxtoP8AEM9C/7cCqM8
4Os6EGsuQAo/72hk7C6IW1MxT2hbQ1ZO3ajCoLQ5S9MRaFonadbLLMvbiwdk0gfh
FaStJSE+4yTIuxXCDIpKWQ6SKFw4bd+aFzo570Dc/ya+7+2NYGITLn3LOugU1oQY
Lz+V/tWXMaHd8ODsEOsG1lGzB/fod5ecu4CbKCawwABLmO7M1loKHfNsPiLWHL6R
voLjmqOFQBhUEcdtTsLGGgEHFIw89JPWExbiqMCs1DmTcvY/MT//GwLVef1k7vAh
KDVVsZZVq2OsIPyefqPM4ACSuZfEWilfpxeWuFGKN1S6GC8OI7gxy7rSCVY9jqAj
9hlt1RtPMU2STEDWuhn0rv6vVmO5njnqOmjIr0yXfkIQG3EF3vPxpgVwVTbhkBeP
hlvuT7RhR71i05DebGxDq4XgOCZ2A94Ua99yTzgWjnfhgap03iIPrJfIOlrVo6gM
skPnMNddphMnxuhhix2Y6xHDW7B3Hes3Cpa5R0As2oZwBp1qK2N0hiPBYvacrMXZ
UQz508TNoU8IV95VoZ5JgYk+le9udfPoeSW/kmynKFR+Nfb+pZP9WZk4LGTDA34M
7R2oIums3DrMLtGOv2SHhYfNsDXbSHFpJgKL1oWwU5K8xLVlYVwferyRIeIJvGPE
oE+PeKHmKczZwnGS/Lu/
=Z+M3
-----END PGP SIGNATURE-----

--nextPart2138718.eOAQWIEH9Y--


From nobody Fri May  5 08:31:57 2017
Return-Path: 
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 CEBBF129A96 for ; Fri,  5 May 2017 08:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.08
X-Spam-Level: 
X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 XGjHvV7JvPdX for ; Fri,  5 May 2017 08:31:54 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E65E129521 for ; Fri,  5 May 2017 08:31:53 -0700 (PDT)
Received: from [97.33.64.104] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1d6fCx-0002lA-Uq; Fri, 05 May 2017 11:31:52 -0400
Date: Fri,  5 May 2017 08:31:53 -0700
From: Bill Frantz 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
cc: Watson Ladd , tls@ietf.org
X-Priority: 3
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec799698d57e580f6917f06005743ae9f0db350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 97.33.64.104
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 15:31:56 -0000

On 5/4/17 at 4:47 PM, colm@allcosts.net (Colm MacC=C3=A1rthaigh) wrote:

>I think you're right; and we could enforce in TLS by encrypting 0-RTT unde=
r
>a key that isn't transmitted until 1-RTT.

This might be a generally useful pattern for 0-RTT use cases=20
that are trying to get large quantities of data to the server quickly.

BTW, I expect to see lots of security bugs due to 0-RTT.

But the Internet and computer operating systems are=20
insecure anyway.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345=20
Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos,=20
CA 95032


From nobody Fri May  5 09:28:06 2017
Return-Path: 
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 A842E129AB5 for ; Fri,  5 May 2017 09:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 tasLX1qAuoVD for ; Fri,  5 May 2017 09:28:04 -0700 (PDT)
Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D291129AB3 for ; Fri,  5 May 2017 09:28:04 -0700 (PDT)
Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id A22674800081E; Fri,  5 May 2017 09:28:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zSv2yGFi44Zh3a mGd0GjOGmGgmI=; b=az3Rh49/IbOW9S1PNNS0G6zWvVlfV1Rgrs3i8V1JErObQb SBzlNJMwMQuEaEMpc9Qug73Pp6a1I92oaimWfJHfEGHs528GnI2MZcxCiquy4lKe 4o2bwMkZ5EMOegPBnwvqtHRgeTn2jywGGzDH07p13hg7xCTUkWPLSZCULfH2E=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 4805348000106; Fri,  5 May 2017 09:28:03 -0700 (PDT)
Date: Fri, 5 May 2017 11:28:00 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: Watson Ladd , "tls@ietf.org" 
Message-ID: <20170505162800.GF10188@localhost>
References:  <20170504235812.GA10188@localhost>  <20170505033652.GB10188@localhost> <3fc4304b-0540-ad4d-6220-15d33cf06645@akamai.com> <20170505045254.GC10188@localhost> <24861825-7e2d-8a97-0b0a-67f176b92d6d@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24861825-7e2d-8a97-0b0a-67f176b92d6d@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Idempotency and the application developer
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 16:28:05 -0000

On Fri, May 05, 2017 at 12:04:14AM -0500, Benjamin Kaduk wrote:
> >> I'm very skeptical that this position would survive into real-world
> >> deployments.
> > Which part?
> 
> No matter what we way here, there will be reverse proxies deployed on
> the internet in the next 5 years that blindly accept 0-RTT knowing
> nothing about the application and not letting the server know that 0-RTT
> was used.

Really?  They already exist and are already deployed?

If so... I... have nothing good to say about that right now, so I'd
better say no more.

Nico
-- 


From nobody Fri May  5 09:28:20 2017
Return-Path: 
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 A077D129AEB for ; Fri,  5 May 2017 09:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 S8iGS3CiLmeB for ; Fri,  5 May 2017 09:28:09 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E9D129AB3 for ; Fri,  5 May 2017 09:28:09 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l135so5370456ywb.2 for ; Fri, 05 May 2017 09:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sRhsKLf3nrmJKCroyaAqoggLJVO5ROckD1aK6bWjEZ4=; b=dbqXFvW2O+AKXLmAsncvvdm/h5HHY2+fGA5PApyXtzEVQeK6sXbXwBLJiShnNNlHOc ZtBbD3AdGTCPUbxfDMrIF0r7kD1hbKtlvsKsTPhzSERfhbmMaDrY7PBFsWomwLB3AEP1 5JKxaURPE+SBrEfD2Tx74soOLrrMQrMrA+sva15R6/yyChexQFxc1oQI5/FBuTOAj97+ NP+uPFSgHOK5lTO6odGWP+sDNYCbQ1vKpdoXnvir67vjvoq3fgrE1ITCLWRgRJZ7QfvZ Xn2GLQ1qqENOVcxMH1FwkSYo+BU5tZ5l++5iU3b3Jv0GmS8vUsnOZI4FgpzLhxtDsLBc MHeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sRhsKLf3nrmJKCroyaAqoggLJVO5ROckD1aK6bWjEZ4=; b=NcRZJlNkK1gP3UQfZmzQ37o+FDOe2cj6MZr3ooFkn0xhDo5EIaZ2sJ/fA/15eOXV98 hdCxMqNJ/ougDzXD7+Nu624SEiyqfEbD1DVXgJ7daiuyYDD5W8nWiNDT3/AFP0mBYVmr EN+VY4Hs10CbzjzhV+TTwYgae0FIg7FjkAJscxe0ic7ZKRFox4ChjPykyrSlpad5PYAk fIv6mHx/FHEPzdqLGnOTARo4kBRpfZEaTCmg+9WK4s0FqCoI4j/ELVEg2l95+2kV7o73 HohCTVERiLbg9LVEmBcdojDOmOGnF5/ax8vQZtL3jtHktikPnp2+IRjwF6pSTEtz75gO 2MYg==
X-Gm-Message-State: AN3rC/4xDesr++BjOvTgpYXizjROGR433z95etE+x4cQJAIIvhocdr3E RvP0qwxYCpIKkWHXHiyqECf5UrDPWA5/
X-Received: by 10.13.238.65 with SMTP id x62mr38734225ywe.122.1494001688361; Fri, 05 May 2017 09:28:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Fri, 5 May 2017 09:28:07 -0700 (PDT)
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Fri, 5 May 2017 09:28:07 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c034d8cedf7f3054ec95f05
Archived-At: 
Subject: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 16:28:13 -0000

--94eb2c034d8cedf7f3054ec95f05
Content-Type: text/plain; charset=UTF-8

I wanted to start a separate thread on this, just to make some small
aspects of replay mitigating clear, because I'd like to make a case for TLS
providing a single-stream, which is what people seem to be doing anyway.

Let's look at the DKG attack. There are two forms of the attack, one is as
follows:

"Client sends a request with a 0-RTT section. The attacker lets the server
receive it, but suppresses the server responses, so the client downgrades
and retries as a 1-RTT request over a new connection. Repeating the
request".

In this case, server-side signaling such as the X-header trick doesn't work
at all. But thankfully this attack is equivalent to an ordinary socket
interference attack. E.g. if an attacker today suppressed a server response
to a HTTP request, then the client will do its retry logic. It's the same,
and I think everything is compatible with today's behavior.

Next is the more interesting form of the attack:

"Client sends a request with a 0-RTT section. For some reason the server
can't reach the strike register or single use cache, and falls back to
1-RTT. Server accepts the request over 1-RTT.  Then a short time later, the
attacker replays the original 0-RTT section."

In this case, server side signaling to the application (such as the neat X-
header trick) also doesn't work, and is not backwards compatible or secure
by default. It doesn't work because the server application can't be made
idempotent from "outside" the application, so any signaling is
insufficient, and is equivalent to the Exactly-Once message delivery
problem in distributed systems. Since a request might be retried as in case
1, it needs an application-level idempotency key, or a delay-and-retry
strategy (but replay will break this). There's some detail on all this in
the review. End result is that a server-side application that was never
designed to reach duplicates may suddenly be getting exactly one duplicate
(that's all the attack allows, if servers reject duplicate 0-RTT).

What is actually needed here, I think, is client-side signaling. Careful
clients need to be made aware of the original 0-RTT failure.

So for example, an SDK that writes to an eventually consistent data store
may treat any 0-RTT failure as a hard failure, and *not* proceed to sending
the request over 1-RTT. Instead it might wait its retry period, do a poll,
and only then retry the request. If the TLS implementation signals the
original  0-RTT failure to the client, as if it were a connection error,
everything is backwards compatible again. Well mostly; to be properly
defensive, the client's retry time or polling interval needs to be greater
than the potential replay window, because only then can it reason about
whether the original request succeeded or not. If there is a strict maximum
replay window, then this behavior is enforceable in a TLS implementation:
by delaying the original failure notification to the client application by
that amount.

Of course browsers won't do this, and that's ok. Browsers have decided that
aggressive retries is best for their application space. But careful clients
/need/ this; and it's not just about backwards compatibility. It is a
fundamental first-principles requirement for something that uses an
eventually consistent data store. We can say don't use 0-RTT, but that's
not practical, for reasons also in the review.

So if we want to fully mitigate DKG attacks, I think it is useful to hard
cap the replay, say that it MUST be at most 10 seconds. And then worst
case, a client that needs to be careful can wait 10 seconds. Note that the
TLS implementation can do this on the client's behalf, by inserting a
delay. Of course that means that for these kinds of applications, this
means that 0-RTT delivers speed most of the time, but may occasionally slow
things down by 10 seconds. I think that's an ok trade-off to make for
backwards compatibility.

But it also has implications for middle-boxes: a TLS reverse proxy needs to
either not use 0-RTT on the "backend" side, or it needs to use it in very
careful way; accepting 0-RTT from the original client, only if the backend
also accepts a 0-RTT section from the proxy. This is to avoid the case
where the client can't reason about the potential for a replay between the
proxy and the backend. It's doable, but gnarly, and slows 0-RTT acceptance
down to the round trip between the client and the backend, via the proxy.

That's one reason why the review suggests something else too:  just lock
careful applications out, but in a mechanistic way rather than a "good
intentions" way, by having TLS implementations *intentionally* duplicate
0-RTT sections.

O.k. so all of that the above might be a bit hairy: but I want to take away
from it at this stage is that splitting the early_data and application_data
at application level isn't particularly helpful; the server-side can't
really use this information anyway, because of the Exactly-Once problem.
Client side signaling does help though, and a simple safe-by-default
mechanism there is to behave as if the connection has failed, but after
writing the first section of data. E.g. in s2n this would be ...

conn = s2n_connect(); // Client makes a connection
r = s2n_write(conn, "GET / HTTP/1.1 ... "); // Client writes some data, we
stuff it in the 0-RTT and send it. This write succeeds. From the client's
perspective, it may or may not have been received; that's normal.

/* At this point the 0-RTT data is rejected by the server, and so it might
be replayable  ... iff the server side strike-register or
   cache had a problem.

   A pedantically correct TLS library might then pause here for 10 seconds,
or if it's non-blocking, then set a timer so that nothing can happen on
conn for the next 10 seconds. Browsers could turn this behavior off, since
they retry aggressively anyway. But it's a secure default that is backwards
compatible.
*/

r = s2n_read()/s2n_write()/s2n_shutdown();  // At this point, s2n returns
failure. It's as if the connection failed. The client can implement its
retry strategy, if any, safely; the request won't be replayed at this
point.

r = s2n_connect(); // Client makes a new connection for a retry.


A slightly higher level API is probably more realistic, because there's a
potential to optimize for connection re-use. There's really no need to tear
down the whole connection and start-over. It's safe to proceed to 1-RTT if
the delay has expired. A higher level API would fix that, but this is just
the "safe by default" API I'm outlining.  Again, all I want to take away is
that all of this is doable safely with a single stream.


-- 
Colm

--94eb2c034d8cedf7f3054ec95f05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



I wanted to start a separate thread on=
 this, just to make some small aspects of replay mitigating clear, because =
I'd like to make a case for TLS providing a single-stream, which is wha=
t people seem to be doing anyway.=C2=A0

Let's =
look at the DKG attack. There are two forms of the attack, one is as follow=
s:

"Client sends a request with a 0-RTT secti=
on. The attacker lets the server receive it, but suppresses the server resp=
onses, so the client downgrades and retries as a 1-RTT request over a new c=
onnection. Repeating the request".=C2=A0

In t=
his case, server-side signaling such as the X-header trick doesn't work=
 at all. But thankfully this attack is equivalent to an ordinary socket int=
erference attack. E.g. if an attacker today suppressed a server response to=
 a HTTP request, then the client will do its retry logic. It's the same=
, and I think everything is compatible with today's behavior.

Next is the more interesting form of the attack:
=

"Client sends a request with a 0-RTT section. For =
some reason the server can't reach the strike register or single use ca=
che, and falls back to 1-RTT. Server accepts the request over 1-RTT.=C2=A0 =
Then a short time later, the attacker replays the original 0-RTT section.&q=
uot;

In this case, server side signaling to the ap=
plication (such as the neat X- header trick) also doesn't work, and is =
not backwards compatible or secure by default. It doesn't work because =
the server application can't be made idempotent from "outside"=
; the application, so any signaling is insufficient, and is equivalent to t=
he Exactly-Once message delivery problem in distributed systems. Since a re=
quest might be retried as in case 1, it needs an application-level idempote=
ncy key, or a delay-and-retry strategy (but replay will break this). There&=
#39;s some detail on all this in the review. End result is that a server-si=
de application that was never designed to reach duplicates may suddenly be =
getting exactly one duplicate (that's all the attack allows, if servers=
 reject duplicate 0-RTT).=C2=A0

What is actually n=
eeded here, I think, is client-side signaling. Careful clients need to be m=
ade aware of the original 0-RTT failure.=C2=A0

So =
for example, an SDK that writes to an eventually consistent data store may =
treat any 0-RTT failure as a hard failure, and *not* proceed to sending the=
 request over 1-RTT. Instead it might wait its retry period, do a poll, and=
 only then retry the request. If the TLS implementation signals the origina=
l =C2=A00-RTT failure to the client, as if it were a connection error, ever=
ything is backwards compatible again. Well mostly; to be properly defensive=
, the client's retry time or polling interval needs to be greater than =
the potential replay window, because only then can it reason about whether =
the original request succeeded or not. If there is a strict maximum replay =
window, then this behavior is enforceable in a TLS implementation: by delay=
ing the original failure notification to the client application by that amo=
unt.=C2=A0

Of course browsers won't do t=
his, and that's ok. Browsers have decided that aggressive retries is be=
st for their application space. But careful clients /need/ this; and it'=
;s not just about backwards compatibility. It is a fundamental first-princi=
ples requirement for something that uses an eventually consistent data stor=
e. We can say don't use 0-RTT, but that's not practical, for reason=
s also in the review.

So if we want to fully mitig=
ate DKG attacks, I think it is useful to hard cap the replay, say that it M=
UST be at most 10 seconds. And then worst case, a client that needs to be c=
areful can wait 10 seconds. Note that the TLS implementation can do this on=
 the client's behalf, by inserting a delay. Of course that means that f=
or these kinds of applications, this means that 0-RTT delivers speed most o=
f the time, but may occasionally slow things down by 10 seconds. I think th=
at's an ok trade-off to make for backwards compatibility.
But it also has implications for middle-boxes: a TLS reverse pr=
oxy needs to either not use 0-RTT on the "backend" side, or it ne=
eds to use it in very careful way; accepting 0-RTT from the original client=
, only if the backend also accepts a 0-RTT section from the proxy. This is =
to avoid the case where the client can't reason about the potential for=
 a replay between the proxy and the backend. It's doable, but gnarly, a=
nd slows 0-RTT acceptance down to the round trip between the client and the=
 backend, via the proxy.=C2=A0

That's one reas=
on why the review suggests something else too: =C2=A0just lock careful appl=
ications out, but in a mechanistic way rather than a "good intentions&=
quot; way, by having TLS implementations *intentionally* duplicate 0-RTT se=
ctions.=C2=A0

O.k. so all of that the above might =
be a bit hairy: but I want to take away from it at this stage is that split=
ting the early_data and application_data at application level isn't par=
ticularly helpful; the server-side can't really use this information an=
yway, because of the Exactly-Once problem. Client side signaling does help =
though, and a simple safe-by-default mechanism there is to behave as if the=
 connection has failed, but after writing the first section of data. E.g. i=
n s2n this would be ...

conn =3D s2n_connect(); //=
 Client makes a connection
r =3D s2n_write(conn, "GET / HTTP=
/1.1 ... "); // Client writes some data, we stuff it in the 0-RTT and =
send it. This write succeeds. From the client's perspective, it may or =
may not have been received; that's normal.=C2=A0

/* At this point the 0-RTT data is rejected by the server, and so it mig=
ht be replayable =C2=A0... iff the server side strike-register or=C2=A0
=C2=A0 =C2=A0cache had a problem.=C2=A0
=C2=A0=C2=A0
=

=C2=A0 =C2=A0A pedantically correct TLS library might then pause here =
for 10 seconds, or if it's non-blocking, then set a timer so that nothi=
ng can happen on conn for the next 10 seconds. Browsers could turn this beh=
avior off, since they retry aggressively anyway. But it's a secure defa=
ult that is backwards compatible.
*/

r =
=3D s2n_read()/s2n_write()/s2n_shutdown(); =C2=A0// At this point, s2n retu=
rns failure. It's as if the connection failed. The client can implement=
 its retry strategy, if any, safely; the request won't be replayed at t=
his point.=C2=A0

r =3D s2n_connect(); // Client ma=
kes a new connection for a retry.=C2=A0


=

A slightly higher level API is probably more realistic, because there&=
#39;s a potential to optimize for connection re-use. There's really no =
need to tear down the whole connection and start-over. It's safe to pro=
ceed to 1-RTT if the delay has expired. A higher level API would fix that, =
but this is just the "safe by default" API I'm outlining.=C2=
=A0 Again, all I want to take away is that all of this is doable safely wit=
h a single stream.=C2=A0


-- 
Colm




--94eb2c034d8cedf7f3054ec95f05--


From nobody Fri May  5 09:45:52 2017
Return-Path: 
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 66086129ADC for ; Fri,  5 May 2017 09:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 UaWcQ5SrxxbA for ; Fri,  5 May 2017 09:45:50 -0700 (PDT)
Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7123E124281 for ; Fri,  5 May 2017 09:45:50 -0700 (PDT)
Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 1CCD648005901; Fri,  5 May 2017 09:45:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=NFLoBRZEoBlEtU VrzVNqQTTRgfA=; b=AGcGw4FR7N9NPNelmcykkockiCB8k/9WBRQEifSwwV/A+f tFz/GQQ7Z4Mm0ZKYILkB8AMNSVI9S1GJT4mrf8PYR3DqKojh01vYNVcAEpl8iLLn QsVOlTINuX9rlqVl49s/JCNCnMR0vqTI1pS3pxSzQ3aQy9JV5wlcBLA6xaz8Q=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id C67FB4800103C; Fri,  5 May 2017 09:45:49 -0700 (PDT)
Date: Fri, 5 May 2017 11:45:47 -0500
From: Nico Williams 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" 
Message-ID: <20170505164546.GG10188@localhost>
References:     <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 16:45:51 -0000

On Fri, May 05, 2017 at 12:07:09AM -0500, Benjamin Kaduk wrote:
> On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> > P.S. Care to name (another :) one security-related protocol that
> > doesn't provide replay protection?
> 
> Some of the earlier uses of Kerberos are subject to replay (hence
> kerberos implementations can end up providing replay caches to try and
> help, which are not perfect and slow to boot).  More modern exchanges
> that use GSS acceptor subkeys are not subject to replay, though.

We might be getting far afield now, but if you're not using "mutual
auth" then GSS/Kerberos will look a lot like TLS 1.3 0-rtt.  GSS apps
that want that need to be careful, just as TLS 1.3 0-rtt apps.

Also, even for the 1-rtt case, GSS/Kerberos supports early (0-rtt) data.

Nico
-- 


From nobody Fri May  5 23:52:08 2017
Return-Path: 
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 1622F126579 for ; Fri,  5 May 2017 23:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Diz51z0kfIsx for ; Fri,  5 May 2017 23:52:05 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36767126FB3 for ; Fri,  5 May 2017 23:52:05 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id 142so21928174wma.1 for ; Fri, 05 May 2017 23:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9XnoF0WMvixQJN6bY4+IOlVn6FWaVtXkrGixKoagnR4=; b=gKoOHlcnQek4J6kOLJvhbY5AhQd5Dtwh9yoEjKMJ6t52Vf5bHmZb3dLsnmDIyj1aiC vOyRjZ8jWh9mC3LgenACu6AVHZvGn2oNH9XVnHGnIkOC7d9hb+bNULiZp2L+LfPUCU4X RMlOKq4dW2APth7LdsCOQReAGPSa7QfUBZ4gBnC+eBR1CGTACaYGmTrRhBKKmS39b5Kg 2v1if9+zhyQB15rv44w9Cx+8uu2EU8DfDzOC1FCqXK4P2wrjT1CmgISbmsNcX9TGeKro 7h/rqJkA7THghgaYGZYekMaihwpQezekoAH+hw8ub+5vKjoHvhHT7HYDU2IldcNKrMZu 2ygw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9XnoF0WMvixQJN6bY4+IOlVn6FWaVtXkrGixKoagnR4=; b=nBTRwIVYBUOzraZR1ptpVFMyAxJJejdJjnMP45MEDL5J9te1TKr/yuTGoiRkbFy+Ie OUTv9SmYg2i+DQ4EuDTjv3WWIm8ApInVvimUOyaYQN2l8a4bk04O28ycwsnmUHvK7ZMr Kd79CFbRaM8xkz7ObruX9vxhxx6X3rSYT266B9tJPDP3fFS6YdBY18FJ4xn5Li6TZgRs 1x8zMPBxLc/iWCUNLzgGMV2P+ChQ39lqh8qrY5HadAxsIjkoH5IKN9bbIlVjVgZIkD0b bx7luTvUwSiWPQQWHxscNe5jb05RqBDHlGR8+yl1/U6XDeLo8MTEw+NKeFVgzTU+07lV ibjA==
X-Gm-Message-State: AN3rC/59j4Dvfyi8XoK7gROGaTKzcvU70ldrIM9lcykX8b8ztjoGobvQ Udm2qH5fdwPt4Q==
X-Received: by 10.80.137.138 with SMTP id g10mr4158249edg.94.1494053523807; Fri, 05 May 2017 23:52:03 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p24sm2709476eda.67.2017.05.05.23.52.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 23:52:02 -0700 (PDT)
From: Yoav Nir 
Message-Id: <762477C8-6BC5-48E7-82CD-5D71FDD8E70C@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_99A00CEE-923D-4F51-8731-22B54D03CD7E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 6 May 2017 09:51:59 +0300
In-Reply-To: <3956794.ukn8WviHj0@pintsize.usersys.redhat.com>
Cc: tls@ietf.org
To: Hubert Kario 
References:  <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com> <3956794.ukn8WviHj0@pintsize.usersys.redhat.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 06:52:07 -0000

--Apple-Mail=_99A00CEE-923D-4F51-8731-22B54D03CD7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks!  That would have been an embarrassing erratum.


> On 5 May 2017, at 14:31, Hubert Kario  wrote:
>=20
> On Thursday, 4 May 2017 19:59:29 CEST Yoav Nir wrote:
>>> 2) In Section 6:
>>>   Server implementations SHOULD support all of the following cipher
>>>   suites, and client implementations SHOULD support at least one of
>>>   them:
>>>=20
>>>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>>   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>=20
>=20
> looks like an "E" is missing here
>=20
>=20
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech =
Republic


--Apple-Mail=_99A00CEE-923D-4F51-8731-22B54D03CD7E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZDXKQAAoJELhJCxUKWMyZFzQIAIfA0BYAhttSpN+Z0vOHBICb
MELPCo9yjWM3EcUmmBwD9JcZUgR1E70knPAn4eJQYHiqlhfBTr50X7n93sYYTVcB
/Kk0hF39bB9afbYUrJ8kEodJ1aEi0roXZAanRXV4fqtduSmlDOdzqbFKfV9+iN9A
tXKBmgsfWKkFIjKLSMePBmaRqvoAmleoM72zuAVoSaTJT3vUXzc7Y7olQhbGAgit
C32FX+VqH3kfcQ4OpgNgXNevc7louYdpYWsLb9ijtu3qujJuWwyo96Poibp13tK4
PmJy+99EZb8G9dVcAM4oyf0Hb5wd7NQ/KZnBy6ODoxfBcnMVEfNDDbQHX45Inf0=
=q+dp
-----END PGP SIGNATURE-----

--Apple-Mail=_99A00CEE-923D-4F51-8731-22B54D03CD7E--


From nobody Fri May  5 23:52:47 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01192120724; Fri,  5 May 2017 23:52:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149405355995.23176.15102157722261803190@ietfa.amsl.com>
Date: Fri, 05 May 2017 23:52:39 -0700
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-17.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 06 May 2017 06:52:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Authors         : Yoav Nir
                          Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-rfc4492bis-17.txt
	Pages           : 32
	Date            : 2017-05-05

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as authentication mechanisms.

   This document obsoletes and replaces RFC 4492.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17
https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc4492bis-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri May  5 23:53:56 2017
Return-Path: 
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 DA0FC1292AE for ; Fri,  5 May 2017 23:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TVScQcYDf3sT for ; Fri,  5 May 2017 23:53:52 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B85128C84 for ; Fri,  5 May 2017 23:53:51 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id u65so39622506wmu.1 for ; Fri, 05 May 2017 23:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q77Qz5ui5VtU1azslIEC4gDYv1fEccomfJirU7Iad1c=; b=sQJSIx8EbYd/v6XmNqc43F2cl/BgUWv+mjds9foX9iXuphNUMDPebQlIlUBVuXorGD B2OwuX7jWrYm1S1RBmguDWSyKxcDHx/tN0eUMXZIGfKJhJd3BhgbqnoEXPjO4KR2XfVG O0aMxq/kBV6/SQkQtR7UZU646yPf4Iwp6KlQjHFCor4tm2i0WX1Gvtn+FXLbPP1qO2V/ 6H9Y0gWrNMeMKedGcuR7PWXfnUXrNLogXUg9cTj0HOLF3xm671fewGRCaGXxjDXeOfHS SkqyZnUhUxMxy6TtmDr4oGG8IaAiw2ouiKqSaggLWV/zxz96D6hUbdcOblj+qbeF49Gk tYGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q77Qz5ui5VtU1azslIEC4gDYv1fEccomfJirU7Iad1c=; b=Jp3SoyizfZlPmJ4Z7yAYJ0dDZTcsYGy3ivqydPxetE1oIkX8RJRmX68IO0+BcuejSD 7wyBMmQWxdMl5gVnhAfo6ovWYHbB/UlbGLaS1XNNE4VeH+FBja+86wijz555LjV9isWd GMNwj8U6+36z47sdT1hrsDXlfpbkCMZF7IQMBxMP4E+k++xKAFVNbRvRDgpMrN7IKKIs G13yVlJyrgIsN3qeG5s3KPSSXJc9PRz5QUiMiAouYQdFUlcJkgcdKq/0cyGHbHBxI0lH w6jzUufZedPmJ8OE/tMmA9pMk3ppisPqFS/P20LUoAVq8VL9zNJxr0NIiMmBR7O8e68W R96w==
X-Gm-Message-State: AN3rC/7nlPsRmn+yTVPREYs1VLkh4AR98d8M5TUkEO1US+tEZOIZ4zG6 vDwFiQOtC/LENA==
X-Received: by 10.80.149.81 with SMTP id v17mr35712932eda.76.1494053630046; Fri, 05 May 2017 23:53:50 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id t45sm2981296edd.47.2017.05.05.23.53.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 23:53:49 -0700 (PDT)
From: Yoav Nir 
Message-Id: <2B62B8B0-2131-4BD4-9F44-CF9CB97F1C79@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5639FB7F-6D0F-4D05-A088-6412149C0A3D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 6 May 2017 09:53:47 +0300
In-Reply-To: 
Cc: Hubert Kario , "" 
To: Kathleen Moriarty 
References:  <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> <04081892-66A1-4459-875D-0C147A5826F0@gmail.com> <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 06:53:54 -0000

--Apple-Mail=_5639FB7F-6D0F-4D05-A088-6412149C0A3D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F869F32D-0281-4FF2-BDD2-869A4CDFA563"


--Apple-Mail=_F869F32D-0281-4FF2-BDD2-869A4CDFA563
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi.

Draft-17 submitted.

Yoav

> On 4 May 2017, at 23:09, Kathleen Moriarty =
 wrote:
>=20
> Yoav,
>=20
> On Thu, May 4, 2017 at 1:59 PM, Yoav Nir > wrote:
>>=20
>> On 4 May 2017, at 16:09, Kathleen Moriarty
>>  wrote:
>>=20
>> I haven't approved it yet as I noticed there was no response (that I =
saw) to
>> Alexey's comment and no change in the draft as a result of his =
comments.
>>=20
>>=20
>>=20
>> You mean these comments?
>> https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0
>>=20
>> I=E2=80=99ll quote them here:
>>=20
>> 0) There is some general awkwardness in text talking about allowed =
points
>> formats, considering that only uncompressed form is now allowed. I =
don't
>> have recommendations about improving text, other than the following:
>>=20
>> If no future formats are expected, it feels almost better to =
recommend
>> against inclusion of the Point formats extension, as lack of it means
>> uncompressed format anyway.
>>=20
>> So this was addressed in draft -16:
>>=20
>> OLD:
>>=20
>>      Implementations of this document MUST support the
>>   uncompressed format for all of their supported curves, and MUST NOT
>>   support other formats for curves defined in this specification.  =
For
>>   backwards compatibility purposes, the point format list extension
>>   MUST still be included, and contain exactly one value: the
>>   uncompressed point format (0).
>>=20
>>=20
>> NEW:
>>=20
>>      Implementations of this document MUST support the
>>   uncompressed format for all of their supported curves, and MUST NOT
>>   support other formats for curves defined in this specification.  =
For
>>   backwards compatibility purposes, the point format list extension =
MAY
>>   still be included, and contain exactly one value: the uncompressed
>>   point format (0).  RFC 4492 specified that if this extension is
>>   missing, it means that only the uncompressed point format is
>>   supported, so interoperability with implementations that support =
the
>>   uncompressed format should work with or without the extension.
>>=20
>>=20
>>=20
>> 1) In Section 2.3, last paragraph: Does this paragraph apply only to =
2.3
>> or does it also apply to 2.1 and 2.2? If the latter, then it needs to =
be
>> moved to section 2.
>>=20
>>=20
>> The content of the last paragraph was moved to a new section:
>>=20
>> 2.4.  Algorithms in Certificate Chains
>>=20
>>   This specification does not impose restrictions on signature =
schemes
>>   used anywhere in the certificate chain.  The previous version of =
this
>>   document required the signatures to match, but this restriction,
>>   originating in previous TLS versions is lifted here as it had been =
in
>>   RFC 5246.
>>=20
>>=20
>>=20
>> 2) In Section 6:
>>=20
>>   Server implementations SHOULD support all of the following cipher
>>   suites, and client implementations SHOULD support at least one of
>>   them:
>>=20
>>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>>=20
>> GCM ciphers are not listed in the table earlier in the same section. =
They
>> are defined in RFC 5289. This document doesn't have any reference to =
RFC
>> 5289 and GCM ciphers are not discussed anywhere else in the document.
>>=20
>>=20
>> Seems like I missed this one.
>=20
> Thanks, let me know when the update is ready.
>=20
>>=20
>> Yoav
>>=20
>>=20
>=20
>=20
>=20
> --
>=20
> Best regards,
> Kathleen


--Apple-Mail=_F869F32D-0281-4FF2-BDD2-869A4CDFA563
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi.

Draft-17 submitted.

Yoav

On =
4 May 2017, at 23:09, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Yoav,
On Thu, May 4, 2017 at 1:59 PM, Yoav Nir =
<ynir.ietf@gmail.com> wrote:

On 4 May =
2017, at 16:09, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote:

I haven't approved it yet as I noticed there =
was no response (that I saw) to
Alexey's comment and no =
change in the draft as a result of his comments.



You mean these comments?
https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-V=
jxXRg0

I=E2=80=99ll quote them here:

0) There is some general awkwardness in text =
talking about allowed points
formats, considering that =
only uncompressed form is now allowed. I don't
have =
recommendations about improving text, other than the following:

If no future formats are expected, it feels =
almost better to recommend
against inclusion of the Point =
formats extension, as lack of it means
uncompressed format =
anyway.

So this was addressed in draft =
-16:

OLD:

     Implementations of this =
document MUST support the
  uncompressed format =
for all of their supported curves, and MUST NOT
  support other formats for curves defined in this =
specification.  For
  backwards =
compatibility purposes, the point format list extension
  MUST still be included, and contain exactly one =
value: the
  uncompressed point format (0).


NEW:

     Implementations of this =
document MUST support the
  uncompressed format =
for all of their supported curves, and MUST NOT
  support other formats for curves defined in this =
specification.  For
  backwards =
compatibility purposes, the point format list extension MAY
  still be included, and contain exactly one value: =
the uncompressed
  point format (0).  RFC =
4492 specified that if this extension is
  missing, it means that only the uncompressed =
point format is
  supported, so interoperability =
with implementations that support the
  uncompressed format should work with or without =
the extension.



1) In Section 2.3, last paragraph: Does this paragraph apply =
only to 2.3
or does it also apply to 2.1 and 2.2? If the =
latter, then it needs to be
moved to section 2.


The content of the last =
paragraph was moved to a new section:

2.4. =
 Algorithms in Certificate Chains

  This specification does not impose restrictions =
on signature schemes
  used anywhere in the =
certificate chain.  The previous version of this
  document required the signatures to match, but =
this restriction,
  originating in previous TLS =
versions is lifted here as it had been in
  RFC =
5246.



2) In =
Section 6:

  Server =
implementations SHOULD support all of the following cipher
  suites, and client implementations SHOULD support =
at least one of
  them:

  o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  o =
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  o =
 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

GCM ciphers are not listed in the table earlier in the same =
section. They
are defined in RFC 5289. This document =
doesn't have any reference to RFC
5289 and GCM ciphers are =
not discussed anywhere else in the document.


Seems like I missed this one.

Thanks, let me know when the update is =
ready.


Yoav



-- 
Best regards,
Kathleen

=

--Apple-Mail=_F869F32D-0281-4FF2-BDD2-869A4CDFA563--

--Apple-Mail=_5639FB7F-6D0F-4D05-A088-6412149C0A3D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZDXL7AAoJELhJCxUKWMyZxCQH/jMvnmMCgXAMkXK/l6QNGDP5
KoKh7eiXBQNHZZG9xpuY4xGf4SPLXBzF/+67vqNzHpbb1cRMZpa0pk5KBO1BsEjP
62hblIDzH9XknJo4aRjIC1iFhDVv6tXsnCH2s3FyCc0utaVZQfpIjY/6zFzd5Xqa
E92EBXTfT0/NSG74ciNnVmjSncmzcKPGDdgroEdX9i3bO55l03DS1oBbIF0LsH/T
qJeJuXB03JMVhtIK9BKWUAUiFNUCOiRVYTpG2iTTqAM2/W+ljMchIpBaUduANBtB
Zer75SDINn3s519+avvyTQw1xJ+WHLTcMAOPubBWVtX+rCw4DuZnGDNUZqXS3s8=
=BY+Z
-----END PGP SIGNATURE-----

--Apple-Mail=_5639FB7F-6D0F-4D05-A088-6412149C0A3D--


From nobody Sat May  6 02:58:41 2017
Return-Path: 
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 8781D12751F for ; Sat,  6 May 2017 02:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 nUqueLzeIOfb for ; Sat,  6 May 2017 02:58:38 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 90A14126C23 for ; Sat,  6 May 2017 02:58:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id B962C213DA; Sat,  6 May 2017 12:58:35 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id vt5vdaP7rrmX; Sat,  6 May 2017 12:58:35 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7AF0821C; Sat,  6 May 2017 12:58:35 +0300 (EEST)
Date: Sat, 6 May 2017 12:58:35 +0300
From: Ilari Liusvaara 
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= 
Cc: "tls@ietf.org" 
Message-ID: <20170506095834.GA4355@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 09:58:40 -0000

On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
> I wanted to start a separate thread on this, just to make some small
> aspects of replay mitigating clear, because I'd like to make a case for TLS
> providing a single-stream, which is what people seem to be doing anyway.



Couple points:

- AFAIK, the 10 second or so figure in existing spec is a slop margin,
  which means the replay window would be 20 seconds, not 10.

- The size of the window depends on clock error margin and transport
  delay margin. At 1s/day clock error margin, you need 14 second
  window just from clock error.

- It is not just low-power devices with really bad clocks. I have seen
  20s per day(!) clock drift on high-power device that doesn't sleep.

- So basically, the size of window is tradeoff with number of devices.

- That automatic wait on 0-RTT failure seems just the kind of feature
  that gets disabled. Furthermore, 10 second idle on connection is
  going to trigger quite a bit of connection timeouts.

- There seems to be no consideration how this interacts with 0-RTT
  exporters (probably applications that accept 0-RTT will then use
  0-RTT exporters for the entiere connection, and those exporters have
  seriously weaker properties).


-Ilari


From nobody Sat May  6 05:22:37 2017
Return-Path: 
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 597EC127419 for ; Sat,  6 May 2017 05:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 v75j1hU2FRMi for ; Sat,  6 May 2017 05:22:33 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5FF124BFA for ; Sat,  6 May 2017 05:22:33 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v46CGrln012792; Sat, 6 May 2017 13:22:30 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=UVEfhmxfdT/COhcVlex89yY98+ZVpvo6xbALIqFP3K4=; b=WlyhnUeHaDYVOlOO5J8USlFtjFjx13VOGDg75NM9Ua5E7e6rMlLpnXGs4Ptr5hs7RZbJ kOKDESDJbjXgwSBt+edZB03OH8gRf6+UwRGNobIGEpfFptnkyKR8sETif9L5MJKSOGZ8 wOfYkQ6L7y+mXqZaBdOcLXVGsLdrrefL5HyLHp6GVM665KkW24qpAQkbZo4x7MlBYGGU +0g4meEkUFwDlbx1FJHNBMxLfUBlWhNrh89EniV7HeJzx9CkOO4G2xuXhyDnr59ZSRaD A7E6wYVwtqzQhdQxsZGmBpwdpmV3zT812xjC287jt2EyoNLPUAe85oGpETOkXGapgy88 JA== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2a96w7hevg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 06 May 2017 13:22:30 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v46CG3A2002621; Sat, 6 May 2017 08:22:29 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a99tvrc3t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 06 May 2017 08:22:29 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 6 May 2017 08:22:27 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 6 May 2017 08:22:27 -0400
From: "Salz, Rich" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "tls@ietf.org" 
Thread-Topic: [TLS] The case for a single stream of data
Thread-Index: AQHSxbylbnClX7eBZUm2Z/AGF1sif6HnOtSQ
Date: Sat, 6 May 2017 12:22:27 +0000
Message-ID: <879211b6670148a19b816018664324f2@usma1ex-dag1mb1.msg.corp.akamai.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.41.190]
Content-Type: multipart/alternative; boundary="_000_879211b6670148a19b816018664324f2usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-06_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705060114
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-06_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705060114
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 12:22:35 -0000

--_000_879211b6670148a19b816018664324f2usma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hhdCBhYm91dCB3aGVuICpwYXJ0KiBvZiBhIHJlcXVlc3QgaXMgaW4gdGhlIDBSVFQgcGFydCwg
YW5kIHRoZSByZXN0IG9mIGl0IGlzbuKAmXQ/ICBJIGJlbGlldmUgdGhpcyB3aWxsIGhhcHBlbiBv
ZnRlbiBmb3IgSDIgaW5pdGlhbCBzZXR1cC4gIEltYWdpbmUgdGhlIOKAnGZ1buKAnSB3aGVuIGlu
aXRpYWwgY29ubmVjdGlvbiBkYXRhLCBzdWNoIGFzIGxvZ2luIGNvb2tpZXMsIGlzIHJlcGxheWVk
IGluIG90aGVyIGNvbnRleHRzIGFuZCBldmVudHVhbGx5IGRlY3J5cHRlZD8NCg0KLS0NClNlbmlv
ciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVh
bQ0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K

--_000_879211b6670148a19b816018664324f2usma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgYWJvdXQgd2hlbiAqPGI+cGFydDwvYj4qIG9mIGEg
cmVxdWVzdCBpcyBpbiB0aGUgMFJUVCBwYXJ0LCBhbmQgdGhlIHJlc3Qgb2YgaXQgaXNu4oCZdD8m
bmJzcDsgSSBiZWxpZXZlIHRoaXMgd2lsbCBoYXBwZW4gb2Z0ZW4gZm9yIEgyIGluaXRpYWwgc2V0
dXAuJm5ic3A7IEltYWdpbmUgdGhlIOKAnGZ1buKAnSB3aGVuIGluaXRpYWwNCiBjb25uZWN0aW9u
IGRhdGEsIHN1Y2ggYXMgbG9naW4gY29va2llcywgaXMgcmVwbGF5ZWQgaW4gb3RoZXIgY29udGV4
dHMgYW5kIGV2ZW50dWFsbHkgZGVjcnlwdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLSZuYnNwOw0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5TZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NZW1iZXIsIE9wZW5T
U0wgRGV2IFRlYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_879211b6670148a19b816018664324f2usma1exdag1mb1msgcorpak_--


From nobody Sat May  6 06:44:01 2017
Return-Path: 
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 84BA1127337 for ; Sat,  6 May 2017 06:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 4W5rwiTqGWUw for ; Sat,  6 May 2017 06:43:57 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C359E127076 for ; Sat,  6 May 2017 06:43:56 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id n4so24643141qkc.0 for ; Sat, 06 May 2017 06:43:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4YXBpb7OhR7mP+9XM73ZiGpdJUWiBDmrwX5uaiVQFMw=; b=PX9nMQ4ioizsvbxhmXZgoEZbls5ZJ1wrYPa7uyUWmQAEHA6NPLM70YwW2I4aziOh1a 7yj9FTglQbDTOiJRtriDah5i+hVdTUqYRDUTOTH1lLqsaGINKAn9GmEPcbnFmtgFisM9 k4y0pYF0RYfpErzDR9+8oxJwcVyN8inzcChwI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4YXBpb7OhR7mP+9XM73ZiGpdJUWiBDmrwX5uaiVQFMw=; b=C1g9lqIz9Po34yoDav48msaIeMi3PTqCrqpm+0yWPSK1Xk+hZ0k6IWspCW9axsBS3y 6yMeO35AjsqwdhP9xybCRlwXwa1r95RmRzUyArn63P2DeEL53cG1VsYrf6AX/0omkeDQ cVRVfZp3WtiZAnMft+zJa25d5SVw31dJ8Prn+znOAJfVBODPrThjU2bfg5NFkOYp2P7V uTfTNfC632lUiQ3LJAHmw3mAK0F1N3ZXzIvH8cjLgeuYf/+6B+rseTZNfafxHVgJrE4+ g5dLhxaYWoXTPmhQl37RDsk4LZrME4SOuye8cR1eyfkXcEoDbQT8fmkA/EduEv9HnxBj WMIA==
X-Gm-Message-State: AODbwcA+eRw3N4SSjvaGgTp7L+WYdvmvveZEfM3328WTI2eQkQJIYitb v07VzzhHYiAUsoCDs28SaVGZO5poYw==
X-Received: by 10.55.142.70 with SMTP id q67mr1719765qkd.247.1494078236015; Sat, 06 May 2017 06:43:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.80.65 with HTTP; Sat, 6 May 2017 06:43:55 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:802e:2aff:fea9:7bd]
In-Reply-To: <879211b6670148a19b816018664324f2@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <879211b6670148a19b816018664324f2@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Kyle Rose 
Date: Sat, 6 May 2017 09:43:55 -0400
Message-ID: 
To: "Salz, Rich" 
Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c083c8c868314054edb329f
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 13:43:59 -0000

--94eb2c083c8c868314054edb329f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 6, 2017 at 8:22 AM, Salz, Rich  wrote:

>
> What about when **part** of a request is in the 0RTT part, and the rest
> of it isn=E2=80=99t?  I believe this will happen often for H2 initial set=
up.
> Imagine the =E2=80=9Cfun=E2=80=9D when initial connection data, such as l=
ogin cookies, is
> replayed in other contexts and eventually decrypted?
>

I asked this question a while back, and didn't get a satisfying answer: if
an on-path attacker replaces the early data with a replay from an earlier
connection, does the server eventually figure this out once the handshake
is complete, or is this mix-and-match impossible for the server to detect?
It would be nice if a security property of early data is that a replay
attack is eventually detected, because at least then you'll know you're
under attack.

Kyle

--94eb2c083c8c868314054edb329f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, May 6, 2017 at 8:22 AM, Salz, Rich <rsalz@akamai.com> wro=
te:











What about when *part* of a request is in th=
e 0RTT part, and the rest of it isn=E2=80=99t?=C2=A0 I believe this will ha=
ppen often for H2 initial setup.=C2=A0 Imagine the =E2=80=9Cfun=E2=80=9D wh=
en initial
 connection data, such as login cookies, is replayed in other contexts and =
eventually decrypted?



I asked this que=
stion a while back, and didn't get a satisfying answer: if an on-path a=
ttacker replaces the early data with a replay from an earlier connection, d=
oes the server eventually figure this out once the handshake is complete, o=
r is this mix-and-match impossible for the server to detect? It would be ni=
ce if a security property of early data is that a replay attack is eventual=
ly detected, because at least then you'll know you're under attack.=


Kyle


--94eb2c083c8c868314054edb329f--


From nobody Sat May  6 08:12:15 2017
Return-Path: 
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 B1E0A12711E for ; Sat,  6 May 2017 08:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 KXc20ZskdGV7 for ; Sat,  6 May 2017 08:12:11 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6D48C1270FC for ; Sat,  6 May 2017 08:12:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 240B7216E3; Sat,  6 May 2017 18:12:09 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id kdEcSA4zff_2; Sat,  6 May 2017 18:12:08 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B658F2313; Sat,  6 May 2017 18:12:08 +0300 (EEST)
Date: Sat, 6 May 2017 18:12:08 +0300
From: Ilari Liusvaara 
To: Kyle Rose 
Cc: "Salz, Rich" , "tls@ietf.org" 
Message-ID: <20170506151208.GA4491@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <879211b6670148a19b816018664324f2@usma1ex-dag1mb1.msg.corp.akamai.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 15:12:14 -0000

On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> On Sat, May 6, 2017 at 8:22 AM, Salz, Rich  wrote:
> 
> >
> > What about when **part** of a request is in the 0RTT part, and the rest
> > of it isn’t?  I believe this will happen often for H2 initial setup.
> > Imagine the “fun†when initial connection data, such as login cookies, is
> > replayed in other contexts and eventually decrypted?
> >
> 
> I asked this question a while back, and didn't get a satisfying answer: if
> an on-path attacker replaces the early data with a replay from an earlier
> connection, does the server eventually figure this out once the handshake
> is complete, or is this mix-and-match impossible for the server to detect?
> It would be nice if a security property of early data is that a replay
> attack is eventually detected, because at least then you'll know you're
> under attack.

Trying to replace the early data leads to fatal handshake error if the
server accepts 0-RTT (since actual deprotection failure from 0-RTT data
is fatal). If server rejects, then the substitution is silently ignored.


-Ilari


From nobody Sat May  6 16:54:47 2017
Return-Path: 
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 53DD61272E1 for ; Sat,  6 May 2017 16:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 v0VzX47UG5MX for ; Sat,  6 May 2017 16:54:43 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4EA120227 for ; Sat,  6 May 2017 16:54:42 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id n4so28354567qte.2 for ; Sat, 06 May 2017 16:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g5ymnvBtfvz3dYVkf0cGFlL3NuEwel3XAlc4Zyr4cGg=; b=edrK2v9jVWnNrepynLX1QUKDLgaFijHvtKB5qh1sl6QoTKbLIpvYuDPaGadkobVmHy Xrp1cnI7AXjoUNdzRA+Pw5fLThLx3aIRLJpblmkT4jygzu8s70VMmGBePwE8M3r+unQw UyPVattplXXhII+O6w7Nj3gcc718JWobHk7e0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g5ymnvBtfvz3dYVkf0cGFlL3NuEwel3XAlc4Zyr4cGg=; b=sKxg3XEO2MFql/V9JmXQaJS2syV1I1kKWi5r1SrD9wJoUxD1XUPYz5GEReKIP1xush Gc9gvrkJJ568NdreJAdv6BMIurqDCUrfCsLUg4V0NUBmGcDXOxEErYyzitblnWIWx/DB a0jpEOA+JUfXws06MIjyyVAwosFxbj1r0P6QtOjXQZjr4+AmxphizexXxbOtEIkOlSTz ijq4WDWTkE9Nb70ceQeQp1naL4/IQ8yyJEwfG87rODVbEoKX3pbiOdokcrGYR+AdJ7Ld yVmMA0HgBpmxdlnohwfu/R1jVgC9KEnYI7aejYzo3CMFtjmI9e4uJrADF1C8eWecLT3u LJjg==
X-Gm-Message-State: AN3rC/5SGoBD+pzAMNF3J/RSE692mGQBzBRgPm/3JLq2PUAr61L/eTC4 iOwo89LmALXD8xMYKHRPPoJI03R7xw==
X-Received: by 10.200.38.41 with SMTP id u38mr27421235qtu.165.1494114882156; Sat, 06 May 2017 16:54:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.80.65 with HTTP; Sat, 6 May 2017 16:54:41 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:802e:2aff:fea9:7bd]
In-Reply-To: <20170506151208.GA4491@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <879211b6670148a19b816018664324f2@usma1ex-dag1mb1.msg.corp.akamai.com>  <20170506151208.GA4491@LK-Perkele-V2.elisa-laajakaista.fi>
From: Kyle Rose 
Date: Sat, 6 May 2017 19:54:41 -0400
Message-ID: 
To: Ilari Liusvaara 
Cc: "Salz, Rich" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11413122ce11ba054ee3ba98
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 May 2017 23:54:45 -0000

--001a11413122ce11ba054ee3ba98
Content-Type: text/plain; charset=UTF-8

On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara 
wrote:

> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> > I asked this question a while back, and didn't get a satisfying answer:
> if
> > an on-path attacker replaces the early data with a replay from an earlier
> > connection, does the server eventually figure this out once the handshake
> > is complete, or is this mix-and-match impossible for the server to
> detect?
> > It would be nice if a security property of early data is that a replay
> > attack is eventually detected, because at least then you'll know you're
> > under attack.
>
> Trying to replace the early data leads to fatal handshake error if the
> server accepts 0-RTT (since actual deprotection failure from 0-RTT data
> is fatal). If server rejects, then the substitution is silently ignored.
>

I'm not sure this completely answers my question, so let me propose where I
think protection lies.

If the on-path attacker replaces only the early data bytes, deprotection of
early data will fail since the early traffic secret incorporates the
ClientHello in its derivation, which includes a (presumably) fresh client
random.

If the on-path attacker replaces the entire first flight (or at least
ClientHello and the early data), the early data may be accepted but the
subsequent handshake will fail because the client and server will derive
different handshake traffic keys.

If this is accurate, then replays of partial requests don't really pose a
problem (at least for HTTP) because the remainder of the request will fail
deprotection and so the request won't actually be delivered to the
application.

Kyle

--001a11413122ce11ba054ee3ba98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, May 6, 2017 at 11:12 AM, Ilari Liusvaara <ilariliusvaara@welho=
.com> wrote:
On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> I asked this question a while back, and didn't get a=
 satisfying answer: if

> an on-path attacker replaces the early data with a replay from an earl=
ier

> connection, does the server eventually figure this out once the handsh=
ake

> is complete, or is this mix-and-match impossible for the server to det=
ect?

> It would be nice if a security property of early data is that a replay=


> attack is eventually detected, because at least then you'll know y=
ou're

> under attack.



Trying to replace the early data leads to fatal handshake error if t=
he

server accepts 0-RTT (since actual deprotection failure from 0-RTT data

is fatal). If server rejects, then the substitution is silently ignored.
=


I'm not sure this completely answers my question, s=
o let me propose where I think protection lies.

If the on=
-path attacker replaces only the early data bytes, deprotection of early da=
ta will fail since the early traffic secret incorporates the ClientHello in=
 its derivation, which includes a (presumably) fresh client random.

=

If the on-path attacker replaces the entire first flight (or at =
least ClientHello and the early data), the early data may be accepted but t=
he subsequent handshake will fail because the client and server will derive=
 different handshake traffic keys.

If this is accurate, t=
hen replays of partial requests don't really pose a problem (at least f=
or HTTP) because the remainder of the request will fail deprotection and so=
 the request won't actually be delivered to the application.
=

Kyle



--001a11413122ce11ba054ee3ba98--


From nobody Sat May  6 17:35:42 2017
Return-Path: 
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 E1CC4120227 for ; Sat,  6 May 2017 17:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 m8tME7zvAqbI for ; Sat,  6 May 2017 17:35:39 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A67127333 for ; Sat,  6 May 2017 17:35:39 -0700 (PDT)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d7AAk-0006ik-7J for tls@ietf.org; Sun, 07 May 2017 02:35:38 +0200
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d7AAh-0001Xt-DZ for tls@ietf.org; Sat, 06 May 2017 20:35:37 -0400
Received: (qmail 12658 invoked from network); 7 May 2017 00:35:33 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 May 2017 00:35:33 -0000
To: Eric Rescorla , Benjamin Kaduk 
References:     <10986afe-873e-a81d-102b-86fa169b156f@akamai.com> 
Cc: "tls@ietf.org" 
From: Christian Huitema 
Message-ID: 
Date: Sat, 6 May 2017 17:35:36 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.215
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqXWJZVKkuSUxCyuHI5n8w1RcOb18WfxGyg6Om6u4YYmwvbnxy2mvS9cWzd uHW+pmU5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0mtUv6SP4 ITUfHeIhOeW8/rbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/sLmBZdPbQF3q8ksWQI6akAWLwKkKHJsy5uz AjSltoq5GyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+abPAYYtQIC6W4oZfGborEPcu6wTHpnlfUs9BUPj1rZ3
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 07 May 2017 00:35:41 -0000

On 5/4/2017 10:12 PM, Eric Rescorla wrote:
>
> Obligatory note that if clients are forbidden from reusing a single
> PSK for multiple 0-RTT, they can still use it for 1-RTT.

Yes, they can. But doing so leaks a unique identifier, which can be used
to link sessions. When I look at the privacy implications as well as the
replay attacks, there is real value in using a resume ticket only once.

-- Christian Huitema




From nobody Sat May  6 17:52:08 2017
Return-Path: 
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 0B674128C82 for ; Sat,  6 May 2017 17:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 0EFuzu2hgwLr for ; Sat,  6 May 2017 17:52:05 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7FA128D69 for ; Sat,  6 May 2017 17:52:05 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id j17so5040204ybj.0 for ; Sat, 06 May 2017 17:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fkP9CrdRkn2EJtRsgoiATvVRqOu1E6X7fiPYPX8en68=; b=caj7gEgtCGYfR2LPQQpdlzt1/tn81j5UV8G9dGSav7/AZItv7fJikVHZpbJjAJsDZ7 UQr9gJtkTBaBsl+/VrjCnxcgR9wjFIADzJi5Mynz336fz64aiLYteJbwLJYMQq0Pi9sT 37Ehs0y1YtBy7JngRBzZFghbeKhLagRgTz6Z/m0mcVE4j35Cbg1N8Ws7HE13itpWFcvh eSqZolrm4R6PqChQFC+r9MnS0QIpY8FRwkLYUqb6/4WYxOlHnFf4za8ZPoZTkSaDV9wK 3NcevS19OslwnlweunCoJ0JNQRMpVRizu7yjPEHlPOv6PUCe8s7JlQl8lQ8YcKRHUaZU AkVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fkP9CrdRkn2EJtRsgoiATvVRqOu1E6X7fiPYPX8en68=; b=Yfy0OOkVDGqllg0HKrObooJB1ijCerellF+rWX17g6HzY2LmtsDYcLjqGA2Ws+6UOp zqH2xSuSMElCmbyMBxR1WvxLe9xENUiMigu4lTlTmD9uUtMdLSR/n8Ou4AKTMZhLL61K WebmF3Izj0L4h+3A/AekD5xBiFDzfwYJLIwId6g5G5o9uDe7d/tk/oA/MqJeX2bhp+qY /d+1f99Ekgj7yJ/HKhtwyIVcwgm7ImUjb/8JnuU1Q8hecNKSvYC/jh+BD7ik3gBmP1e8 BzmYSEpY7EVcTj/iRJ3ssW7PvvmVizVg1fck5V6rXnjvcKCQ74fgpHQ9154w0XHxZ7Kt 8eUQ==
X-Gm-Message-State: AODbwcCKvA00uKQxFDxNBJl+AJgyZKqDF1vWgLTQQNAPZXWV7G20BfIo EqE4kg/IY9nS501i11lY29WVWdlMvw==
X-Received: by 10.37.161.196 with SMTP id a62mr4957389ybi.9.1494118324591; Sat, 06 May 2017 17:52:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Sat, 6 May 2017 17:51:24 -0700 (PDT)
In-Reply-To: 
References:     <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>  
From: Eric Rescorla 
Date: Sat, 6 May 2017 17:51:24 -0700
Message-ID: 
To: Christian Huitema 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045c5632fd7341054ee487ec
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 07 May 2017 00:52:07 -0000

--f403045c5632fd7341054ee487ec
Content-Type: text/plain; charset=UTF-8

On Sat, May 6, 2017 at 5:35 PM, Christian Huitema 
wrote:

>
>
> On 5/4/2017 10:12 PM, Eric Rescorla wrote:
> >
> > Obligatory note that if clients are forbidden from reusing a single
> > PSK for multiple 0-RTT, they can still use it for 1-RTT.
>
> Yes, they can. But doing so leaks a unique identifier, which can be used
> to link sessions. When I look at the privacy implications as well as the
> replay attacks, there is real value in using a resume ticket only once.
>

Agreed.  Also, I think that's Ben Kaduk you're quoting :)

-Ekr


>
> -- Christian Huitema
>
>
>
>

--f403045c5632fd7341054ee487ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, May 6, 2017 at 5:35 PM, Christian Huitema <=
;huitema@huitema.n=
et> wrote:




On 5/4/2017 10:12 PM, Eric Rescorla wrote:

>

> Obligatory note that if clients are forbidden from reusing a single
> PSK for multiple 0-RTT, they can still use it for 1-RTT.



Yes, they can. But doing so leaks a unique identifier, which can be =
used

to link sessions. When I look at the privacy implications as well as the
replay attacks, there is real value in using a resume ticket only once.
=


Agreed.=C2=A0 Also, I think that's Ben=
 Kaduk you're quoting :)

-Ekr
=C2=A0=




-- Christian Huitema











--f403045c5632fd7341054ee487ec--


From nobody Sat May  6 17:56:04 2017
Return-Path: 
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 5B42C129411 for ; Sat,  6 May 2017 17:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 nasW7P5bssqG for ; Sat,  6 May 2017 17:56:00 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AFD128C82 for ; Sat,  6 May 2017 17:56:00 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id b68so16861955ywe.3 for ; Sat, 06 May 2017 17:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jm6u9TxAQhVvFvr7ZotgMvGefGJVYmc3rMyHtzYL3aU=; b=O9dQfSmdM20aBFmaBCLEIbaVOqSoXSQxFSN9VjQ2fnis9daenkjhwEzCY5NiaV5sJ7 /Bti0Gr8xEXu7DuuoLh+mz2lDrDWRghKraplgoZBduwOVRYP48/gTnYZLM3/HKX6dSHk hvu4tGxtKD4vhgOZ87pZ3hQY/H68fUdiN9/HHgp9zbt3ZejLtLcm5ER/i4IvvBS5KOBZ vTN7tuhwOfimaRiIDMsTgtL1Wp8akjBxt099JZbbKFkU/mHcJvaqzm5wvczzuQ7K/wpw LNc8IxCk8QbVdkctAcSbZJJGn3ZLnSiUay9MYEeM/4zSvoZPo0iHTrc/NRZDLu6iBcDr xJIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jm6u9TxAQhVvFvr7ZotgMvGefGJVYmc3rMyHtzYL3aU=; b=hnCxI3HHQrl59EUVDryAL2uvo5LxE9onp9lG0Domrs18uwY9JGao/xefcojYvdFYd7 FVJZ0XHaYjnNd40Z+eTOXNukTqcUVcVG1rkRoP7awxRB+EC1uJzzyaMZLkGw0DWOd8rS Iw56V3F88OTvb84++XQ8wmIq2QBPD1cK+9ekJ0y00G/afTBALIE5kvlMuNpQcf1V3i7z KL1keOIRIsa6xorTcUpkBIjvxn9elu1Fs4lPyDHG6WOIcoqpZO+mHyInovmMt+sQQKKs YqZX5GCmrcZfP8349Zmy92uHSHARUA2wvt6Weo3tjq4W8pje+45dPyw9dIe3Ch91Q5bw HIWQ==
X-Gm-Message-State: AODbwcDaNm9IcDah0ZJrtXuV41/brdSfNAiZyG6EeKBjHGDnzoQ0EktY 3pzK4Bf6dEoSi857fk83xuah9ZyumQ==
X-Received: by 10.129.85.83 with SMTP id j80mr6944032ywb.283.1494118560007; Sat, 06 May 2017 17:56:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Sat, 6 May 2017 17:55:19 -0700 (PDT)
In-Reply-To: 
References:  <879211b6670148a19b816018664324f2@usma1ex-dag1mb1.msg.corp.akamai.com>  <20170506151208.GA4491@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Eric Rescorla 
Date: Sat, 6 May 2017 17:55:19 -0700
Message-ID: 
To: Kyle Rose 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113f3cbe05e666054ee496dd
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 07 May 2017 00:56:02 -0000

--001a113f3cbe05e666054ee496dd
Content-Type: text/plain; charset=UTF-8

On Sat, May 6, 2017 at 4:54 PM, Kyle Rose  wrote:

> On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara  > wrote:
>
>> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
>> > I asked this question a while back, and didn't get a satisfying answer:
>> if
>> > an on-path attacker replaces the early data with a replay from an
>> earlier
>> > connection, does the server eventually figure this out once the
>> handshake
>> > is complete, or is this mix-and-match impossible for the server to
>> detect?
>> > It would be nice if a security property of early data is that a replay
>> > attack is eventually detected, because at least then you'll know you're
>> > under attack.
>>
>> Trying to replace the early data leads to fatal handshake error if the
>> server accepts 0-RTT (since actual deprotection failure from 0-RTT data
>> is fatal). If server rejects, then the substitution is silently ignored.
>>
>
> I'm not sure this completely answers my question, so let me propose where
> I think protection lies.
>
> If the on-path attacker replaces only the early data bytes, deprotection
> of early data will fail since the early traffic secret incorporates the
> ClientHello in its derivation, which includes a (presumably) fresh client
> random.
>

Correct.


If the on-path attacker replaces the entire first flight (or at least
> ClientHello and the early data), the early data may be accepted but the
> subsequent handshake will fail because the client and server will derive
> different handshake traffic keys.
>

Correct.

-Ekr


>
> If this is accurate, then replays of partial requests don't really pose a
> problem (at least for HTTP) because the remainder of the request will fail
> deprotection and so the request won't actually be delivered to the
> application.
>
> Kyle
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a113f3cbe05e666054ee496dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, May 6, 2017 at 4:54 PM, Kyle Rose <krose@krose.org> wrote:
On Sat, May 6, 2017=
 at 11:12 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
=
On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> I asked this question a while back, and didn&#=
39;t get a satisfying answer: if

> an on-path attacker replaces the early data with a replay from an earl=
ier

> connection, does the server eventually figure this out once the handsh=
ake

> is complete, or is this mix-and-match impossible for the server to det=
ect?

> It would be nice if a security property of early data is that a replay=


> attack is eventually detected, because at least then you'll know y=
ou're

> under attack.



Trying to replace the early data leads to fatal handshake error if t=
he

server accepts 0-RTT (since actual deprotection failure from 0-RTT data

is fatal). If server rejects, then the substitution is silently ignored.

I'm not sure this compl=
etely answers my question, so let me propose where I think protection lies.=


If the on-path attacker replaces only the early data byt=
es, deprotection of early data will fail since the early traffic secret inc=
orporates the ClientHello in its derivation, which includes a (presumably) =
fresh client random.

Correct.


If the on-path attacker replaces the entire first flight (or at leas=
t ClientHello and the early data), the early data may be accepted but the s=
ubsequent handshake will fail because the client and server will derive dif=
ferent handshake traffic keys.

Correct.

-Ekr
=C2=A0

If this is accurate, then =
replays of partial requests don't really pose a problem (at least for H=
TTP) because the remainder of the request will fail deprotection and so the=
 request won't actually be delivered to the application.

Kyle



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113f3cbe05e666054ee496dd--


From nobody Sun May  7 02:27:23 2017
Return-Path: 
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 B650B127868 for ; Sun,  7 May 2017 02:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 P6qSm9CgbpFS for ; Sun,  7 May 2017 02:27:20 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F367120725 for ; Sun,  7 May 2017 02:27:20 -0700 (PDT)
Received: from [192.168.0.6] (cpe-67-241-70-168.twcny.res.rr.com [67.241.70.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 048527A32F1 for ; Sun,  7 May 2017 09:27:18 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Sun, 7 May 2017 05:27:17 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: <835B5EBF-9B1B-4E3D-9B1B-952944AC3C6A@dukhovni.org>
References:     <10986afe-873e-a81d-102b-86fa169b156f@akamai.com>   
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 07 May 2017 09:27:21 -0000

> On May 6, 2017, at 8:51 PM, Eric Rescorla  wrote:
> 
> Yes, they can. But doing so leaks a unique identifier, which can be used
> to link sessions. When I look at the privacy implications as well as the
> replay attacks, there is real value in using a resume ticket only once.
> 
> Agreed.  Also, I think that's Ben Kaduk you're quoting :)

Agreed, on the general case, but a reminder that not all applications
benefit from such "privacy".  A sending SMTP MTA has a fixed public
IP address, and even sends a fixed fixed SMTP "HELO" name in the clear
before STARTTLS.  It might of course also send SNI in the clear, ...
and will typically perform cleartext DNS queries that identify the
peer.  There is exceedingly little opportunity or desire to hide client
and server host names.  So some applications will reuse session tickets
(while avoiding 0-RTT).

-- 
	Viktor.


From nobody Mon May  8 10:43:16 2017
Return-Path: 
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 E7331128768 for ; Mon,  8 May 2017 10:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 XLdcZuC9f-k3 for ; Mon,  8 May 2017 10:43:13 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6F2126C23 for ; Mon,  8 May 2017 10:43:13 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id w50so50716232wrc.0 for ; Mon, 08 May 2017 10:43:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9g3T5uL7N4ZrQ+xOJv+f9Py7amjLWiJAiTbuvyHuUR4=; b=jTYhxPzplCNve341NIPq+3BNzdC1sEwIqSeZni9rUHi01W9IXMUCtSBNaWR5XK95J6 vD0DZhJA4LKn+BQnx4TZ3M11vBC36+KhZkwC+1C++6B5cL1vMNlJxAHAKkCRnr1Y03Z8 lltdPqKPnkYL5azSdPjZHNHjfN3drMaXj1r17ghcqZft7/GE6Ib7a4qKgDXksIjBBkNp GXD7h8N2mLR/wd5BFe/DfzC0t9xWOT6tWyO2hNO9otIQ5dLiEEufxv2n0JNwTPQdczu6 FXvjINvYjjacmu7tu2IzZQGJp/ibBnGsGQho2ncyuIxFpHcsEiLEv/n+cwK1CKq9Hw3L WgGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9g3T5uL7N4ZrQ+xOJv+f9Py7amjLWiJAiTbuvyHuUR4=; b=k6mAwJIN8UFd34xse6govPStHiJjcgqPMiAriQg2GJwtObPD9ZAn97OV2C2cCIgPBV 3wdO4RuX584+ZkKwHa+6CZZARIiR1dU+rx6OoNPAt0lDY1Xb7eQlPUEm8b26hUhJXstr srsdlFuWVkOGFYPwLDsx56/qGLGkx9JooIzJAKWIPtd/5EVoBr9xl5BtAMwqwItIZ0Kz yrornfQR6wk1qShErGWZ0ch//1RsqMZdr8mpWrM1OIvevt9i+/83sEONQkguJkUjLbz0 mG7DAfmHrlCwUPPduqqkHaZJCNvwQwuZvjJyI82Nmml1LyuCeNrVVx1Qtek1mu7B2YGL i69A==
X-Gm-Message-State: AN3rC/6EaQqHOx6xSH+V2WDqVANn79UGT8wXdzeXipQym8t11sYyC/fC 9MNXQv9aBQ1wbkmWoTLf1RYkgmw/zIBLP1s=
X-Received: by 10.223.142.135 with SMTP id q7mr40918651wrb.180.1494265391619;  Mon, 08 May 2017 10:43:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.179.68 with HTTP; Mon, 8 May 2017 10:43:10 -0700 (PDT)
In-Reply-To: 
References:  
From: Richard Barnes 
Date: Mon, 8 May 2017 13:43:10 -0400
Message-ID: 
To: Martin Thomson 
Cc: Matt Caswell , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045f4ec4de5288054f06c5f6
Archived-At: 
Subject: Re: [TLS] OpenSSL now at draft-20
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 17:43:15 -0000

--f403045f4ec4de5288054f06c5f6
Content-Type: text/plain; charset=UTF-8

On Wed, May 3, 2017 at 6:48 PM, Martin Thomson 
wrote:

> On 4 May 2017 at 02:29, Matt Caswell  wrote:
> > FYI, I have just made the necessary updates to bring the OpenSSL
> > master branch up to draft-20 compatibility. Please test!!
>
>
> That's timely.  I just landed -20 support in NSS.  It's on a branch
> because we're not switch-hitting and we don't want to upgrade Firefox
> just yet.
>
> See https://hg.mozilla.org/projects/nss/shortlog/NSS_TLS13_DRAFT19_BRANCH


... and I just landed -20 support in mint.

https://github.com/bifurcation/mint/pull/122

I haven't tried it with OpenSSL yet, but it works with Martin's branch of
NSS doing 1xRTT in both directions.

--Richard



>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045f4ec4de5288054f06c5f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, May 3, 2017 at 6:48 PM, Martin Thomson <martin.thomson@=
gmail.com> wrote:
On 4 May 2017 at 02:29, Matt Caswell <=
frodo@baggins.org> wrote:

> FYI, I have just made the necessary updates to bring the OpenSSL

> master branch up to draft-20 compatibility. Please test!!





That's timely.=C2=A0 I just landed -20 support in NSS.=C2=A0 It&=
#39;s on a branch

because we're not switch-hitting and we don't want to upgrade Firef=
ox

just yet.



See https://hg.mozilla.org/projects/nss/shortlog/NSS_TLS13_DRAFT19_BRANCH
<=
br>
... and I just landed -20 support in mint.=C2=A0 


I=
 haven't tried it with OpenSSL yet, but it works with Martin's bran=
ch of NSS doing 1xRTT in both directions.

--Richar=
d

=C2=A0





_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f403045f4ec4de5288054f06c5f6--


From nobody Mon May  8 19:33:31 2017
Return-Path: 
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 7A178128D16 for ; Mon,  8 May 2017 19:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 WCCSuxPQnBEC for ; Mon,  8 May 2017 19:33:29 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id F120A128BB6 for ; Mon,  8 May 2017 19:33:28 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3DC0E200029; Tue,  9 May 2017 02:33:28 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 2779A200003; Tue,  9 May 2017 02:33:28 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494297208; bh=unmgrX/IlCvcxeM6qlFSF1YWuI8UpUTyPaLZuxSqSks=; l=6072; h=To:References:Cc:From:Date:In-Reply-To:From; b=jTUcgzYQYkR0WVBQQMFzW+ghferbkDQH6pgGSdLpvYxlGDpf3xPvE7r/V4mieWxnM i/95UCPIQja+j/MzPnaCbEybdTu5cpGff0jclrC7L0SEQwfqkPoRvXv8M55CU7zB3r UHbU2AGLHMi+lwGjAd5Qob1QZgt2xgzYkEretLfQ=
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 B0C611E0F6; Tue,  9 May 2017 02:33:27 +0000 (GMT)
To: Ilari Liusvaara , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
References:  <20170506095834.GA4355@LK-Perkele-V2.elisa-laajakaista.fi>
Cc: "tls@ietf.org" 
From: Benjamin Kaduk 
Message-ID: <8487b6ec-70e9-ef91-1aa8-5d9f9554499e@akamai.com>
Date: Mon, 8 May 2017 21:33:27 -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: <20170506095834.GA4355@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------B9A237F7B482C650D8B2A5D2"
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 02:33:30 -0000

This is a multi-part message in MIME format.
--------------B9A237F7B482C650D8B2A5D2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
> On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
>> I wanted to start a separate thread on this, just to make some small
>> aspects of replay mitigating clear, because I'd like to make a case for TLS
>> providing a single-stream, which is what people seem to be doing anyway.
> 
>
> Couple points:
>
> - AFAIK, the 10 second or so figure in existing spec is a slop margin,
>   which means the replay window would be 20 seconds, not 10.

As the author of that text, I mostly intended it to be the total window,
not the slop margin.  But the main idea was to give an order of
magnitude, i.e., "shorter than minutes".

> - The size of the window depends on clock error margin and transport
>   delay margin. At 1s/day clock error margin, you need 14 second
>   window just from clock error.

Or you can accept full handshakes every couple hours.  Amortized that
may not be bad, if you have lots of connections.  Or you may only have
one connection every day ever, in which case it is noticeable.  It's
pretty situation-dependent.

> - It is not just low-power devices with really bad clocks. I have seen
>   20s per day(!) clock drift on high-power device that doesn't sleep.

Is there a problem with saying that devices with bad clocks talking to
beefy web servers don't get to do 0-RTT?  I don't see a problem with it.

> - So basically, the size of window is tradeoff with number of devices.

Yes.

> - That automatic wait on 0-RTT failure seems just the kind of feature
>   that gets disabled. Furthermore, 10 second idle on connection is
>   going to trigger quite a bit of connection timeouts.

I could believe that people would accept buffering data until the 1-RTT
handshake finishes (combined with rate limiting on the number of
connections with accepted 0-RTT data); I don't think people would accept
"wait the full clock skew allowance", though.

> - There seems to be no consideration how this interacts with 0-RTT
>   exporters (probably applications that accept 0-RTT will then use
>   0-RTT exporters for the entiere connection, and those exporters have
>   seriously weaker properties).
>

Yeah, the 0-RTT exporter feels like a footgun waiting to be used.

-Ben

--------------B9A237F7B482C650D8B2A5D2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:

    

      
On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:


      

        
I wanted to start a separate thread on this, just to make some small
aspects of replay mitigating clear, because I'd like to make a case for TLS
providing a single-stream, which is what people seem to be doing anyway.


      

      
<Snip a long mail>

Couple points:

- AFAIK, the 10 second or so figure in existing spec is a slop margin,
  which means the replay window would be 20 seconds, not 10.


    

    

    As the author of that text, I mostly intended it to be the total
    window, not the slop margin.  But the main idea was to give an order
    of magnitude, i.e., "shorter than minutes".

    

    

      
- The size of the window depends on clock error margin and transport
  delay margin. At 1s/day clock error margin, you need 14 second
  window just from clock error.


    

    

    Or you can accept full handshakes every couple hours.  Amortized
    that may not be bad, if you have lots of connections.  Or you may
    only have one connection every day ever, in which case it is
    noticeable.  It's pretty situation-dependent.

    

    

      
- It is not just low-power devices with really bad clocks. I have seen
  20s per day(!) clock drift on high-power device that doesn't sleep.


    

    

    Is there a problem with saying that devices with bad clocks talking
    to beefy web servers don't get to do 0-RTT?  I don't see a problem
    with it.

    

    

      
- So basically, the size of window is tradeoff with number of devices.


    

    

    Yes.

    

    

      
- That automatic wait on 0-RTT failure seems just the kind of feature
  that gets disabled. Furthermore, 10 second idle on connection is
  going to trigger quite a bit of connection timeouts.


    

    

    I could believe that people would accept buffering data until the
    1-RTT handshake finishes (combined with rate limiting on the number
    of connections with accepted 0-RTT data); I don't think people would
    accept "wait the full clock skew allowance", though.

    

    

      
- There seems to be no consideration how this interacts with 0-RTT
  exporters (probably applications that accept 0-RTT will then use
  0-RTT exporters for the entiere connection, and those exporters have
  seriously weaker properties).



    

    

    Yeah, the 0-RTT exporter feels like a footgun waiting to be used.

    

    -Ben

  


--------------B9A237F7B482C650D8B2A5D2--


From nobody Mon May  8 21:45:22 2017
Return-Path: 
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 280CB127136 for ; Mon,  8 May 2017 21:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 l0dD8Dc58koX for ; Mon,  8 May 2017 21:45:18 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3777A1205D3 for ; Mon,  8 May 2017 21:45:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 9FC72215BB; Tue,  9 May 2017 07:45:16 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id UEJMIe_MlL4W; Tue,  9 May 2017 07:45:16 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 650FF2313; Tue,  9 May 2017 07:45:16 +0300 (EEST)
Date: Tue, 9 May 2017 07:45:15 +0300
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" 
Message-ID: <20170509044515.GB8239@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20170506095834.GA4355@LK-Perkele-V2.elisa-laajakaista.fi> <8487b6ec-70e9-ef91-1aa8-5d9f9554499e@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8487b6ec-70e9-ef91-1aa8-5d9f9554499e@akamai.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 04:45:20 -0000

On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:
> On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
> > On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
> >> I wanted to start a separate thread on this, just to make some small
> >> aspects of replay mitigating clear, because I'd like to make a case for TLS
> >> providing a single-stream, which is what people seem to be doing anyway.
> > 
> >
> > Couple points:
> >
> > - It is not just low-power devices with really bad clocks. I have seen
> >   20s per day(!) clock drift on high-power device that doesn't sleep.
> 
> Is there a problem with saying that devices with bad clocks talking to
> beefy web servers don't get to do 0-RTT?  I don't see a problem with it.

Also, any device that has access to semi-accurate time (relative time
in protocols has other benefits, like not having increase magnitude with
time) could do first-order compensation, which already renders the clocks
pretty accurate, even if time comparision occurs relatively rarely.

> > - That automatic wait on 0-RTT failure seems just the kind of feature
> >   that gets disabled. Furthermore, 10 second idle on connection is
> >   going to trigger quite a bit of connection timeouts.
> 
> I could believe that people would accept buffering data until the 1-RTT
> handshake finishes (combined with rate limiting on the number of
> connections with accepted 0-RTT data); I don't think people would accept
> "wait the full clock skew allowance", though.

Did I misread the thread-starter proposal for waiting the allowance?

I think the early data provisioning already has 0-RTT buffer size, for
the case the server buffers the 0-RTT data (this buffering obviously
destroys the utility, but if it doesn't occur on every connection...)

> > - There seems to be no consideration how this interacts with 0-RTT
> >   exporters (probably applications that accept 0-RTT will then use
> >   0-RTT exporters for the entiere connection, and those exporters have
> >   seriously weaker properties).
> >
> 
> Yeah, the 0-RTT exporter feels like a footgun waiting to be used.

Unfortunately, looks like some are planning to use it, in ways
seriously broken unless the server does full replay-caching.


-Ilari


From nobody Mon May  8 22:08:09 2017
Return-Path: 
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 54EDA127B52 for ; Mon,  8 May 2017 22:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level: 
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 cpdcLf9C5wsT for ; Mon,  8 May 2017 22:08:06 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id A670912704A for ; Mon,  8 May 2017 22:08:06 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D8E00433451; Tue,  9 May 2017 05:08:05 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C2B35433413; Tue,  9 May 2017 05:08:05 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494306485; bh=afvA+yeLcwHZV9lEsxbKmBrOBEY4XrXgh8SxuPR1XM0=; l=4596; h=To:References:Cc:From:Date:In-Reply-To:From; b=LERGbUsH/QuETUl6SYDVwr9OKx8wlNIXv77yk+G3+BQr7KNTi5QsYr9+i5616qQcY xuaZP9to1jGQjGI25ylSSCVKIclH0MJpU2SfB0/aFAX3czDWvreJDxafc2rbEj8ODl /0ZX4thKmDJkXIez3sflRsPdcyRNWXAgX1vm3l4E=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7E6701FD16; Tue,  9 May 2017 05:08:05 +0000 (GMT)
To: Ilari Liusvaara 
References:  <20170506095834.GA4355@LK-Perkele-V2.elisa-laajakaista.fi> <8487b6ec-70e9-ef91-1aa8-5d9f9554499e@akamai.com> <20170509044515.GB8239@LK-Perkele-V2.elisa-laajakaista.fi>
Cc: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "tls@ietf.org" 
From: Benjamin Kaduk 
Message-ID: <7de26f98-84fe-3d65-a5fe-6b6f78efd981@akamai.com>
Date: Tue, 9 May 2017 00:08:05 -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: <20170509044515.GB8239@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------E4F9D0CDBC7876D349F71BC1"
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 05:08:08 -0000

This is a multi-part message in MIME format.
--------------E4F9D0CDBC7876D349F71BC1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/08/2017 11:45 PM, Ilari Liusvaara wrote:
> On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:
>> On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
>>
>>> - That automatic wait on 0-RTT failure seems just the kind of feature
>>>   that gets disabled. Furthermore, 10 second idle on connection is
>>>   going to trigger quite a bit of connection timeouts.
>> I could believe that people would accept buffering data until the 1-RTT
>> handshake finishes (combined with rate limiting on the number of
>> connections with accepted 0-RTT data); I don't think people would accept
>> "wait the full clock skew allowance", though.
> Did I misread the thread-starter proposal for waiting the allowance?

No, I think you read it correctly (and I agree with you).
I have a more detailed reply to the original message in a compose
window, but it will not be done tonight.

> I think the early data provisioning already has 0-RTT buffer size, for
> the case the server buffers the 0-RTT data (this buffering obviously
> destroys the utility, but if it doesn't occur on every connection...)
>
>>> - There seems to be no consideration how this interacts with 0-RTT
>>>   exporters (probably applications that accept 0-RTT will then use
>>>   0-RTT exporters for the entiere connection, and those exporters have
>>>   seriously weaker properties).
>>>
>> Yeah, the 0-RTT exporter feels like a footgun waiting to be used.
> Unfortunately, looks like some are planning to use it, in ways
> seriously broken unless the server does full replay-caching.
>

:( :( :(

Clearly we should make sure their documents prominently note the
requirement for strong replay protection, but is there more we can do?

-Ben

--------------E4F9D0CDBC7876D349F71BC1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 05/08/2017 11:45 PM, Ilari Liusvaara wrote:

    

      
On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:


      

        
On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:


        

      

      

        

          
- That automatic wait on 0-RTT failure seems just the kind of feature
  that gets disabled. Furthermore, 10 second idle on connection is
  going to trigger quite a bit of connection timeouts.


        

        
I could believe that people would accept buffering data until the 1-RTT
handshake finishes (combined with rate limiting on the number of
connections with accepted 0-RTT data); I don't think people would accept
"wait the full clock skew allowance", though.


      

      
Did I misread the thread-starter proposal for waiting the allowance?


    

    

    No, I think you read it correctly (and I agree with you).

    I have a more detailed reply to the original message in a compose
    window, but it will not be done tonight.

    

    

      
I think the early data provisioning already has 0-RTT buffer size, for
the case the server buffers the 0-RTT data (this buffering obviously
destroys the utility, but if it doesn't occur on every connection...)



      

        

          
- There seems to be no consideration how this interacts with 0-RTT
  exporters (probably applications that accept 0-RTT will then use
  0-RTT exporters for the entiere connection, and those exporters have
  seriously weaker properties).



        

        
Yeah, the 0-RTT exporter feels like a footgun waiting to be used.


      

      
Unfortunately, looks like some are planning to use it, in ways
seriously broken unless the server does full replay-caching.



    

    

    :( :( :(

    

    Clearly we should make sure their documents prominently note the
    requirement for strong replay protection, but is there more we can
    do?

    

    -Ben

  


--------------E4F9D0CDBC7876D349F71BC1--


From nobody Tue May  9 09:00:57 2017
Return-Path: 
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 B6AF512E76A for ; Tue,  9 May 2017 09:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 QOUtlpSL_pnW for ; Tue,  9 May 2017 09:00:40 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB87B1270A3 for ; Tue,  9 May 2017 09:00:40 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v49Fq7G4025406; Tue, 9 May 2017 17:00:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=I2/T/zrQHxuu5mDIMJPvDCRQ544YFyQj2kVKMMTkRUE=; b=CaMMauCcC0ebmIB0DqTlsra5ZINjDxCIGScoGQdMetmgXhl06K0BkmZg1hIcesqbcFiH PRLN4gOngyiCDzdAp1mP6zlaKyYcQ9i/KZEJvsEQ+FZlEWOnjjLNRT8qC4+CC2eGzlR3 TtchRz2q2c07/1pjP0epkbA+BGs3SfYMCKpkL/eTU0Akx/t6s9Sxy1/GGapdIbp5C+zY ryrITGCraHTRLIaqxat3lCkBVJoyys3trs9HuXTzbggFeCtDDbwBmLBP/xaTz9Yt6mxR F5ZTISEq3oy0L7k2t0Pu3gA1eyGFh74UH1aAyIN1YE8UPVB2YCt6ZXZ6rcjOlsO7PtfK RA== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2abatx2j48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 May 2017 17:00:38 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v49FuGD3031297; Tue, 9 May 2017 12:00:36 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a99tvyyhw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 May 2017 12:00:36 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 12:00:35 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 9 May 2017 12:00:35 -0400
From: "Salz, Rich" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "tls@ietf.org" 
Thread-Topic: [TLS] The case for a single stream of data
Thread-Index: AQHSxbylbnClX7eBZUm2Z/AGF1sif6HsLwTA
Date: Tue, 9 May 2017 16:00:34 +0000
Message-ID: <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.228]
Content-Type: multipart/alternative; boundary="_000_9f5858c8d86742b9aa82bdac46590c92usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090085
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090085
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 16:00:48 -0000

--_000_9f5858c8d86742b9aa82bdac46590c92usma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VG8gbWUsIHRoZSBhcmd1bWVudCBhZ2FpbnN0IHRoaXMgY29tZXMgZG93biB0byB0aGlzOiAgVGhl
IDBSVFQgZGF0YSBoYXMgZGlmZmVyZW50IHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhbiB0aGUgcG9z
dC1oYW5kc2hha2UgZGF0YSwgYW5kIFRMUyBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIG5vdCBoaWRl
IHRoYXQgZGlmZmVyZW5jZSBmcm9tIGFwcGxpY2F0aW9ucy4NCg0KLS0NClNlbmlvciBBcmNoaXRl
Y3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06IHJp
Y2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K

--_000_9f5858c8d86742b9aa82bdac46590c92usma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIG1lLCB0aGUgYXJndW1lbnQgYWdhaW5zdCB0aGlzIGNv
bWVzIGRvd24gdG8gdGhpczombmJzcDsgVGhlIDBSVFQgZGF0YSBoYXMgZGlmZmVyZW50IHNlY3Vy
aXR5IHByb3BlcnRpZXMgdGhhbiB0aGUgcG9zdC1oYW5kc2hha2UgZGF0YSwgYW5kIFRMUyBpbXBs
ZW1lbnRhdGlvbnMgc2hvdWxkIG5vdCBoaWRlDQogdGhhdCBkaWZmZXJlbmNlIGZyb20gYXBwbGlj
YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW5pb3IgQXJjaGl0ZWN0LCBB
a2FtYWkgVGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklNOiBy
aWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_9f5858c8d86742b9aa82bdac46590c92usma1exdag1mb1msgcorpak_--


From nobody Tue May  9 09:26:06 2017
Return-Path: 
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 0B2A1129ADF for ; Tue,  9 May 2017 09:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 1SUMKy_Gy6Us for ; Tue,  9 May 2017 09:26:03 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D176B1294CC for ; Tue,  9 May 2017 09:26:02 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DE3D77A32F1 for ; Tue,  9 May 2017 16:26:01 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
Date: Tue, 9 May 2017 12:26:01 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: <3510843A-8628-4859-B627-55C4EC7111D9@dukhovni.org>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 16:26:04 -0000

> On May 9, 2017, at 12:00 PM, Salz, Rich  wrote:
> 
> To me, the argument against this comes down to this:  The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.

What would a receiver API then look like?  Would it be something like:

  * Repeatedly request 0-RTT data until none-remains, if none expected
    or desired, fail if any found.

  * Then repeatedly request 1-RTT data via existing TLS APIs

  * Fail if 1-RTT data is requested and not all the 0-RTT data has yet
    been consumed?

Or did you have something else in mind?  What are your thoughts on the
sender side?  Just enable 0-RTT and have the toolkit send as much 0-RTT
data as "fits" and the rest 1-RTT, or an explicit request for a specific
0-RTT payload?

-- 
	Viktor.


From nobody Tue May  9 09:27:42 2017
Return-Path: 
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 26A4A129C1E for ; Tue,  9 May 2017 09:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 6veR4QCSELKv for ; Tue,  9 May 2017 09:27:39 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7C112948B for ; Tue,  9 May 2017 09:27:39 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id p143so1570983yba.2 for ; Tue, 09 May 2017 09:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3jnYuC+eXzN+ENNaH5mTkVjlvZMOfq1U2VKOp+lAiV8=; b=NLjshpvv33wO04XGJpvGCpFtkkDfBo2H3oTFv3ulS/X0JhiF9m9Jp4JaDBPsK4mQkV +l90QhOlc7VrvITn645a+bvYEQHKiQkh15z/NVMvY5lgH5m0US9fojVeguhm1kOZTKBg 2KnCQLOvjiFw8fKamAuEA0zSVi3DOxuu5AVFNeusHT4iJu0BiNNvUMOVYY2B4iifPuST p7O6tSS1uiQKPkDoOJ6sDSJyv9xxmwnYFSkqEYAcY6lxGlhfNOwqwf8nHJoE6e5EhrAO X4ZoESbDxV3KHE2854T+52Fz1qnsJf1julU9bGIuT049NDITGQH/L6Ax88SMSziMKezR iluA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3jnYuC+eXzN+ENNaH5mTkVjlvZMOfq1U2VKOp+lAiV8=; b=HykJzeRQiadt2qTXhwgYyWPSDdWGesudsNMnTOgiFaUJ3dt6SRuCyBYIE2yJIhhkm+ yQHX65VVzkdbiTJDXjDAUTLsXLETf6WrkCYaIvfUl8vfKwNVyx/layr4BTmQZdwq8Zpz 4mZvgyrZ30KHclaEzJBArCoy5dUF3KHkNk6LLHR6xnLyF0lCX4v4L0+hCkH80IoMu76q 2i07DhYSxMbMm+nu0LHfw3iCQD2IglbK56C/e3fbkkUqRCe2eElxGwRCsF12Os2IooGq /D3fa8NOuVvCTd+8bVLu4ZI45lt7KTXOBgdAJLn2Iv+fm25uIBaHQ3N+2pfvgXdBbaaV QN8w==
X-Gm-Message-State: AODbwcDfI5fvQHkFRy7Af3V7Rv/D6gBmMV9e9syHKwBqjbQLcjPXo11J HQQASEvWVmsKfFIzSJFseImiRdPtkA==
X-Received: by 10.37.16.212 with SMTP id 203mr897340ybq.90.1494347258345; Tue, 09 May 2017 09:27:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Tue, 9 May 2017 09:27:37 -0700 (PDT)
In-Reply-To: <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Tue, 9 May 2017 09:27:37 -0700
Message-ID: 
To: "Salz, Rich" 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c0ff0481c5b4054f19d514
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 16:27:41 -0000

--001a11c0ff0481c5b4054f19d514
Content-Type: text/plain; charset=UTF-8

On Tue, May 9, 2017 at 9:00 AM, Salz, Rich  wrote:

> To me, the argument against this comes down to this:  The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.
>

I absolutely agree with sentiment, but the first problem is that we've been
concentrating on the server side, where it's actually impossible.

It's actually impossible because a 0RTT request may be retried as a 1RTT
request and there's no way to correlate the two. So when the 1RTT request
shows up, we can't go "This might be a repeat" - for example the X- header
trick doesn't work in this case. It's subtle, which makes it even more
likely to trip on it.

I think the only approach that actually rigorously works is the client-side
one, that I outlined. That approach isn't very relevant to browsers, who
plan to retry aggressively anyway, but I think it's the only approach that
would work for a careful client. Interestingly, it doesn't really need
separate streams for the signaling to work. Though it'd be great to see a
formal proof in something like F*, Coq or TLA+.

The second problem is that middle-boxes can break any signaling. For
example a CDN or TLS accelerator may enable 0-RTT towards the back-end
origin without enabling it to the original client. In this model, the
client has *no* way to reason about retries or replay. That's really very
broken and a serious violation of the transport layer contract. I think we
should be more prescriptive here and say that if there are to be these
kinds of middle-boxes, then they need to honor maximum replay windows, and
they need to only enable 0-RTT from the client back. (e.g. client enabled,
but origin disabled is actually ok, but not the other way around).

In going through all of this, I'm assuming that the server at least has a
robust mitigation against 0-RTT replay, because not doing so is clearly
broken and I'm even entertaining how it can be supported. That stateless
form of mitigation is insecure and should die. If there's a notion that
server side signaling should be kept to facilitate stateless mitigation
(which permits millions of replays) ... we shouldn't have any time for
that, because no-one has a proposal for how the secrecy attacks can be
mitigated.


-- 
Colm

--001a11c0ff0481c5b4054f19d514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, May 9, 2017 at 9:00 AM, Salz, Rich <rsalz@akamai.com> wrote:











To me, the argument against this comes down to this=
:=C2=A0 The 0RTT data has different security properties than the post-hands=
hake data, and TLS implementations should not hide
 that difference from applications.

I absolutely agree with sentiment, but the first problem is=
 that we've been concentrating on the server side, where it's actua=
lly impossible.=C2=A0

It's actually impossible=
 because a 0RTT request may be retried as a 1RTT request and there's no=
 way to correlate the two. So when the 1RTT request shows up, we can't =
go "This might be a repeat" - for example the X- header trick doe=
sn't work in this case. It's subtle, which makes it even more likel=
y to trip on it.=C2=A0

I think the only approach t=
hat actually rigorously works is the client-side one, that I outlined. That=
 approach isn't very relevant to browsers, who plan to retry aggressive=
ly anyway, but I think it's the only approach that would work for a car=
eful client. Interestingly, it doesn't really need separate streams for=
 the signaling to work. Though it'd be great to see a formal proof in s=
omething like F*, Coq or TLA+. =C2=A0

The second p=
roblem is that middle-boxes can break any signaling. For example a CDN or T=
LS accelerator may enable 0-RTT towards the back-end origin without enablin=
g it to the original client. In this model, the client has *no* way to reas=
on about retries or replay. That's really very broken and a serious vio=
lation of the transport layer contract. I think we should be more prescript=
ive here and say that if there are to be these kinds of middle-boxes, then =
they need to honor maximum replay windows, and they need to only enable 0-R=
TT from the client back. (e.g. client enabled, but origin disabled is actua=
lly ok, but not the other way around).=C2=A0

In going through all of=
 this, I'm assuming that the server at least has a robust mitigation ag=
ainst 0-RTT replay, because not doing so is clearly broken and I'm even=
 entertaining how it can be supported. That stateless form of mitigation is=
 insecure and should die. If there's a notion that server side signalin=
g should be kept to facilitate stateless mitigation (which permits millions=
 of replays) ... we shouldn't have any time for that, because no-one ha=
s a proposal for how the secrecy attacks can be mitigated.=C2=A0
=


-- 
Colm




--001a11c0ff0481c5b4054f19d514--


From nobody Tue May  9 09:31:49 2017
Return-Path: 
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 8E67212DDD2 for ; Tue,  9 May 2017 09:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 gx8uM30djIP5 for ; Tue,  9 May 2017 09:31:45 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CC112948B for ; Tue,  9 May 2017 09:31:45 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v49GRG6G018109 for ; Tue, 9 May 2017 17:31:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Ijb/HbJbMxlwEFdfgQ36Uyrl1o6oQUmKhzEavWiYKVM=; b=AWrHUiXBOFgKkaUfotOBs0pQMPdHYrVKmeQhL93uvgkgMBwK4GXRzWryzgITzB/e5VmZ Z5O3j4EMJjyWGdFVwg9TjWTeTj7C240dYTbIGiZXCO6Ba5Vyl+BWwj+vCfSGJcQs4AdG hZ4kDgLZqb00i594oAXhB4OsSyPgSeRD5ZKYdTvP0WAqtoCWJo7VvDBqNRVAiYt1wiUt 514uGQm3dsPIJx7fvoqv2s78j9CQYTB/NHbJ1rjbz2iCgBCpFKZxq9vG9w5MuRt65G7H cgpIitceNdjVI57L2QD6KR+6wBxtg2WdY2pOl7hOIt84wn3xDo4VLopzGcqaB+4owoBt ww== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2abcamhx6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 09 May 2017 17:31:42 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v49GQ0ll017959 for ; Tue, 9 May 2017 12:31:42 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a99tudfnw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 09 May 2017 12:31:42 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 12:31:40 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 12:31:39 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 9 May 2017 12:31:39 -0400
From: "Salz, Rich" 
To: TLS WG 
Thread-Topic: [TLS] The case for a single stream of data
Thread-Index: AQHSxbylbnClX7eBZUm2Z/AGF1sif6HsLwTAgABKdYD//73KwA==
Date: Tue, 9 May 2017 16:31:39 +0000
Message-ID: <1a5362f76c8e445ea03c425741790177@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com> <3510843A-8628-4859-B627-55C4EC7111D9@dukhovni.org>
In-Reply-To: <3510843A-8628-4859-B627-55C4EC7111D9@dukhovni.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.228]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090087
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090087
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 16:31:48 -0000

> What would a receiver API then look like?  Would it be something like:
...
> Or did you have something else in mind?  What are your thoughts on the
> sender side?  Just enable 0-RTT and have the toolkit send as much 0-RTT d=
ata
> as "fits" and the rest 1-RTT, or an explicit request for a specific 0-RTT=
 payload?

As implemented in OpenSSL; see=20
   https://www.openssl.org/docs/manmaster/man3/SSL_read_early_data.html
(which also describes the "write" part, and the query and control functions=
.)


From nobody Tue May  9 09:41:29 2017
Return-Path: 
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 90837129B62 for ; Tue,  9 May 2017 09:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 u-v5k12muXTl for ; Tue,  9 May 2017 09:41:26 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6976F1279EB for ; Tue,  9 May 2017 09:41:25 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v49GbnHq007385; Tue, 9 May 2017 17:41:23 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=eii5/1qWebsUzDWn4cdlE0viVJOtXdiq4Oop025AleU=; b=DsMtK/fEo6GPRn/RJcGCIOQ8yvZ5Eisc1PppnTMt1E0Z9NVwFFsvKdlgjHPBBj5gM7iF 7wKql0vfSZBWHU9aRx3LXhARtgXTueD1RXsXUGABlooVDN3RgZcfEc/oHBIWQQ7bIWZM h5CYYeR63dku6K4BbTYZCtzsLc2z1+dZ+rI1sFfqi/AYJC6MfDxLvgqnDK41VDsjtIzN 0EX/H7LlVcIN+2t7INpmQQOt6ucITw8MXGdPU6L8YlAE2dBB4VWJYuUzzuO43ayT0LGT ZoMS2poQPoDP6wROTn3I9aRKfR1fe1TG0VaNJaEmDuZvw3nG6JJXXEvb43vX+H9OQ8fo 7A== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2abatx2tuv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 May 2017 17:41:23 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v49Ge3Xn002944; Tue, 9 May 2017 12:41:21 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a99tunhd0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 May 2017 12:41:21 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 12:41:20 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 9 May 2017 12:41:20 -0400
From: "Salz, Rich" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] The case for a single stream of data
Thread-Index: AQHSxbylbnClX7eBZUm2Z/AGF1sif6HsLwTAgABK54D//79nIA==
Date: Tue, 9 May 2017 16:41:19 +0000
Message-ID: <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090088
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090089
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 16:41:28 -0000

PiBJdCdzIGFjdHVhbGx5IGltcG9zc2libGUgYmVjYXVzZSBhIDBSVFQgcmVxdWVzdCBtYXkgYmUg
cmV0cmllZCBhcyBhIDFSVFQgcmVxdWVzdCBhbmQgdGhlcmUncyBubyB3YXkgdG8gY29ycmVsYXRl
IHRoZSB0d28uIFNvIHdoZW4gdGhlIDFSVFQgcmVxdWVzdCBzaG93cyB1cCwgd2UgY2FuJ3QgZ28g
IlRoaXMgbWlnaHQgYmUgYSByZXBlYXQiIC0gZm9yIGV4YW1wbGUgdGhlIFgtIGhlYWRlciB0cmlj
ayBkb2Vzbid0IHdvcmsgaW4gdGhpcyBjYXNlLiBJdCdzIHN1YnRsZSwgd2hpY2ggbWFrZXMgaXQg
ZXZlbiBtb3JlIGxpa2VseSB0byB0cmlwIG9uIGl0LsKgDQoNClRoYXQgYWxzbyBhc3N1bWVzIHRo
YXQgdGhlIDBSVFQgZGF0YSB3aWxsIGJlIGEgY29tcGxldGVseSBzZWxmLWNvbnRhaW5lZCByZXF1
ZXN0LiAgSSBzaGFyZSB0aGUgY29uY2VybiB0aGF0IEt5bGUgYW5kIG90aGVycyBoYXZlIHBvaW50
ZWQgb3V0LCB0aGF0IGEgc2luZ2xlIHJlcXVlc3Qgd2lsbCBzcGFuIHRoZSBib3VuZGFyaWVzLg0K
DQo+IEkgdGhpbmsgdGhlIG9ubHkgYXBwcm9hY2ggdGhhdCBhY3R1YWxseSByaWdvcm91c2x5IHdv
cmtzIGlzIHRoZSBjbGllbnQtc2lkZSBvbmUNCg0KQXR0YWNrZXJzIHdpbGwgbm90IHVzZSB3ZWxs
LWJlaGF2ZWQgY2xpZW50czsgZG9lcyB5b3VyIGFwcHJvYWNoIHN0aWxsIHdvcms/DQoNCj5UaGUg
c2Vjb25kIHByb2JsZW0gaXMgdGhhdCBtaWRkbGUtYm94ZXMgY2FuIGJyZWFrIGFueSBzaWduYWxp
bmcuIEZvciBleGFtcGxlIGEgQ0ROIG9yIFRMUyBhY2NlbGVyYXRvciBtYXkgZW5hYmxlIDAtUlRU
IHRvd2FyZHMgdGhlIGJhY2stZW5kIG9yaWdpbiB3aXRob3V0IGVuYWJsaW5nIGl0IHRvIHRoZSBv
cmlnaW5hbCBjbGllbnQuIEluIHRoaXMgbW9kZWwsIHRoZSBjbGllbnQgaGFzICpubyogd2F5IHRv
IHJlYXNvbiBhYm91dCByZXRyaWVzIG9yIHJlcGxheS4NCg0KQSBDRE4gaXMgbm90IGEgbWlkZGxl
Ym94LiAgQXMgZmFyIGFzIHRoZSBjbGllbnQgaXMgY29uY2VybmVkIGEgQ0ROICppcyogdGhlIG9y
aWdpbi4gIFRoZSBhZ3JlZW1lbnQgaW4tcGxhY2UgYmV0d2VlbiB0aGUgQ0ROIGFuZCB0aGUgb3Jp
Z2luIGlzIG91dCBvZiBzY29wZSBoZXJlLiAgQSBUTFMgYWNjZWxlcmF0b3IsIHdoaWNoIGlzIGEg
dG9vbCB0byBoZWxwIGFuIG9yaWdpbiB3aXRoIGl0cyAqbG9jYWwqIHBlcmZvcm1hbmNlLCBvciBv
dGhlciBsb3dlci1sYXllciAoaW4gdGhlIEwzIEw1IGV0YyBzZW5zZSkgYXNzaXN0IGlzIHdpdGhp
biBzY29wZS4gIERvZXMgdGhhdCBtYWtlIHNlbnNlPw0KDQo+IFRoYXQncyByZWFsbHkgdmVyeSBi
cm9rZW4gYW5kIGEgc2VyaW91cyB2aW9sYXRpb24gb2YgdGhlIHRyYW5zcG9ydCBsYXllciBjb250
cmFjdC4NCg0KT25seSBpZiB5b3UgYmVsaWV2ZSBDRE4gaXMgYSBtaWRkbGVib3guICBUaGUgdHJh
bnNwb3J0IGxheWVyIGNvbnRyYWN0IGlzIG92ZXJyaWRkZW4gYnkgbGVnYWwgY29udHJhY3RzIG9y
IEVVTEEgOikNCg0KCS9yJA0KDQo=


From nobody Tue May  9 10:28:33 2017
Return-Path: 
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 D6A2C1294F3 for ; Tue,  9 May 2017 10:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.802
X-Spam-Level: 
X-Spam-Status: No, score=-4.802 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=microsoft.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 dlua_Ttps5S9 for ; Tue,  9 May 2017 10:28:30 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1F1127076 for ; Tue,  9 May 2017 10:28:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JIDU28dNwAZRgTeirApLXMewg3UgqJz+Ae8L8705pDQ=; b=Q+7XI1vnyHF/tmjdBIpVVEPLUEWL9sGIcZK6AL9IurYUfXw/6szTC06bQ9TFjp5uF/pINL+gnfP2nGU5RBtqKDPeyh3/rjRi1YHM9DUGlzGYNMZqwzkla1S2RKWxk0N87OsHbfvt2Ohu/83AVvaP2nA85iDuLBxzNsIaXkFcdIo=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0092.namprd21.prod.outlook.com (10.161.141.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.0; Tue, 9 May 2017 17:28:27 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1101.000; Tue, 9 May 2017 17:28:27 +0000
From: Andrei Popov 
To: "Salz, Rich" , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] The case for a single stream of data
Thread-Index: AQHSxbyr6+FqrvsOD063PUQX/Ho2+aHsL04AgAAHj4CAAAPUgIAAC1hQ
Date: Tue, 9 May 2017 17:28:27 +0000
Message-ID: 
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>  <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0092; 7:ET6mYxVR2sdoNBeyPib+5P8Fu7pKqiIJy/8hYLIMrqxl0o3ckGxZ+M5H8g3R7yN6QLbnZsFi42r0y7IN8KdfVVa/mtqpOW7vF115I6frG5ps1QH5PhGsTF9mPCFxrEvfiuuzgoGvVw/sQhDlmnesCNNuHs52jA3wzMQzWraG/T0snipilkVMS8bPKRBiij2Dt1O2FR1U0JxBXk/elU/VS7wemU1u7U2euVNl9RcDyKTCwavAiO9+PNbZZXcotU9YlIJJHM4x3YYmnDk+fBcUbSr0o76+0+p7qcWXS5R9l0H1yY4D4PARaTb3OflNpjod76HIjg3kzcXOFUR7MZTz5Ka9olhry7Ea6r2nRTHgkVI=
x-ms-traffictypediagnostic: DM2PR21MB0092:
x-ms-office365-filtering-correlation-id: 04ca2c15-9950-449c-40a7-08d49700cdbe
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR21MB0092; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703036)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:DM2PR21MB0092; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:DM2PR21MB0092; 
x-forefront-prvs: 0302D4F392
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39410400002)(39400400002)(39850400002)(33656002)(3660700001)(77096006)(93886004)(6116002)(6506006)(2950100002)(3280700002)(2906002)(8936002)(81166006)(8676002)(229853002)(2900100001)(86362001)(5660300001)(189998001)(9686003)(74316002)(38730400002)(478600001)(99286003)(10290500003)(122556002)(76176999)(7696004)(54356999)(6436002)(50986999)(53936002)(5005710100001)(10090500001)(6246003)(7736002)(305945005)(55016002)(4326008)(25786009)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0092; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2017 17:28:27.1799 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0092
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 17:28:32 -0000

PiBUbyBtZSwgdGhlIGFyZ3VtZW50IGFnYWluc3QgdGhpcyBjb21lcyBkb3duIHRvIHRoaXM6ICBU
aGUgMFJUVCBkYXRhIGhhcyBkaWZmZXJlbnQgc2VjdXJpdHkgcHJvcGVydGllcyB0aGFuIHRoZSBw
b3N0LWhhbmRzaGFrZSBkYXRhLCBhbmQgVExTIGltcGxlbWVudGF0aW9ucyBzaG91bGQgbm90IGhp
ZGUgdGhhdCBkaWZmZXJlbmNlIGZyb20gYXBwbGljYXRpb25zLg0KVGhpcyBpcyB0cnVlLCBhbmQg
ZWFybHkgb24gdGhlcmUgc2VlbWVkIHRvIGJlIGdlbmVyYWwgYWdyZWVtZW50IHRoYXQgMC1SVFQg
ZGF0YSB3b3VsZCByZXF1aXJlIGV4cGxpY2l0IG9wdC1pbiBmcm9tIHRoZSBjYWxsZXIsIGUuZy4g
dmlhIG5ldyBBUEkgc3VyZmFjZS4NCg0KPiBPbmNlIHRoZSBpbml0aWFsIFNTTF93cml0ZV9lYXJs
eV9kYXRhKCkgY2FsbCBoYXMgY29tcGxldGVkIHN1Y2Nlc3NmdWxseSB0aGUgY2xpZW50IG1heSBp
bnRlcmxlYXZlIGNhbGxzIHRvIFNTTF9yZWFkX2V4KDMpIGFuZCBTU0xfcmVhZCgzKSB3aXRoIGNh
bGxzIHRvIFNTTF93cml0ZV9lYXJseV9kYXRhKCkgYXMgcmVxdWlyZWQuDQpJJ20gY3VyaW91cyB3
aHkgdGhlIGNsaWVudCBkb2VzIG5vdCBoYXZlIHRvIGNhbGwgU1NMX3JlYWRfZWFybHlfZGF0YSBp
bnN0ZWFkIG9mIHRoZSBub3JtYWwgU1NMX3JlYWQgaW4gdGhpcyBjYXNlLg0KDQpDaGVlcnMsDQoN
CkFuZHJlaQ0K


From nobody Tue May  9 10:30:46 2017
Return-Path: 
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 B93E8129BA4 for ; Tue,  9 May 2017 10:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 5DoR6uno9kDy for ; Tue,  9 May 2017 10:30:42 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939AA129C1E for ; Tue,  9 May 2017 10:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494351039; l=1602; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=4I8JnOGKnxaZ+vkqcWJjNDaAPFLgIGDU0bxRSQJzDxw=; b=F02EhvfpE3QCNXZYf49bevl77qpcVQp8KD0T4xzqkeoId/umSJaiVO2zXd7i6GIWGd BsNhWd/X8FEhlhdMnvcebQWcxQGI3Dn0hNopKgWmJNUiTLog5X8B/bV+JSnc067DW8eY F1GoQ0EP5AcPlrvlW0PjYMUg5lF5oU7ghUdkU=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWW4p8jDXe5M9gWO76GPk
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p57B96B9B.dip0.t-ipconnect.de [87.185.107.155]) by smtp.strato.de (RZmta 40.6 DYNA|AUTH) with ESMTPSA id n06cc1t49HUcnI8 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Tue, 9 May 2017 19:30:38 +0200 (CEST)
To: tls@ietf.org
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>  <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Roland Zink 
Message-ID: <5a5e0448-1b1a-1b92-e22b-f4c095f2bfbd@zinks.de>
Date: Tue, 9 May 2017 19:30:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 17:30:45 -0000

Am 09.05.2017 um 18:41 schrieb Salz, Rich:
> The second problem is that middle-boxes can break any signaling. For example a CDN or TLS accelerator may enable 0-RTT towards the back-end origin without enabling it to the original client. In this model, the client has *no* way to reason about retries or replay.
> A CDN is not a middlebox.  As far as the client is concerned a CDN *is* the origin.  The agreement in-place between the CDN and the origin is out of scope here.  A TLS accelerator, which is a tool to help an origin with its *local* performance, or other lower-layer (in the L3 L5 etc sense) assist is within scope.  Does that make sense?

Depends on how you look on this. For TLS the CDN is the origin. For an 
end user the CDN is often a third party which means some unknown 
entities get access to potential private data. When this is on another 
country this may include foreign official entities in addition to the 
3rd party company itself. Really bad is when the user is not informed at 
all, e.g. the page URL doesn't show the CDN (or ad or tracking) company. 
For a mass surveillance just monitor a few tracking, advertising or CDN 
companies and you will get most of the URLs (refer header) and more from 
most users without breaking the TLS security. So why do TLS at all?

>> That's really very broken and a serious violation of the transport layer contract.
> Only if you believe CDN is a middlebox.  The transport layer contract is overridden by legal contracts or EULA :)
>
> 	/r$
I would prefer if TLS wouldn't allow 3rd parties without user notification.

Roland


From nobody Tue May  9 10:35:42 2017
Return-Path: 
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 5E88B129536 for ; Tue,  9 May 2017 10:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 Jwb7LwxJ4YlI for ; Tue,  9 May 2017 10:35:38 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67CF129511 for ; Tue,  9 May 2017 10:35:38 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id 203so4113441ywe.0 for ; Tue, 09 May 2017 10:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uuOYRXRjpGGZuoi3EAk/fo9/Svk3WnB6d7h97ondEKc=; b=XOkoD+W7sMPtXoEqWRkMT/3a9+qfaHVb9XEK4cavaJ7OLp7qATO0TW8HvN2k3LVUUR 33JICUC1XIaxheVFc5sImPv5h6kOvrKeBt+BIpHJsUs4CS21WX5GWPKvfeOp/D6u0a9o jJWb+eICbs1/nj80kk6+Kuszx58PzV7lhMYR1syhycDF3+hcBX/COkB37dHmZUlQJKJU rLIUypFQTZM+hXr/b8MhUrOh86ZnKD5wQNXIvceQznizHzwOhfk2VEAq7j66DwWUEudU OZjZloth8hr0Je/n64Y2jZvc0Q+097Lxbezd9bZEq9J6qUdzUmZi3b1/xp3wvrM4n+2t meVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uuOYRXRjpGGZuoi3EAk/fo9/Svk3WnB6d7h97ondEKc=; b=aQQcesttc7S+FpoKpA1XpjcwZ/9TV17qnDYd3GOTBa2aS98HSQBFcXYB8gIFjRhXs8 BydiAC6yK04j4YgTKX9s8LyOttS9fvI7ypxhYsXWxaniMOmTybRyYCPg8GSpxFexKFD/ bKCdt4LCqipPKf89ir9nAgfrCXGmatixdq/a6+GpuDcUgg2yTanuHrEIr5BCkqDHtsbc Bryc5xnyDVHmGYedfw3hxhKwLrDD6gDcadA7Ukf6oqmIhVeiRexO4tVjxM1DZbzEgvhm /PII+MVv2x+kgSsjQX1n+/WNUaLm76VK8wBQLJ/fQg8brMjUceZVmkSyjpEbgM454+hq V3Sg==
X-Gm-Message-State: AODbwcBchEoSw9YKSuskFIwpVUrY4YlISs2yGH9LwFxC73pjNYZGHBSt vk/tVCQB2AIKz5C5hYSRBkT+FP0x9Q==
X-Received: by 10.129.56.11 with SMTP id f11mr1080723ywa.241.1494351337934; Tue, 09 May 2017 10:35:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Tue, 9 May 2017 10:35:37 -0700 (PDT)
In-Reply-To: <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>  <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Tue, 9 May 2017 10:35:37 -0700
Message-ID: 
To: "Salz, Rich" 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11483b10ab0b85054f1ac8a1
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 17:35:40 -0000

--001a11483b10ab0b85054f1ac8a1
Content-Type: text/plain; charset=UTF-8

On Tue, May 9, 2017 at 9:41 AM, Salz, Rich  wrote:

> > It's actually impossible because a 0RTT request may be retried as a 1RTT
> request and there's no way to correlate the two. So when the 1RTT request
> shows up, we can't go "This might be a repeat" - for example the X- header
> trick doesn't work in this case. It's subtle, which makes it even more
> likely to trip on it.
>
> That also assumes that the 0RTT data will be a completely self-contained
> request.  I share the concern that Kyle and others have pointed out, that a
> single request will span the boundaries.
>

True; though I think the partial request case it's ok ... I think it's just
orphaned data. The mechanisms that prevent 0-RTT insertion across different
connections do seem robust.


> > I think the only approach that actually rigorously works is the
> client-side one
>
> Attackers will not use well-behaved clients; does your approach still work?
>

Yes; it's about signaling to the client that "Your data may or may not have
been received". This is an ordinary failure mode for TCP and TLS and
something many clients have careful reasoning around. The difference with
0-RTT is now there's a bigger window of time during which that request may
get received, but that's it really. If the attacker replays, then it can be
received; and the attacker can use any client, but it doesn't change the
original well-behaved client's reasoning.

>The second problem is that middle-boxes can break any signaling. For
> example a CDN or TLS accelerator may enable 0-RTT towards the back-end
> origin without enabling it to the original client. In this model, the
> client has *no* way to reason about retries or replay.
>
> A CDN is not a middlebox.  As far as the client is concerned a CDN *is*
> the origin.


No I don't think this works in transactional systems. For example; suppose
the client performs an update or write "through" the CDN, and 0-RTT is
being used on both sides. In the 0-RTT world, the CDN might be subject to
replay between the CDN and the Origin. But as defined, the actual client
gets no visibility of that. That breaks careful clients.  For example they
may get a 500 back and assume that the request failed, without knowing that
the request may be replayed any time in the next 10 seconds and therefore
succeed.

This can all be made workable though; with a careful consideration of how
the signaling propagates; that's not in the draft at this time though.


> > That's really very broken and a serious violation of the transport layer
> contract.
>
> Only if you believe CDN is a middlebox.  The transport layer contract is
> overridden by legal contracts or EULA :)
>

Of course, but I think this is a predictable security problem. The
implications are very subtle and may be exploited by attackers, while
people unknowingly enable the behavior. I realize I'm in dark corner cases
here; but I think we should approach all of this with the same rigor we
treat the TLS state machine and crypto proofs.
-- 
Colm

--001a11483b10ab0b85054f1ac8a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, May 9, 2017 at 9:41 AM, Salz, Rich <rsalz@akamai.com> wrote:
> It'=
s actually impossible because a 0RTT request may be retried as a 1RTT reque=
st and there's no way to correlate the two. So when the 1RTT request sh=
ows up, we can't go "This might be a repeat" - for example th=
e X- header trick doesn't work in this case. It's subtle, which mak=
es it even more likely to trip on it.=C2=A0



That also assumes that the 0RTT data will be a completely self-conta=
ined request.=C2=A0 I share the concern that Kyle and others have pointed o=
ut, that a single request will span the boundaries.
True; though I think the partial request case it's ok ... =
I think it's just orphaned data. The mechanisms that prevent 0-RTT inse=
rtion across different connections do seem robust.=C2=A0
=C2=A0

> I think the only approach that actually rigorously works is the client=
-side one



Attackers will not use well-behaved clients; does your approach stil=
l work?

Yes; it's about signaling t=
o the client that "Your data may or may not have been received". =
This is an ordinary failure mode for TCP and TLS and something many clients=
 have careful reasoning around. The difference with 0-RTT is now there'=
s a bigger window of time during which that request may get received, but t=
hat's it really. If the attacker replays, then it can be received; and =
the attacker can use any client, but it doesn't change the original wel=
l-behaved client's reasoning.=C2=A0


>The second problem is that middle-boxes can break any signaling. For ex=
ample a CDN or TLS accelerator may enable 0-RTT towards the back-end origin=
 without enabling it to the original client. In this model, the client has =
*no* way to reason about retries or replay.



A CDN is not a middlebox.=C2=A0 As far as the client is concerned a =
CDN *is* the origin.=C2=A0

No I don't t=
hink this works in transactional systems. For example; suppose the client p=
erforms an update or write "through" the CDN, and 0-RTT is being =
used on both sides. In the 0-RTT world, the CDN might be subject to replay =
between the CDN and the Origin. But as defined, the actual client gets no v=
isibility of that. That breaks careful clients.=C2=A0 For example they may =
get a 500 back and assume that the request failed, without knowing that the=
 request may be replayed any time in the next 10 seconds and therefore succ=
eed.=C2=A0

This can all be made workable though; w=
ith a careful consideration of how the signaling propagates; that's not=
 in the draft at this time though.=C2=A0
=C2=A0

> That's really very broken and a serious violation of the transport=
 layer contract.



Only if you believe CDN is a middlebox.=C2=A0 The transport layer co=
ntract is overridden by legal contracts or EULA :)
Of course, but I think this is a predictable security problem. =
The implications are very subtle and may be exploited by attackers, while p=
eople unknowingly enable the behavior. I realize I'm in dark corner cas=
es here; but I think we should approach all of this with the same rigor we =
treat the TLS state machine and crypto proofs.=C2=A0
-- 
Colm




--001a11483b10ab0b85054f1ac8a1--


From nobody Tue May  9 11:12:34 2017
Return-Path: 
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 5A661124D6C for ; Tue,  9 May 2017 11:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 SPiVn3ue33FJ for ; Tue,  9 May 2017 11:12:30 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF05127B57 for ; Tue,  9 May 2017 11:12:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 5D67821CE4; Tue,  9 May 2017 21:12:29 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id zzuWRHkeLW3o; Tue,  9 May 2017 21:12:29 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F21E0C4; Tue,  9 May 2017 21:12:28 +0300 (EEST)
Date: Tue, 9 May 2017 21:12:27 +0300
From: Ilari Liusvaara 
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= 
Cc: "Salz, Rich" , "tls@ietf.org" 
Message-ID: <20170509181227.GA9346@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>  <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 18:12:32 -0000

On Tue, May 09, 2017 at 10:35:37AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 9, 2017 at 9:41 AM, Salz, Rich  wrote:

> >The second problem is that middle-boxes can break any signaling. For
> > example a CDN or TLS accelerator may enable 0-RTT towards the back-end
> > origin without enabling it to the original client. In this model, the
> > client has *no* way to reason about retries or replay.
> >
> > A CDN is not a middlebox.  As far as the client is concerned a CDN *is*
> > the origin.
> 
> 
> No I don't think this works in transactional systems. For example; suppose
> the client performs an update or write "through" the CDN, and 0-RTT is
> being used on both sides. In the 0-RTT world, the CDN might be subject to
> replay between the CDN and the Origin. But as defined, the actual client
> gets no visibility of that. That breaks careful clients.  For example they
> may get a 500 back and assume that the request failed, without knowing that
> the request may be replayed any time in the next 10 seconds and therefore
> succeed.

Doesn't this imply that clients or CDN are using unsafe HTTP methods in
0-RTT data? Which is of course _seriously_ broken.

Because HTTP specification expressly forbids any and all updates and
writes using safe methods. Ignoring that causes very severe security
vulernabilities even today (e.g., causes essentially undefendable CSRF
attacks).



-Ilari


From nobody Tue May  9 11:44:18 2017
Return-Path: 
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 126B812EADE for ; Tue,  9 May 2017 11:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 bsIiqs4BRC-l for ; Tue,  9 May 2017 11:44:16 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9C2129534 for ; Tue,  9 May 2017 11:44:16 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id s22so2527740ybe.3 for ; Tue, 09 May 2017 11:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BY64HMOhaDCfQRYLsTiE8ZCLIIM1pxp+ObMVNtsYFtw=; b=mtOeSrfofh3bwdOMERBA3WX7CzF9ejTM83oBnai66z7o+UrlVLMkjp8HBAAoVEhagQ XYxaJlK72CtyRDDiZLYuyrRim5DoMQ/+vJvBNOZCOs1naLtGERow7pIrIrQiOy7CW81F +zPFxunP5pJl3i+iU4tC4wjZ2HKSn9QwXMxioFqVjBNiZhtwgu+QAGaY1Zleq4kHvDcJ Ma7S0AMtiiCD9SzWIgnEJOcH2Jk/hHOsAhJ1nROSQgdJ0+kw6jYiYEq4t65qgEcU7G13 x1tjAdvTBFcpMb5Pn+ho1H7/BehJe8pM/1CSwfYg28oZr0EJf8cU3OrVuleHJfb73haH j3ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BY64HMOhaDCfQRYLsTiE8ZCLIIM1pxp+ObMVNtsYFtw=; b=MvVn3G9ATLVQyaFBQdVJBXja/XnvnEbI6H0i063stOZLObUpl9v3KbKKV4sA4dKRj1 XsrCqynPd9WL3KRC9DwcZPicpM9Zoh3/06rRA3eGLOVxiVetrFtTuEhsunxREmN+tjqD 9Xu/wI5TkGdBmZHeFn2WsECQvkpA7lpbfNi/Kz2ox3YaDyAHYLGvDi4oIBfvS4S6/vyZ Nzb545TCOq++uufxY7ZwgsEUGg6L8KLeialpsEbomeYGXgcqMrc27FxQlXZL0kYu9aaL 5PAJf31xeXwbFMbrLLZxqnMu9N5MZDVPzQVSnT1Gji5IDm/aTk7YWJHvjnQsEeLJIuJH AmZA==
X-Gm-Message-State: AODbwcBQxsIcnDcLuw+f1RuaJ32CJKHksJ1CX18Vv/sZuhx3RM+ShJV+ znYpu1ZjoCj2tSfvwQ6XuO2XzlTfHg==
X-Received: by 10.37.198.147 with SMTP id k141mr1393434ybf.27.1494355455503; Tue, 09 May 2017 11:44:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Tue, 9 May 2017 11:44:14 -0700 (PDT)
In-Reply-To: <20170509181227.GA9346@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>  <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>  <20170509181227.GA9346@LK-Perkele-V2.elisa-laajakaista.fi>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Tue, 9 May 2017 11:44:14 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: "Salz, Rich" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c08c53c181f21054f1bbe25
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 18:44:18 -0000

--94eb2c08c53c181f21054f1bbe25
Content-Type: text/plain; charset=UTF-8

On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara 
wrote:
>
> Doesn't this imply that clients or CDN are using unsafe HTTP methods in
> 0-RTT data? Which is of course _seriously_ broken.
>

It doesn't really. First; the CDN may be acting as a Layer 4 TLS proxy.
Some CDNs sell these as SSL accelerators that work by moving the handshake
closer to clients and do almost nothing else. For example S3 Transfer
acceleration works like that:
http://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html .
In that case, the TLS proxy isn't necessarily even aware of the
under-lyling protocol. Will they be able to resist the easy-to-enable 0-RTT
time savings?

But secondly, in the real world, these can be GETs and that's how many APIs
are constructed. Why? because even though it ignores correct REST
principles, people can test and compose these operations more easily from
the command line (e.g. curl). We've all seen many APIs like this.

Because HTTP specification expressly forbids any and all updates and
> writes using safe methods. Ignoring that causes very severe security
> vulernabilities even today (e.g., causes essentially undefendable CSRF
> attacks).
>

These aren't browser requests, they can be SDK and other clients making
HTTP API requests. That's much more common too, by volume. CSRF isn't an
issue in cases like that.

I think everything I'm writing applies even for a careful REST-compliant
case too. Even if the client is using PUT or POST or DELETE or whatever,
the same kind of transactional semantics apply. All it takes is a
disconnect between the settings in any of the middle transport layers and
the expectations of the underlying protocol. I just think that disconnect
is very predictable.

-- 
Colm

--94eb2c08c53c181f21054f1bbe25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
Doesn't this imply that clients or CDN are using unsafe HTTP me=
thods in

0-RTT data? Which is of course _seriously_ broken.
It doesn't really. First; the CDN may be acting as a Layer =
4 TLS proxy. Some CDNs sell these as SSL accelerators that work by moving t=
he handshake closer to clients and do almost nothing else. For example S3 T=
ransfer acceleration works like that: http://docs.aws.amazon.com=
/AmazonS3/latest/dev/transfer-acceleration.html . In that case, the TLS=
 proxy isn't necessarily even aware of the under-lyling protocol. Will =
they be able to resist the easy-to-enable 0-RTT time savings?=C2=A0
=C2=A0
But secondly, in the real world, these can be GETs and =
that's how many APIs are constructed. Why? because even though it ignor=
es correct REST principles, people can test and compose these operations mo=
re easily from the command line (e.g. curl). We've all seen many APIs l=
ike this.=C2=A0


Because HTTP specification expressly forbids any and all updates and

writes using safe methods. Ignoring that causes very severe security

vulernabilities even today (e.g., causes essentially undefendable CSRF

attacks).

These aren't browser requ=
ests, they can be SDK and other clients making HTTP API requests. That'=
s much more common too, by volume. CSRF isn't an issue in cases like th=
at.=C2=A0

I think everything I'm writing appli=
es even for a careful REST-compliant case too. Even if the client is using =
PUT or POST or DELETE or whatever, the same kind of transactional semantics=
 apply. All it takes is a disconnect between the settings in any of the mid=
dle transport layers and the expectations of the underlying protocol. I jus=
t think that disconnect is very predictable.=C2=A0

-- 
Colm



--94eb2c08c53c181f21054f1bbe25--


From nobody Wed May 10 06:26:42 2017
Return-Path: 
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 C29E9129AC5 for ; Tue,  9 May 2017 23:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Tl3UQM3PdT-j for ; Tue,  9 May 2017 23:45:31 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A181129AC1 for ; Tue,  9 May 2017 23:45:31 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 66A00B81089; Tue,  9 May 2017 23:45:22 -0700 (PDT)
To: pwouters@redhat.com, Hannes.Tschofenig@gmx.net, gnu@toad.com, weiler@tislabs.com, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: x@example.net, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170510064522.66A00B81089@rfc-editor.org>
Date: Tue,  9 May 2017 23:45:22 -0700 (PDT)
Archived-At: 
X-Mailman-Approved-At: Wed, 10 May 2017 06:26:39 -0700
Subject: [TLS] [Technical Errata Reported] RFC7250 (5013)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 06:45:33 -0000

The following errata report has been submitted for RFC7250,
"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5013

--------------------------------------
Type: Technical
Reported by: i 

Section: 7

Original Text
-------------
   IANA has allocated two new TLS extensions, client_certificate_type
   and server_certificate_type, from the "TLS ExtensionType Values"
   subregistry defined in [RFC5246].

Corrected Text
--------------
   IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for
   client_certificate_type and server_certificate_type, respectively,
   in the "TLS ExtensionType Values" subregistry defined in [RFC5246].

Notes
-----


Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7250 (draft-ietf-tls-oob-pubkey-11)
--------------------------------------
Title               : Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Publication Date    : June 2014
Author(s)           : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Wed May 10 06:42:15 2017
Return-Path: 
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 B7AFC129463 for ; Wed, 10 May 2017 06:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 zvio_5dS8MY8 for ; Wed, 10 May 2017 06:42:10 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784F8129B35 for ; Wed, 10 May 2017 06:42:10 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id n4so29452529qte.2 for ; Wed, 10 May 2017 06:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4yeCo1e92HO9BlP2n7d8ttpWt5fQ84AsyuFovVwgJKc=; b=OU8wRQxhOAYe1e7hLaQsDrIQfpt4F2sVzn4I4Mlm0A27yZnTMWe6nq5Mvpsl1j1YAz nd2uWEfZ2E6Kozdg+yqIubfPDsqsgbOUHl8vqIbr/3ggrCq9CRlFlmhSYj3SgjofMJME Ld81FDmUyrdZK6uu9sWPavPoLmI732dVPlk8w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4yeCo1e92HO9BlP2n7d8ttpWt5fQ84AsyuFovVwgJKc=; b=tLx/LynrKPC53/vrNfgX8rcayRZgnLs8dpXxgfVrFSQUnGkhJ9Y3h7KUfVuqYcKmou +sq/1vokiX+Zy27UZ2LVht9yZCcgXaI+Uu/qsU8jdsUwmPSQdDvnbSgEySV818RyyHRD d5Xg+2CMpolNavnt1ckFP+pFn/SpyQV/YOk7zsDB4AlAkU7Sj7avuN0gRQEFnXLVkSZT PrrsL7Emji9LgSOsqw3EPjS3dZyPCjiNMNqEficLYamfkA6WLndtVc8vWe+sYE8M0bfC nYHkmh4JKfC87Rk1bMUbPYO3AJHNViL7qfIyVwT7CoWJWslHKsRjZvwUqyFEsGfD2Ss6 FIXw==
X-Gm-Message-State: AODbwcC0npDSzmysmfYhke9KScxRKbFCrOSkwR6YIBkNWwxgQs19Kfnj kju4rexHK0Zsbg==
X-Received: by 10.200.35.80 with SMTP id b16mr5315675qtb.205.1494423729484; Wed, 10 May 2017 06:42:09 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.219.90]) by smtp.gmail.com with ESMTPSA id j1sm2211046qkf.57.2017.05.10.06.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 06:42:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Turner 
In-Reply-To: <20170510064522.66A00B81089@rfc-editor.org>
Date: Wed, 10 May 2017 09:42:07 -0400
Cc: pwouters@redhat.com, Hannes Tschofenig , gnu@toad.com, Sam Weiller , Tero Kivinen , Kathleen Moriarty , Eric Rescorla , Joe Salowey 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2785CF1A-B5C8-42EA-8664-FBC5E17EBE79@sn3rd.com>
References: <20170510064522.66A00B81089@rfc-editor.org>
To: "" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] [Technical Errata Reported] RFC7250 (5013)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 13:42:14 -0000

I would definitively re-categorize this =E2=80=9Ceditorial=E2=80=9D; =
there=E2=80=99s no 2119-changes proposed and there=E2=80=99s no bits on =
the wire changes.  And, I=E2=80=99d either reject this one because =
technically the existing text is correct (i.e., they are two extensions) =
and this really ought not of caused an interoperability problem or mark =
it HFDU (hold for document update).  The new text does include the code =
points, but those can be obtained from the registry and don=E2=80=99t =
absolutely have to be included.

spt

> On May 10, 2017, at 02:45, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC7250,
> "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram =
Transport Layer Security (DTLS)".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5013
>=20
> --------------------------------------
> Type: Technical
> Reported by: i 
>=20
> Section: 7
>=20
> Original Text
> -------------
>   IANA has allocated two new TLS extensions, client_certificate_type
>   and server_certificate_type, from the "TLS ExtensionType Values"
>   subregistry defined in [RFC5246].
>=20
> Corrected Text
> --------------
>   IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for
>   client_certificate_type and server_certificate_type, respectively,
>   in the "TLS ExtensionType Values" subregistry defined in [RFC5246].
>=20
> Notes
> -----
>=20
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party =20
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC7250 (draft-ietf-tls-oob-pubkey-11)
> --------------------------------------
> Title               : Using Raw Public Keys in Transport Layer =
Security (TLS) and Datagram Transport Layer Security (DTLS)
> Publication Date    : June 2014
> Author(s)           : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, =
S. Weiler, T. Kivinen
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


From nobody Wed May 10 06:51:17 2017
Return-Path: 
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 0A865129B2F for ; Wed, 10 May 2017 06:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.102
X-Spam-Level: 
X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 MjA2QNZ1xjLX for ; Wed, 10 May 2017 06:51:13 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E59B12422F for ; Wed, 10 May 2017 06:51:13 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wNHhG1qfyz391; Wed, 10 May 2017 15:51:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1494424270; bh=euwdpAr2FU4Zam4o/DTNubHzIoG8G6zNX+UjxdS/KXY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KNBBPx3Kb0T+0gMVTxOoFvDquQYo3R2fBzklIEypbpC0NzHHQMGb1E122IONozc00 WYfvwikcMd+Nqgl3ZtKZ+WBHeoZYjwMJmd+71WUwbxp4F7/wDhTH1V/acFSTnW5d4B snF0FQNZGrypUUSHNLSnOLOodFXezJxcQet/R/cg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id R_zY6O3vwoK8; Wed, 10 May 2017 15:51:07 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 10 May 2017 15:51:06 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id EAC964080D7; Wed, 10 May 2017 09:51:05 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EAC964080D7
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D46FC4129B53; Wed, 10 May 2017 09:51:05 -0400 (EDT)
Date: Wed, 10 May 2017 09:51:05 -0400 (EDT)
From: Paul Wouters 
To: Sean Turner 
cc: "" , Sam Weiller ,  John Gilmore , Tero Kivinen ,  Paul Wouters 
In-Reply-To: <2785CF1A-B5C8-42EA-8664-FBC5E17EBE79@sn3rd.com>
Message-ID: 
References: <20170510064522.66A00B81089@rfc-editor.org> <2785CF1A-B5C8-42EA-8664-FBC5E17EBE79@sn3rd.com>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: 
Subject: Re: [TLS] [Technical Errata Reported] RFC7250 (5013)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 13:51:16 -0000

On Wed, 10 May 2017, Sean Turner wrote:

> I would definitively re-categorize this “editorialâ€; there’s no 2119-changes proposed and there’s no bits on the wire changes.  And, I’d either reject this one because technically the existing text is correct (i.e., they are two extensions) and this really ought not of caused an interoperability problem or mark it HFDU (hold for document update).  The new text does include the code points, but those can be obtained from the registry and don’t absolutely have to be included.

Sounds right to me.

Paul


From nobody Wed May 10 08:21:30 2017
Return-Path: 
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 B0B3B129465 for ; Wed, 10 May 2017 08:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.58
X-Spam-Level: 
X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 vjs7ai12DXHX for ; Wed, 10 May 2017 08:21:27 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [217.160.92.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FED127698 for ; Wed, 10 May 2017 08:21:27 -0700 (PDT)
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 9FF2ADA7 for ; Wed, 10 May 2017 16:21:25 +0100 (BST)
Received: by mail-it0-f41.google.com with SMTP id g126so3473507ith.0 for ; Wed, 10 May 2017 08:21:25 -0700 (PDT)
X-Gm-Message-State: AODbwcCk2SwD9+iLM/FstcqoccnWcO7Zv/I1etks0AAE3B9B8LPfT4sk QoZNaD2+vYInzzccqTfNgoKlmv2HYA==
X-Received: by 10.36.0.23 with SMTP id 23mr5885935ita.108.1494429683998; Wed, 10 May 2017 08:21:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.127.79 with HTTP; Wed, 10 May 2017 08:21:23 -0700 (PDT)
From: Matt Caswell 
Date: Wed, 10 May 2017 16:21:23 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] Alerts
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 15:21:28 -0000

Draft-20 currently contains this text in the section "Server
Certificate Selection":

'If the client cannot construct an acceptable chain using the provided
certificates and decides to abort the handshake, then it MUST abort
the handshake with an"unsupported_certificate" alert."'

However, section 6 lists a number of other generic certificate related alerts:
certificate_revoked
certificate_expired
certificate_unknown
unknown_ca

While section 6 provides descriptions of these they are not mentioned
elsewhere in the spec, so there is no guidance as to when they might
be used.

So, given the text in the "Server Certificate Selection" section,
should a client always send "unsupported_certificate" for all
failures? Or should one of the other alerts be used instead if it
seems more appropriate? E.g. If a client attempts to "construct an
acceptable chain", but finds an expired certificate - should it
respond with "unsupported_certificate" or "certificate_expired"?

There seems to be some inconsistency between server certificate
selection and client certificate selection, i.e. in the former it is
mandated that a specific alert be sent, but in the latter there is no
such requirement.

Additionally, there are a number of other alerts mentioned in section
6 (not just certificate related ones), that are never mentioned
anywhere else in the spec. Do we really need all of these alerts? If
they are needed, shouldn't they be explicitly mentioned elsewhere in
the spec in the locations where they are relevant (associated with
some MUST/SHOULD/MAY requirement)? As things stand the interpretation
of when they should be sent seems quite loose.

Matt


From nobody Wed May 10 10:29:03 2017
Return-Path: 
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 A144C129461 for ; Wed, 10 May 2017 10:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ibEJcOnpntF5 for ; Wed, 10 May 2017 10:29:00 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC3212420B for ; Wed, 10 May 2017 10:29:00 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA75063142 for ; Wed, 10 May 2017 17:28:59 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DA75063142
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DA75063142
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A75CE17962 for ; Wed, 10 May 2017 17:28:59 +0000 (UTC)
From: Hubert Kario 
To: "tls@ietf.org" 
Date: Wed, 10 May 2017 19:28:51 +0200
Message-ID: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2545833.bSing3hz15"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 10 May 2017 17:29:00 +0000 (UTC)
Archived-At: 
Subject: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 17:29:02 -0000

--nextPart2545833.bSing3hz15
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make=
=20
sure that the client and server agree on the host that the client wants to=
=20
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending=
=20
the salt and the resulting hash, making the server calculate the same hash=
=20
with each of the virtual host names it supports and comparing with the clie=
nt=20
provided value?

(apologies if that was already proposed and rejected)
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart2545833.bSing3hz15
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZE03TAAoJEJKo0bgB0vX1BSYQAIf80DghwBgrXTKYTdH+yHcI
lH5R4/lPUvjia9JRiDZtB3IAU8WPTEiqeSbcVS8d8mwsjnJNsc5paYJqzAXsj1vn
pi+4dXsqQYTRqWUkpVZRUBbSdabLgG4lAuDjbDlEwvxuAvLG0WfUPnKyNJ50MnVL
T6gidut2yQGPTBw8YityzWGsILyopJtf/aa8iRE8sF24xu6/r9Um/+T8Rnwoh/3f
5zICdpCMPXp3pvja3Q8Ra5vI5DuhaGmnpZW19j3dMfu98CXY8pGmoRsIaWMIRQq/
bLfAsQDYrWO3zsRBVPMKiJhv4b+Dwfz210n35P4ashN6Fo9ct6Tkl7Gwn1lneSU5
qXlAAHGOR/i5WSO6Dyplqe+CwjHgkud9Z8l/6agOnEDgLiih2hSuhGbgvceCoDr1
uq2coLY3ALJUbjf2MULTrs3q4A41Z5Ukwee//SO47UPe8M3WMa8EBIONLrjPx7NA
f/HTa3PGtPQTMEcKKDILmB7Xl9vQdssRVaz7y+q2cwfrJIW7inzvIa47htqDneBe
PoYHjfZC2wq6TpbnTz4YUBN/uyoIw/zZwKcnu+4+MQK5A5CLZhuFp6eetKGDfQBE
JCYfRvEMlZmr7FtgLs1BbgDUegSZhVTR/W4CiuOwC9q2wLG+FvY8tqrDJylR50PO
l1BEPHEifrzk/ZXdl4vG
=yosH
-----END PGP SIGNATURE-----

--nextPart2545833.bSing3hz15--


From nobody Wed May 10 11:25:28 2017
Return-Path: 
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 1F42D129C37 for ; Wed, 10 May 2017 11:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 0mv8ytIDrLbJ for ; Wed, 10 May 2017 11:25:24 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DD7129536 for ; Wed, 10 May 2017 11:25:24 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DA7647A32F1 for ; Wed, 10 May 2017 18:25:23 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
Date: Wed, 10 May 2017 14:25:22 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 18:25:26 -0000

> On May 10, 2017, at 1:28 PM, Hubert Kario  wrote:
>=20
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, =
sending=20
> the salt and the resulting hash, making the server calculate the same =
hash=20
> with each of the virtual host names it supports and comparing with the =
client=20
> provided value?
>=20
> (apologies if that was already proposed and rejected)

There in many cases way too many virtual host names for the server to =
test.

On the other hand, the attacker with fast hashing silicon can perform =
the
same computation very quickly.  The virtual hosts supported by the =
remote
server are likely not much a secret in most cases.

--=20
	Viktor.


From nobody Wed May 10 11:47:19 2017
Return-Path: 
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 BB0CB12E858 for ; Wed, 10 May 2017 11:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ZJFWN8UStRMh for ; Wed, 10 May 2017 11:47:16 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EE312951F for ; Wed, 10 May 2017 11:47:16 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 963F4448D69; Wed, 10 May 2017 18:47:15 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 963F4448D69
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 963F4448D69
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E0761710A; Wed, 10 May 2017 18:47:15 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 10 May 2017 20:47:13 +0200
Message-ID: <2478514.aZun5FUmZT@pintsize.usersys.redhat.com>
In-Reply-To: <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2010235.3A1IW0gdv3"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 10 May 2017 18:47:15 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 18:47:18 -0000

--nextPart2010235.3A1IW0gdv3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 1:28 PM, Hubert Kario  wrote:
> >=20
> > Couldn't we "encrypt" the SNI by hashing the host name with a salt,
> > sending
> > the salt and the resulting hash, making the server calculate the same h=
ash
> > with each of the virtual host names it supports and comparing with the
> > client provided value?
> >=20
> > (apologies if that was already proposed and rejected)
>=20
> There in many cases way too many virtual host names for the server to tes=
t.

if you have tens of thousands of websites you either have a farm of servers=
,=20
so you can solve that with sharding, or the websites don't get much traffic=
 so=20
it's not a performance problem

> On the other hand, the attacker with fast hashing silicon can perform the
> same computation very quickly.

But it does make simple keyword matching on hostname much harder or=20
impossible.

>  The virtual hosts supported by the remote
> server are likely not much a secret in most cases.

that's argument for not spending too much resources on the encryption/
obfuscation, not that we shouldn't do it.


But in general, I wonder if we didn't approach the SNI from the wrong side =
=2D=20
as I said, we may not need to encrypt it, we just make sure that client and=
=20
server agree on the virtual host the connection is going to.
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart2010235.3A1IW0gdv3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZE2AxAAoJEJKo0bgB0vX1rnYP/2aQdXlJhJOI7NlaXwLW5JO2
iyIDIHTQS2u6WKp89PuIAoQR6LSs7wy3LG/9auLmLakjRHmUDfMvzYOJikFY4Tpy
HwbJ3lW895T+708qosfORsdWaDNA4N4xGnjqaVv7qc7s6DOLBPJ46LomoGocwVBc
P7k/jyx4YxteeyzzWbGJ3CrS+RaGhU38ArMLlgOduYApXjK9XiLCuP07mYDAFEQk
WlOrNjuSbcpbC6KuZAcxbVNXaPbOgM03PcrtSnORexSQVo+zk7UkFN/KVYInTmPO
t5MOtFRaeWSfIMdVs6QhmuO+kNCu6jmb96oijERWRSdqdBWV/NA5VLnKeHv3ONBO
YvpPd/vQrnIVESaPqrCwg/E0kttCOvVWYxXdk7SqNyr5duOWhHuWygSPqLgDUmHJ
iSBJ07Of1nY0vAxBrPbSoG2+IhpliTmuSm3P1EwcdqmNLAFSCCAol4FWkgDwj6iC
7btrhrhEj821+x2aNFqHcd9/lCFu1+N5Oc91SPQoFOkzopXHeJXBi4+LD7i/a1c9
wB77vhFKUcnUYMOnWVuhfmlxMV4rJz3//0AVsdkZ9F3T5bEkDtT9F5hOLPTCbAJt
mExpyKjSfNx4vDfSg0HyfRrwv4+4xT347K5arw90Os3+8srEoz4LDihHUbDSVZog
ghwMdyLb3N43hmsNDuqi
=c50E
-----END PGP SIGNATURE-----

--nextPart2010235.3A1IW0gdv3--


From nobody Wed May 10 12:04:57 2017
Return-Path: 
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 26BC3126C23 for ; Wed, 10 May 2017 12:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 W3TJrckPISTZ for ; Wed, 10 May 2017 12:04:55 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BC91267BB for ; Wed, 10 May 2017 12:04:54 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1314A7A32F1 for ; Wed, 10 May 2017 19:04:54 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <2478514.aZun5FUmZT@pintsize.usersys.redhat.com>
Date: Wed, 10 May 2017 15:04:53 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 19:04:56 -0000

> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>=20
> But in general, I wonder if we didn't approach the SNI from the wrong =
side -=20
> as I said, we may not need to encrypt it, we just make sure that =
client and=20
> server agree on the virtual host the connection is going to.

They can do that with a name in the clear.  If the name is to be hidden
from passive observers, then you do need encryption so that only the
client and server, and not the passive observers, can recover the name.

Encryption means key agreement, and requires delaying SNI by a =
round-trip,
or having published DH shares in DNS, which of course also needs privacy
protection for SNI encryption to matter.

I do believe this was discussed at some length previously.

--=20
--=20
	Viktor.


From nobody Wed May 10 12:09:35 2017
Return-Path: 
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 8D927128768 for ; Wed, 10 May 2017 12:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 fzx4vjat6Tbm for ; Wed, 10 May 2017 12:09:33 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D933D126C23 for ; Wed, 10 May 2017 12:09:32 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4AJ7IVj004367 for ; Wed, 10 May 2017 20:09:30 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=tVhccfgMRUGbb0jJN2oLdcL0pgAwXvdrQNio0uj0fso=; b=An/rKvemkv2uIiTB2LYD1LOZcQK9magx/4yXaHE9njWvLBJDu7a5sVD5WR+bdLnnQKo4 9WkPByoxwlVxq8YJhE+4bA1o+8pfofOrts8jeEw0gCzEk98hOytWecJc3ybHOk0Wx3nu zW0TJJVuAdcxeceeDbrtTsn9IyS/lcoAaXctqH/e26IfoFoCk3fwWJ0B7Nfg2/UhwsME VkYmuWd/jjIJbx1eu3eSD9dCHhM8Cmzm6xo1hu1dQPC3rs7nDogDPtJ2otbBtwZvIejc KxuTIAJM2C2op256y7lBVh1bzufNWfZZkpeWgh5a3WlZs/HnymgjJRW924thhqznqdJQ Bg== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2absa14sty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 May 2017 20:09:30 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4AJ6NVe030547 for ; Wed, 10 May 2017 15:09:30 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a99tufy7x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 10 May 2017 15:09:30 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 15:09:29 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 10 May 2017 15:09:29 -0400
From: "Salz, Rich" 
To: TLS WG 
Thread-Topic: [TLS] "Encrypted" SNI
Thread-Index: AQHSybLvEhuV4X1WPk6Zn8r+xi6goaHuJToAgAAGG4CAAATvgP//ve5Q
Date: Wed, 10 May 2017 19:09:28 +0000
Message-ID: 
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
In-Reply-To: <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.197]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100130
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100130
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 19:09:34 -0000

> Encryption means key agreement, and requires delaying SNI by a round-trip=
,
> or having published DH shares in DNS, which of course also needs privacy
> protection for SNI encryption to matter.

With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible.=
 =20

A am long overdue for a writeup on this.


From nobody Wed May 10 12:12:44 2017
Return-Path: 
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 E279912762F for ; Wed, 10 May 2017 12:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 4kA5sh6oj1dq for ; Wed, 10 May 2017 12:12:41 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53660126B6D for ; Wed, 10 May 2017 12:12:41 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d8X2N-0006rl-I6 for tls@ietf.org; Wed, 10 May 2017 21:12:40 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d8X2L-00035d-Hg for tls@ietf.org; Wed, 10 May 2017 15:12:38 -0400
Received: (qmail 22614 invoked from network); 10 May 2017 19:12:35 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 May 2017 19:12:35 -0000
To: tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
From: Christian Huitema 
Message-ID: 
Date: Wed, 10 May 2017 12:12:34 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.232
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49I98TYJ6ZsqWtR/HDmWTg9dTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqstSUqOv19ssXzGimea9RjRcOb18WfxGyg6Om6u4YYm8U8PJYfwDzxUsvn W7IGAt05hjoyEb9Oq0NWpyO3vrfYJa7GnXDffeBY//TcvM3Flj3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBqW+JovcC0XtHTtanzqbG/HTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0RIi70Zj/ IY8QKxHw+AcBk7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg/BLRpUPYqBUd+r v2LSTGakKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAzeBJotfmDEuf371A4KffGQaso9iv7kZ9azJt3DY/E7nm
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 19:12:43 -0000

On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>>
>> But in general, I wonder if we didn't approach the SNI from the wrong =
side -=20
>> as I said, we may not need to encrypt it, we just make sure that clien=
t and=20
>> server agree on the virtual host the connection is going to.
> They can do that with a name in the clear.  If the name is to be hidden=

> from passive observers, then you do need encryption so that only the
> client and server, and not the passive observers, can recover the name.=

>
> Encryption means key agreement, and requires delaying SNI by a round-tr=
ip,
> or having published DH shares in DNS, which of course also needs privac=
y
> protection for SNI encryption to matter.
>
> I do believe this was discussed at some length previously.
It certainly was. But then the clear text SNI is a gaping privacy hole
in TLS, the kind of issue that should keep us awake at night until it is
resolved. We need to make sure that we make progress, rather than rehash
the old arguments. Maybe we should invest some time and document the
various proposals in a draft. I am willing to work on that. Any other
volunteers?

-- Christian Huitema


From nobody Wed May 10 12:15:24 2017
Return-Path: 
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 0DB3112EA59 for ; Wed, 10 May 2017 12:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Hx-CZ61-lbIh for ; Wed, 10 May 2017 12:15:04 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id CFFE112EA74 for ; Wed, 10 May 2017 12:15:03 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 861ED200041; Wed, 10 May 2017 19:15:03 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 66AD7200014; Wed, 10 May 2017 19:15:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494443703; bh=EDBAKLIRl+cTq50pa2dKz98glpwOW4WT+olWCVzS88M=; l=4151; h=To:References:From:Date:In-Reply-To:From; b=YvqqHKkj1Y/CMiyJNoYBzwe0kmgEmmS165rg9pj7dLtln8+hbCavWnRmxqsn7AcvN rydTQBNIBlhLBHdC9ARsWygDOS8N79h0PoW1rmN4mmIefM98VmBmZ1Qw/OWpdBhL5E Fu+psm4K0DhwVpBWLnQ6CqNCtI0LoNKWp80lSTLA=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 1951B98084; Wed, 10 May 2017 19:15:03 +0000 (GMT)
To: Christian Huitema , tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org> 
From: Benjamin Kaduk 
Message-ID: <326d4637-cb99-4892-4c82-ce5d52b0b4a0@akamai.com>
Date: Wed, 10 May 2017 14:15:01 -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: 
Content-Type: multipart/alternative; boundary="------------0B2B124A08EC47BD92585162"
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 19:15:05 -0000

This is a multi-part message in MIME format.
--------------0B2B124A08EC47BD92585162
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/10/2017 02:12 PM, Christian Huitema wrote:
>
> On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>>> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>>>
>>> But in general, I wonder if we didn't approach the SNI from the wrong side - 
>>> as I said, we may not need to encrypt it, we just make sure that client and 
>>> server agree on the virtual host the connection is going to.
>> They can do that with a name in the clear.  If the name is to be hidden
>> from passive observers, then you do need encryption so that only the
>> client and server, and not the passive observers, can recover the name.
>>
>> Encryption means key agreement, and requires delaying SNI by a round-trip,
>> or having published DH shares in DNS, which of course also needs privacy
>> protection for SNI encryption to matter.
>>
>> I do believe this was discussed at some length previously.
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?
>

It seems like there are a number of ways to encrypt the SNI for the
*second* (and subsequent) exchange with a given server; I have one that
I have some notes on and might try to write up.  But do we think that's
worth doing, or do we want to also provide protection for the initial
contact?  It seems like there is a qualitative difference, there...

-Ben

--------------0B2B124A08EC47BD92585162
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/10/2017 02:12 PM, Christian Huitema wrote:

    

      

On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:


      

        

          
On May 10, 2017, at 2:47 PM, Hubert Kario <hkario@redhat.com> wrote:

But in general, I wonder if we didn't approach the SNI from the wrong side - 
as I said, we may not need to encrypt it, we just make sure that client and 
server agree on the virtual host the connection is going to.


        

        
They can do that with a name in the clear.  If the name is to be hidden
from passive observers, then you do need encryption so that only the
client and server, and not the passive observers, can recover the name.

Encryption means key agreement, and requires delaying SNI by a round-trip,
or having published DH shares in DNS, which of course also needs privacy
protection for SNI encryption to matter.

I do believe this was discussed at some length previously.


      

      
It certainly was. But then the clear text SNI is a gaping privacy hole
in TLS, the kind of issue that should keep us awake at night until it is
resolved. We need to make sure that we make progress, rather than rehash
the old arguments. Maybe we should invest some time and document the
various proposals in a draft. I am willing to work on that. Any other
volunteers?



    

    

    It seems like there are a number of ways to encrypt the SNI for the
    *second* (and subsequent) exchange with a given server; I have one
    that I have some notes on and might try to write up.  But do we
    think that's worth doing, or do we want to also provide protection
    for the initial contact?  It seems like there is a qualitative
    difference, there...

    

    -Ben

  


--------------0B2B124A08EC47BD92585162--


From nobody Wed May 10 12:28:55 2017
Return-Path: 
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 2BC0F12E034 for ; Wed, 10 May 2017 12:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 PR6t3kGbA-ZI for ; Wed, 10 May 2017 12:28:51 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 116681274D0 for ; Wed, 10 May 2017 12:28:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 9967B21C96; Wed, 10 May 2017 22:28:49 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id gsmsJwWg84E6; Wed, 10 May 2017 22:28:49 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6F15B27F; Wed, 10 May 2017 22:28:49 +0300 (EEST)
Date: Wed, 10 May 2017 22:28:48 +0300
From: Ilari Liusvaara 
To: Hubert Kario 
Cc: "tls@ietf.org" 
Message-ID: <20170510192848.GA11915@LK-Perkele-V2.elisa-laajakaista.fi>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 19:28:53 -0000

On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> Yes, encrypted SNI was discussed and ultimately rejected.
> 
> But do we really have to send the literal value? Don't we need to just make 
> sure that the client and server agree on the host that the client wants to 
> connect?
> 
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
> the salt and the resulting hash, making the server calculate the same hash 
> with each of the virtual host names it supports and comparing with the client 
> provided value?

What makes encrypting SNI nasty is replay attacks.

There also was proposal for putting SNI mapping into DNS (which limits the
leakage if DNS lookups are private). However, I came up with a way to use
that to attack HTTPS (the usual "default vhost" attacks).


-Ilari


From nobody Wed May 10 13:51:58 2017
Return-Path: 
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 874FD12EAB8 for ; Wed, 10 May 2017 13:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vnT_TgSmXxes for ; Wed, 10 May 2017 13:51:56 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FFF129C0B for ; Wed, 10 May 2017 13:51:56 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id w50so5829444wrc.0 for ; Wed, 10 May 2017 13:51:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fr9hkLgnOgIPih9ODqM+NTfYEORcIpdF6R4GVV4xUVk=; b=tqwP+qXtWtUt0WB9m5EPOiclqgmg+0N9PV34QlksolpWJEgR+jwL0zFynfqWvYTiZl /Klwm4RDIFVAyi3aeJSUGlcfn+GBguRkA8bi4yaEl0L+UWQCMhsuVw2W86wtm+bAaYRU G6x/YVFuas9fuSsm+wCZQjBnhiEKGzqL+8tbVVdnofR/gIPSw7Q4hSBZfO1i5rFcfm/+ OR+/zjK2ZLmsLqHY5G8Vv4ED7yCqgx7wL8D7Mt4fFPNjuRuI0gd23yFGGATk9AiDcJ8Z mM8JR8o+F1j62lGapMRQYq2Nbq2qTCC9Fy19xPmCi9YWrv7E2ogJN4KFgDNwu5CNIkBW QOjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fr9hkLgnOgIPih9ODqM+NTfYEORcIpdF6R4GVV4xUVk=; b=PnvkULzeiwdlGGjpeXka3nKPH87kgt9JbVQCrcTfEe8NJkQT1LYwWKj3OrwjiEgMPX dS4tzanhXo/Czd8OrZYhmkQYvca2RY/OSKX/8zrmo8RCr63TbqOHppbd0FIHnuSrwrvp jrEWJlzIjn9W52ISS3Vba3WD+HnrURikU4jWYZdWycH2u20jIOLN34aSFFWElk21K2Zo NwF8FWCyc7Dlp0PfXyIPX7FZWFEAQ70BfBN28ME/lzdZLwZ/fmxfZDP9TANpso9ajfSz Ya2zjUA/0twrhJZL5tyPuPwAyNQmrkb0/aUoSgTzVNhoA0msfRo/tkbYrIY6+8WLtEv1 5x2w==
X-Gm-Message-State: AODbwcDND9hBEhPG54PDkQX9EgwyiFC0alq9yDhyaB3vjZRK3g1bit5A +J9JNkvEBMQsEtw8KLfrbpm1DPEW79GA
X-Received: by 10.46.8.26 with SMTP id 26mr3503650lji.128.1494449514537; Wed, 10 May 2017 13:51:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Wed, 10 May 2017 13:51:53 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Thu, 11 May 2017 06:51:53 +1000
Message-ID: 
To: Matt Caswell 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [TLS] Alerts
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 20:51:57 -0000

On 11 May 2017 at 01:21, Matt Caswell  wrote:
> Do we really need all of these alerts?

NSS uses these, but in ways that I don't really understand.  I think
that this is part of the general issue that TLS does and doesn't
really include requirements about how to handle the certificate chain.


From nobody Wed May 10 14:40:21 2017
Return-Path: 
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 0452C1294AB for ; Wed, 10 May 2017 14:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 nXsmxvnXal_a for ; Wed, 10 May 2017 14:40:18 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B25C128DF3 for ; Wed, 10 May 2017 14:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494452416; l=3533; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=l0kUKntxWwDXkkAsjuFGtqnwTM8eAxq4tkOQrgZUJkE=; b=W3DhWT4Tdz7USPPm1Juy5itkFbsWlWH8VRpUp88NFlQybyxZLWNf/4dqJtbNFAiZRv ioUT6M8bQiYJnU/Y5F9eFulkqWzAohZypTBtzPpD4dyfGYIHPQNgsUCoqvdX/4We3l/t 1SQ1uCt8RGE/Je32cFKM/3C3fi1po08GWwNgw=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIweUns/Oqm8M2XeLgRv9qu3DB7g==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:9c05:2dc6:bb3c:d4e3] ([2001:4dd0:ff67:0:9c05:2dc6:bb3c:d4e3]) by smtp.strato.de (RZmta 40.6 AUTH) with ESMTPSA id 608061t4ALeFUvU (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 10 May 2017 23:40:15 +0200 (CEST)
To: tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
From: Roland Zink 
Message-ID: 
Date: Wed, 10 May 2017 23:40:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------2FE4FA50E007C1BDCD8DF731"
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 21:40:21 -0000

This is a multi-part message in MIME format.
--------------2FE4FA50E007C1BDCD8DF731
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

The SNI extension is optional, so you don't have to send the literal 
value. Indeed quite some number of apps do not send it. Browsers 
currently can't know if the SNI is required by the origin servers and 
usually send this, but there could be some signal to not send it. One 
example could be a HTTP header to tell the browser that SNI should be 
send and if it isn't present then no SNI is send. Unfortunately this 
would break current sites but still it can be done the other way around 
e.g. send a header to not send SNI.

Regards,

Roland


Am 10.05.2017 um 19:28 schrieb Hubert Kario:
> Yes, encrypted SNI was discussed and ultimately rejected.
>
> But do we really have to send the literal value? Don't we need to just make
> sure that the client and server agree on the host that the client wants to
> connect?
>
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
> the salt and the resulting hash, making the server calculate the same hash
> with each of the virtual host names it supports and comparing with the client
> provided value?
>
> (apologies if that was already proposed and rejected)
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------2FE4FA50E007C1BDCD8DF731
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
The SNI extension is optional, so you don't have to send the
      literal value. Indeed quite some number of apps do not send it.
      Browsers currently can't know if the SNI is required by the origin
      servers and usually send this, but there could be some signal to
      not send it. One example could be a HTTP header to tell the
      browser that SNI should be send and if it isn't present then no
      SNI is send. Unfortunately this would break current sites but
      still it can be done the other way around e.g. send a header to
      not send SNI.

    
Regards,

    
Roland

    


    

    
Am 10.05.2017 um 19:28 schrieb Hubert
      Kario:

    

    

      
Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make 
sure that the client and server agree on the host that the client wants to 
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
the salt and the resulting hash, making the server calculate the same hash 
with each of the virtual host names it supports and comparing with the client 
provided value?

(apologies if that was already proposed and rejected)


      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------2FE4FA50E007C1BDCD8DF731--


From nobody Wed May 10 14:51:07 2017
Return-Path: 
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 EAE631292CE for ; Wed, 10 May 2017 14:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 R92tBTsef5E7 for ; Wed, 10 May 2017 14:51:05 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA4E1292C5 for ; Wed, 10 May 2017 14:51:05 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d8ZVe-0006Ye-Ol for tls@ietf.org; Wed, 10 May 2017 23:51:03 +0200
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d8ZVZ-0006vf-Iw for tls@ietf.org; Wed, 10 May 2017 17:50:58 -0400
Received: (qmail 17763 invoked from network); 10 May 2017 21:50:51 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 May 2017 21:50:51 -0000
To: Roland Zink , tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> 
From: Christian Huitema 
Message-ID: <1be2b15e-2e96-89f4-fe72-7f35a03ae99b@huitema.net>
Date: Wed, 10 May 2017 14:50:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.190
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpsm1bsvpS6/5av0CXYg4TrRcOb18WfxGyg6Om6u4YYm4Rd89++QihjXUN6 t2+7VS45hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpF3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0TQjVng+I 4j5NH+PNTw0CHLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa67s2SuN2OBHS35xAp92lJI/So36ili1tgrL sQ8JMBxgxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 21:51:07 -0000

On 5/10/2017 2:40 PM, Roland Zink wrote:
> The SNI extension is optional, so you don't have to send the literal
> value. Indeed quite some number of apps do not send it. Browsers
> currently can't know if the SNI is required by the origin servers and
> usually send this, but there could be some signal to not send it. One
> example could be a HTTP header to tell the browser that SNI should be
> send and if it isn't present then no SNI is send. Unfortunately this
> would break current sites but still it can be done the other way
> around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema


From nobody Wed May 10 15:03:27 2017
Return-Path: 
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 06A0E129A90 for ; Wed, 10 May 2017 15:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 TAcwq4Kc9DQI for ; Wed, 10 May 2017 15:03:23 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705BF1292C5 for ; Wed, 10 May 2017 15:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494453801; l=1141; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=sOBo4JVp20HIk0j3i7vnAy/aYhj5e/Ztb7JVpCyntxk=; b=fZDtCOIU0kQTRcyUrKS7vWa/gDi40js3OEBtkSANZ+FooXjXx5bD12RxK40hVaVlI9 lrMqFU/NF1YJ+tHm9ZiFZ2dmDKkHk9/pQwfg0t4xl8s2ICElNHmia/3TCn5WlSywPMk5 WQQfa2Biq3wn+2SeItmfW/noubLCCipizV8XI=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIweUns/Oqm8M2XeLgRv9qu3DB7g==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:9c05:2dc6:bb3c:d4e3] ([2001:4dd0:ff67:0:9c05:2dc6:bb3c:d4e3]) by smtp.strato.de (RZmta 40.6 AUTH) with ESMTPSA id 90a140t4AM3EVMz (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 11 May 2017 00:03:14 +0200 (CEST)
To: Christian Huitema , tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>  <1be2b15e-2e96-89f4-fe72-7f35a03ae99b@huitema.net>
From: Roland Zink 
Message-ID: <95423440-7d9a-6568-0e80-e58e3e27a373@zinks.de>
Date: Thu, 11 May 2017 00:03:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1be2b15e-2e96-89f4-fe72-7f35a03ae99b@huitema.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 22:03:25 -0000

Not necessarily as you may for example use the path part of a URL to 
distinguish between services.


Roland




Am 10.05.2017 um 23:50 schrieb Christian Huitema:
>
> On 5/10/2017 2:40 PM, Roland Zink wrote:
>> The SNI extension is optional, so you don't have to send the literal
>> value. Indeed quite some number of apps do not send it. Browsers
>> currently can't know if the SNI is required by the origin servers and
>> usually send this, but there could be some signal to not send it. One
>> example could be a HTTP header to tell the browser that SNI should be
>> send and if it isn't present then no SNI is send. Unfortunately this
>> would break current sites but still it can be done the other way
>> around e.g. send a header to not send SNI.
> Yes. But this is only possible when each service has a separate IP
> address. The privacy gain occurs precisely when several services share
> the same address, but that's exactly when the SNI is required. If the
> SNI was somehow encrypted, adversaries would not be able to use it to
> find which service the user is connecting to.
>
> -- Christian Huitema
>


From nobody Wed May 10 19:02:41 2017
Return-Path: 
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 23F0A126BF0 for ; Wed, 10 May 2017 19:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.591
X-Spam-Level: *
X-Spam-Status: No, score=1.591 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592] autolearn=no 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 OmS2LmMDN_Nq for ; Wed, 10 May 2017 19:02:38 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4464D129329 for ; Wed, 10 May 2017 19:02:38 -0700 (PDT)
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id B078FF993; Wed, 10 May 2017 22:02:37 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id CD21820F79; Wed, 10 May 2017 16:24:05 -0400 (EDT)
From: Daniel Kahn Gillmor 
To: Christian Huitema , tls@ietf.org
In-Reply-To: 
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org> 
Date: Wed, 10 May 2017 16:24:05 -0400
Message-ID: <87ziekihp6.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 02:02:39 -0000

On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?

I agree with Christian's assessment of the problem, and i'd be
interested in collaborating on such a draft.

The DNS folks are making strides to protect name information (the other
main place where this kind of data is leaking).  TLS needs to keep up.

    --dkg


From nobody Wed May 10 22:00:22 2017
Return-Path: 
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 3C5A412945E for ; Wed, 10 May 2017 22:00:21 -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 CkcEnZfu_bOJ for ; Wed, 10 May 2017 22:00:19 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BE1AF126BF6 for ; Wed, 10 May 2017 22:00:18 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C57C743341D; Thu, 11 May 2017 05:00:17 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A49D2433404; Thu, 11 May 2017 05:00:17 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494478817; bh=HRNPBKul+yjifRzdQYgnXaODVSmBYJI0Lx/sFhQMwSg=; l=28703; h=From:To:References:Date:In-Reply-To:From; b=VIe5uo/CDf8e1d2kfAyDUhTIympefFdMXCjjutEZwJ7jMZ4tUZG9WGpTgWUpyfj+W hqDhgaA+AHp3dEEfFr0yRiJE5Zz/0AhqJKRCH0tw9FpFJC9foi6MMvg80pjwWZxPeb 9uJj72ESIcnBSHXYDbmooB2WJWBxYROpykfcmtRo=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 61F2D1FC03; Thu, 11 May 2017 05:00:17 +0000 (GMT)
From: Benjamin Kaduk 
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , "tls@ietf.org" 
References: 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Thu, 11 May 2017 00:00:17 -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: 
Content-Type: multipart/alternative; boundary="------------A8688FCAE9DFBFC6788D668E"
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 05:00:21 -0000

This is a multi-part message in MIME format.
--------------A8688FCAE9DFBFC6788D668E
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

As Ilari says, there's a lot of stuff in here.  I'll put some thoughts
here at the top, and more inline.

First off, it seems somewhat self-evident that if we guarantee 0-RTT
non-replay, then of course it makes sense to just concatenate the
streams.  That is, if 0-RTT data is not replayable, there's not much
special about it to merit separating it off from normal application
data.  This isn't quite exactly true because of the DKG attack, but it
may be close enough to not matter.

However, I'm still not convinced that requiring strong 0-RTT non-replay
is feasible/the right thing to do.  So, I do not consider the question
of single stream vs. block-of-early-data + 1-RTT stream to be settled.

On 05/05/2017 11:28 AM, Colm MacCárthaigh wrote:
>
> I wanted to start a separate thread on this, just to make some small
> aspects of replay mitigating clear, because I'd like to make a case
> for TLS providing a single-stream, which is what people seem to be
> doing anyway. 
>
> Let's look at the DKG attack. There are two forms of the attack, one
> is as follows:
>
> "Client sends a request with a 0-RTT section. The attacker lets the
> server receive it, but suppresses the server responses, so the client
> downgrades and retries as a 1-RTT request over a new connection.
> Repeating the request". 
>

Does the client always downgrade?  We don't require it to do so, in TLS
1.3, though of course browsers would.

> In this case, server-side signaling such as the X-header trick doesn't
> work at all. But thankfully this attack is equivalent to an ordinary
> socket interference attack. E.g. if an attacker today suppressed a
> server response to a HTTP request, then the client will do its retry
> logic. It's the same, and I think everything is compatible with
> today's behavior.
>
> Next is the more interesting form of the attack:
>
> "Client sends a request with a 0-RTT section. For some reason the
> server can't reach the strike register or single use cache, and falls
> back to 1-RTT. Server accepts the request over 1-RTT.  Then a short
> time later, the attacker replays the original 0-RTT section."
>
> In this case, server side signaling to the application (such as the
> neat X- header trick) also doesn't work, and is not backwards
> compatible or secure by default. It doesn't work because the server
> application can't be made idempotent from "outside" the application,
> so any signaling is insufficient, and is equivalent to the
> Exactly-Once message delivery problem in distributed systems. Since a
> request might be retried as in case 1, it needs an application-level
> idempotency key, or a delay-and-retry strategy (but replay will break
> this). There's some detail on all this in the review. End result is
> that a server-side application that was never designed to reach
> duplicates may suddenly be getting exactly one duplicate (that's all
> the attack allows, if servers reject duplicate 0-RTT). 
>

I feel like many applications that use delay-and-retry will see this and
conclude that they should just not attempt to use 0-RTT.

> What is actually needed here, I think, is client-side signaling.
> Careful clients need to be made aware of the original 0-RTT failure. 
>
> So for example, an SDK that writes to an eventually consistent data
> store may treat any 0-RTT failure as a hard failure, and *not* proceed
> to sending the request over 1-RTT. Instead it

Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT; the
application can decide it's willing to take the risk or use some other
strategy.  But I'm not convinced that the TLS stack needs to decide on
its own, without application input.

> might wait its retry period, do a poll, and only then retry the
> request. If the TLS implementation signals the original  0-RTT failure
> to the client, as if it were a connection error, everything is
> backwards compatible again. Well mostly; to be properly defensive, the
> client's retry time or polling interval needs to be greater than the
> potential replay window, because only then can it reason about whether
> the original request succeeded or not. If there is a strict maximum
> replay window, then this behavior is enforceable in a TLS
> implementation: by delaying the original failure notification to the
> client application by that amount. 
>

And if there is not a strict replay window defined in the spec, then the
client must have some way of knowing what window the server is using,
etc., etc..  When I added the 10-second guidance that's currently in
there, I explicitly wanted something concrete, but was not willing to
claim that I knew enough about all possible ways in which TLS can be
deployed to make a normative requirement for all users of the protocol. 
I don't think that's changed; setting a fixed global limit seems to be
asking for trouble.  I suppose if we really needed to we could stick it
in a NST extension, but I don't think we really need to.

> Of course browsers won't do this, and that's ok. Browsers have decided
> that aggressive retries is best for their application space. But
> careful clients /need/ this; and it's not just about backwards
> compatibility. It is a fundamental first-principles requirement for
> something that uses an eventually consistent data store. We can say
> don't use 0-RTT, but that's not practical, for reasons also in the review.

Does a careful client really need the TLS stack to signal connection
error?  Surely the TLS stack will provide a mechanism to inquire as to
the connection state, and whether 0-RTT was rejected.  The application
could implement its own delay.

And I read what you wrote in the github issue about how saying "don't
use 0-RTT" is not practical, but I don't believe that it is universally
true.  Some (careful) applications will rightly consider the tradeoffs
and decide to not use it.  On the web ... there are different forces at
play, and it may well take a (security bug) name and website to cause
webapp creators and framework authors to take proper notice.  But I am
having a hard time squaring your point about careful clients with the
point about non-practicality.  If there are careful clients, they will
heed warnings; if just using warnings is not practical, then what are
the careful clients doing?

>
> So if we want to fully mitigate DKG attacks, I think it is useful to
> hard cap the replay, say that it MUST be at most 10 seconds. And then
> worst case, a client that needs to be careful can wait 10 seconds.
> Note that the TLS implementation can do this on the client's behalf,
> by inserting a delay. Of course that means that for these kinds of
> applications, this means that 0-RTT delivers speed most of the time,
> but may occasionally slow things down by 10 seconds. I think that's an
> ok trade-off to make for backwards compatibility.
>

Again, does this need to be in the TLS implementation or can the
(careful) application do it?

But more importantly, a requirement to "randomly" (i.e., unpredictably)
introduce a large (10-second) delay into processing is going to cause a
lot of frustration in large deployments.  Predictability trumps average
speed, in many use cases.  In other words, I don't think your side of
the tradeoff is the IETF consensus position.

> But it also has implications for middle-boxes: a TLS reverse proxy
> needs to either not use 0-RTT on the "backend" side, or it needs to
> use it in very careful way; accepting 0-RTT from the original client,
> only if the backend also accepts a 0-RTT section from the proxy. This
> is to avoid the case where the client can't reason about the potential
> for a replay between the proxy and the backend. It's doable, but
> gnarly, and slows 0-RTT acceptance down to the round trip between the
> client and the backend, via the proxy. 
>

Waiting to find out if the backend accepts 0-RTT from the proxy
basically negates any value that might be gained from using 0-RTT there
-- it's more consistent and safer to always use 1-RTT.  Many (though of
course not all) reverse-proxy deployments

> That's one reason why the review suggests something else too:  just
> lock careful applications out, but in a mechanistic way rather than a
> "good intentions" way, by having TLS implementations *intentionally*
> duplicate 0-RTT sections. 
>

Err, regularly locking out careful applications is supposed to be a good
thing?

> O.k. so all of that the above might be a bit hairy: but I want to take
> away from it at this stage is that splitting the early_data and
> application_data at application level isn't particularly helpful; the
> server-side can't really use this information anyway, because of the
> Exactly-Once problem. Client side signaling does help though, and a
> simple safe-by-default mechanism there is to behave as if the
> connection has failed, but after writing the first section of data.
> E.g. in s2n this would be ...
>
> conn = s2n_connect(); // Client makes a connection
> r = s2n_write(conn, "GET / HTTP/1.1 ... "); // Client writes some
> data, we stuff it in the 0-RTT and send it. This write succeeds. From
> the client's perspective, it may or may not have been received; that's
> normal. 
>
> /* At this point the 0-RTT data is rejected by the server, and so it
> might be replayable  ... iff the server side strike-register or 
>    cache had a problem. 
>   
>    A pedantically correct TLS library might then pause here for 10
> seconds, or if it's non-blocking, then set a timer so that nothing can
> happen on conn for the next 10 seconds. Browsers could turn this
> behavior off, since they retry aggressively anyway. But it's a secure
> default that is backwards compatible.
> */
>
> r = s2n_read()/s2n_write()/s2n_shutdown();  // At this point, s2n
> returns failure. It's as if the connection failed. The client can
> implement its retry strategy, if any, safely; the request won't be
> replayed at this point. 
>
> r = s2n_connect(); // Client makes a new connection for a retry. 
>

(Again, the mandatory 10-second delay on 0-RTT rejection introduces huge
processing time variance, which is a no-go in some environments.)

It seems like you are taking the general stance that the TLS stack is
the only thing responsible for anti-replay and it should take strenuous
measures to effect anti-replay.  I don't disagree that the TLS stack
should provide anti-replay measures, but I also don't think that it's
the only actor in the stack that should be thinking about anti-replay. 
If we assume that the application can also be involved in anti-replay
(yes, an assumption, for this purpose), then a lot of these proposed
countermeasures seem excessive.  The careful client can introduce its
delays, and the careful server can also differentiate between 0-RTT and
1-RTT requests, holding on to potentially dangerous if replayed 0-RTT
requests until the handshake completes, and dropping them without
processing otherwise.  This is more efficient, as delay is only
introduced where needed for safety, and does not force the TLS stack to
make a one-size-maybe-fits-all decision on the tradeoffs involved.

I understand the desire to produce a protocol that is safe by default. 
But we do that already: by default, you don't get to use 0-RTT and
comply with the spec!  The TLS WG cannot take sole responsibility for
the security of the internet, or even the world wide web; we can provide
tools and do a lot of the work, but other things have to contribute as
well.  Side channels are a great example; we can do all we can at the
TLS layer but the application still has a boatload of chances to
introduce side channels that leak nominally secret information.  We can
provide a lot of tools, including single-use session caches/strike
registers, and encourage their use, and that helps make everything more
secure.  But I don't think we should feel like we need to go it alone.

>
> A slightly higher level API is probably more realistic, because
> there's a potential to optimize for connection re-use. There's really
> no need to tear down the whole connection and start-over. It's safe to
> proceed to 1-RTT if the delay has expired. A higher level API would
> fix that, but this is just the "safe by default" API I'm outlining. 
> Again, all I want to take away is that all of this is doable safely
> with a single stream. 
>

By the time the delay has expired you could have set up several 1-RTT
exchanges, yes. But then it starts looking more like a network
communications library built on top of the TLS protocol than just a TLS
protocol implementation.

-Ben

--------------A8688FCAE9DFBFC6788D668E
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    As Ilari says, there's a lot of stuff in here.  I'll put some
      thoughts here at the top, and more inline.

      

      First off, it seems somewhat self-evident that if we guarantee
      0-RTT non-replay, then of course it makes sense to just
      concatenate the streams.  That is, if 0-RTT data is not
      replayable, there's not much special about it to merit separating
      it off from normal application data.  This isn't quite exactly
      true because of the DKG attack, but it may be close enough to not
      matter.

      

      However, I'm still not convinced that requiring strong 0-RTT
      non-replay is feasible/the right thing to do.  So, I do not
      consider the question of single stream vs. block-of-early-data +
      1-RTT stream to be settled.

    

    
On 05/05/2017 11:28 AM, Colm
      MacCárthaigh wrote:

    

    

      
      

        


        

        
I wanted to start a separate thread on this, just to make
          some small aspects of replay mitigating clear, because I'd
          like to make a case for TLS providing a single-stream, which
          is what people seem to be doing anyway. 

        


        

        
Let's look at the DKG attack. There are two forms of the
          attack, one is as follows:

        


        

        
"Client sends a request with a 0-RTT section. The attacker
          lets the server receive it, but suppresses the server
          responses, so the client downgrades and retries as a 1-RTT
          request over a new connection. Repeating the request". 

        


        

      

    

    

    Does the client always downgrade?  We don't require it to do so, in
    TLS 1.3, though of course browsers would.

    

    

      

        
 

        
In this case, server-side signaling such as the X-header
          trick doesn't work at all. But thankfully this attack is
          equivalent to an ordinary socket interference attack. E.g. if
          an attacker today suppressed a server response to a HTTP
          request, then the client will do its retry logic. It's the
          same, and I think everything is compatible with today's
          behavior.

        


        

        
Next is the more interesting form of the attack:

        


        

        

          
"Client sends a request with a 0-RTT section. For some
            reason the server can't reach the strike register or single
            use cache, and falls back to 1-RTT. Server accepts the
            request over 1-RTT.  Then a short time later, the attacker
            replays the original 0-RTT section."

          


          

          
In this case, server side signaling to the application
            (such as the neat X- header trick) also doesn't work, and is
            not backwards compatible or secure by default. It doesn't
            work because the server application can't be made idempotent
            from "outside" the application, so any signaling is
            insufficient, and is equivalent to the Exactly-Once message
            delivery problem in distributed systems. Since a request
            might be retried as in case 1, it needs an application-level
            idempotency key, or a delay-and-retry strategy (but replay
            will break this). There's some detail on all this in the
            review. End result is that a server-side application that
            was never designed to reach duplicates may suddenly be
            getting exactly one duplicate (that's all the attack allows,
            if servers reject duplicate 0-RTT). 

          


          

        

      

    

    

    I feel like many applications that use delay-and-retry will see this
    and conclude that they should just not attempt to use 0-RTT.

    

    

      

        

          
 

          
What is actually needed here, I think, is client-side
            signaling. Careful clients need to be made aware of the
            original 0-RTT failure. 

          


          

          
So for example, an SDK that writes to an eventually
            consistent data store may treat any 0-RTT failure as a hard
            failure, and *not* proceed to sending the request over
            1-RTT. Instead it 

        

      

    

    

    Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT;
    the application can decide it's willing to take the risk or use some
    other strategy.  But I'm not convinced that the TLS stack needs to
    decide on its own, without application input.

    

    

      

        

          
might wait its retry period, do a poll, and only then
            retry the request. If the TLS implementation signals the
            original  0-RTT failure to the client, as if it were a
            connection error, everything is backwards compatible again.
            Well mostly; to be properly defensive, the client's retry
            time or polling interval needs to be greater than the
            potential replay window, because only then can it reason
            about whether the original request succeeded or not. If
            there is a strict maximum replay window, then this behavior
            is enforceable in a TLS implementation: by delaying the
            original failure notification to the client application by
            that amount. 

        

        


        

      

    

    

    And if there is not a strict replay window defined in the spec, then
    the client must have some way of knowing what window the server is
    using, etc., etc..  When I added the 10-second guidance that's
    currently in there, I explicitly wanted something concrete, but was
    not willing to claim that I knew enough about all possible ways in
    which TLS can be deployed to make a normative requirement for all
    users of the protocol.  I don't think that's changed; setting a
    fixed global limit seems to be asking for trouble.  I suppose if we
    really needed to we could stick it in a NST extension, but I don't
    think we really need to.

    

    

      

        
 

        
Of course browsers won't do this, and that's ok. Browsers
          have decided that aggressive retries is best for their
          application space. But careful clients /need/ this; and it's
          not just about backwards compatibility. It is a fundamental
          first-principles requirement for something that uses an
          eventually consistent data store. We can say don't use 0-RTT,
          but that's not practical, for reasons also in the review.

      

    

    

    Does a careful client really need the TLS stack to signal connection
    error?  Surely the TLS stack will provide a mechanism to inquire as
    to the connection state, and whether 0-RTT was rejected.  The
    application could implement its own delay.

    

    And I read what you wrote in the github issue about how saying
    "don't use 0-RTT" is not practical, but I don't believe that it is
    universally true.  Some (careful) applications will rightly consider
    the tradeoffs and decide to not use it.  On the web ... there are
    different forces at play, and it may well take a (security bug) name
    and website to cause webapp creators and framework authors to take
    proper notice.  But I am having a hard time squaring your point
    about careful clients with the point about non-practicality.  If
    there are careful clients, they will heed warnings; if just using
    warnings is not practical, then what are the careful clients doing?

    

    

      

        


        

        
So if we want to fully mitigate DKG attacks, I think it is
          useful to hard cap the replay, say that it MUST be at most 10
          seconds. And then worst case, a client that needs to be
          careful can wait 10 seconds. Note that the TLS implementation
          can do this on the client's behalf, by inserting a delay. Of
          course that means that for these kinds of applications, this
          means that 0-RTT delivers speed most of the time, but may
          occasionally slow things down by 10 seconds. I think that's an
          ok trade-off to make for backwards compatibility.

        


        

      

    

    

    Again, does this need to be in the TLS implementation or can the
    (careful) application do it?

    

    But more importantly, a requirement to "randomly" (i.e.,
    unpredictably) introduce a large (10-second) delay into processing
    is going to cause a lot of frustration in large deployments. 
    Predictability trumps average speed, in many use cases.  In other
    words, I don't think your side of the tradeoff is the IETF consensus
    position.

    

    

      

        
 

        
But it also has implications for middle-boxes: a TLS
          reverse proxy needs to either not use 0-RTT on the "backend"
          side, or it needs to use it in very careful way; accepting
          0-RTT from the original client, only if the backend also
          accepts a 0-RTT section from the proxy. This is to avoid the
          case where the client can't reason about the potential for a
          replay between the proxy and the backend. It's doable, but
          gnarly, and slows 0-RTT acceptance down to the round trip
          between the client and the backend, via the proxy. 

        


        

      

    

    

    Waiting to find out if the backend accepts 0-RTT from the proxy
    basically negates any value that might be gained from using 0-RTT
    there -- it's more consistent and safer to always use 1-RTT.  Many
    (though of course not all) reverse-proxy deployments

    

    

      

        
 

        
That's one reason why the review suggests something else
          too:  just lock careful applications out, but in a mechanistic
          way rather than a "good intentions" way, by having TLS
          implementations *intentionally* duplicate 0-RTT sections. 

        


        

      

    

    

    Err, regularly locking out careful applications is supposed to be a
    good thing?

    

    

      

        
 

        
O.k. so all of that the above might be a bit hairy: but I
          want to take away from it at this stage is that splitting the
          early_data and application_data at application level isn't
          particularly helpful; the server-side can't really use this
          information anyway, because of the Exactly-Once problem.
          Client side signaling does help though, and a simple
          safe-by-default mechanism there is to behave as if the
          connection has failed, but after writing the first section of
          data. E.g. in s2n this would be ...

        


        

        
conn = s2n_connect(); // Client makes a connection

        
r = s2n_write(conn, "GET / HTTP/1.1 ... "); // Client
          writes some data, we stuff it in the 0-RTT and send it. This
          write succeeds. From the client's perspective, it may or may
          not have been received; that's normal. 

        


        

        
/* At this point the 0-RTT data is rejected by the server,
          and so it might be replayable  ... iff the server side
          strike-register or 

        
   cache had a problem. 

        
  

        
   A pedantically correct TLS library might then pause here
          for 10 seconds, or if it's non-blocking, then set a timer so
          that nothing can happen on conn for the next 10 seconds.
          Browsers could turn this behavior off, since they retry
          aggressively anyway. But it's a secure default that is
          backwards compatible.

        
*/

        


        

        
r = s2n_read()/s2n_write()/s2n_shutdown();  // At this
          point, s2n returns failure. It's as if the connection failed.
          The client can implement its retry strategy, if any, safely;
          the request won't be replayed at this point. 

        


        

        
r = s2n_connect(); // Client makes a new connection for a
          retry. 

        


        

      

    

    

    (Again, the mandatory 10-second delay on 0-RTT rejection introduces
    huge processing time variance, which is a no-go in some
    environments.)

    

    It seems like you are taking the general stance that the TLS stack
    is the only thing responsible for anti-replay and it should take
    strenuous measures to effect anti-replay.  I don't disagree that the
    TLS stack should provide anti-replay measures, but I also don't
    think that it's the only actor in the stack that should be thinking
    about anti-replay.  If we assume that the application can also be
    involved in anti-replay (yes, an assumption, for this purpose), then
    a lot of these proposed countermeasures seem excessive.  The careful
    client can introduce its delays, and the careful server can also
    differentiate between 0-RTT and 1-RTT requests, holding on to
    potentially dangerous if replayed 0-RTT requests until the handshake
    completes, and dropping them without processing otherwise.  This is
    more efficient, as delay is only introduced where needed for safety,
    and does not force the TLS stack to make a one-size-maybe-fits-all
    decision on the tradeoffs involved.

    

    I understand the desire to produce a protocol that is safe by
    default.  But we do that already: by default, you don't get to use
    0-RTT and comply with the spec!  The TLS WG cannot take sole
    responsibility for the security of the internet, or even the world
    wide web; we can provide tools and do a lot of the work, but other
    things have to contribute as well.  Side channels are a great
    example; we can do all we can at the TLS layer but the application
    still has a boatload of chances to introduce side channels that leak
    nominally secret information.  We can provide a lot of tools,
    including single-use session caches/strike registers, and encourage
    their use, and that helps make everything more secure.  But I don't
    think we should feel like we need to go it alone.

    

    

      

        
 

        


        

        
A slightly higher level API is probably more realistic,
          because there's a potential to optimize for connection re-use.
          There's really no need to tear down the whole connection and
          start-over. It's safe to proceed to 1-RTT if the delay has
          expired. A higher level API would fix that, but this is just
          the "safe by default" API I'm outlining.  Again, all I want to
          take away is that all of this is doable safely with a single
          stream. 

        

      

    

    

    By the time the delay has expired you could have set up several
    1-RTT exchanges, yes. But then it starts looking more like a network
    communications library built on top of the TLS protocol than just a
    TLS protocol implementation.

    

    -Ben

  


--------------A8688FCAE9DFBFC6788D668E--


From nobody Wed May 10 23:01:51 2017
Return-Path: 
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 44807129A99 for ; Wed, 10 May 2017 23:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 biBRY_q3UtT0 for ; Wed, 10 May 2017 23:01:46 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54BDF128BC8 for ; Wed, 10 May 2017 23:01:46 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id b68so7860250ywe.3 for ; Wed, 10 May 2017 23:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ye5ySPHMhQkisjJ8IFPVK+RhQTHlcVjImCC1SeiBwi0=; b=gLEAM8TaVki3wFnKamYFU0+wI0Ey5SHQYHEZllEuSvPq3o2Ku8B518uc+lubfE9Ny9 9qtqcovy5jrixivMVrrf7vg7ghcOuOUitILf9YIwgF2GTtJa0xcoX8Di7Ep8WGZG2oZ6 pYRXFwLhdTHpvvqgRFiyMpiAyEoFuFMyTYDKWr5KEyyFndzvFdbIHpXEC5GYdOZKw3We vUkUdw7IkpB+XM4xu5ITvJReDRWlEZeTo85Xf+9BePTujDcJtkvCz/F65NnjlzlNBjyG ldOerST6ahoQ/lyQaP6GXY3JsUumOkM6IQtirqGgSxnQMg5eVYTwT/2RhML5BFG3D3SZ BeCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ye5ySPHMhQkisjJ8IFPVK+RhQTHlcVjImCC1SeiBwi0=; b=hhl4fSUvWvZjUVusTSb7Zv5XitHL7pSP7IgXi1LnyB7553ADvPaW3ATNHjwn3D1Jiv HTqKS6m31jmMu1Wyp6AaHJP2CAG5hfHJ9+/ZFIsDlGangZZ15OalloYzjpNAKjEBLd5j TKlFNG3125KaI5mJYAperxt7Nb093lTRNXBfPcpTUo1vJ30pjqKtshHLWqOrLdl+/tiB /NBq8iJ/sw1nOo2rzQuhtUCOEw3vxWz4t1AXybFeChOvuFwM8KrrwUjryp8CiWyVtGRK UuyNdBWuYSKY/wRRMG9+RcSxsp+DSpc0sC9Zhx78t6N0vQGOclmOZ60SFkm1Cp8zBqur nr5g==
X-Gm-Message-State: AODbwcAmzvQg8A697YX0mChVlMCd01eIhiYP9zduoVawI7NaDVonENlF k8J7kUoOBHQv3uT6O+bigHR1DbOkIA==
X-Received: by 10.129.96.69 with SMTP id u66mr392217ywb.241.1494482505336; Wed, 10 May 2017 23:01:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Wed, 10 May 2017 23:01:44 -0700 (PDT)
In-Reply-To: 
References:  
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 10 May 2017 23:01:44 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11471c00da9dcf054f395286
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 06:01:49 -0000

--001a11471c00da9dcf054f395286
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 10, 2017 at 10:00 PM, Benjamin Kaduk  wrote:
>
> However, I'm still not convinced that requiring strong 0-RTT non-replay i=
s
> feasible/the right thing to do.
>

[ I've cut a lot for brevity, but hopefully what I've replied with can
address this, and the rest ]

The case for requiring servers, and especially middle-boxes to provide
strong 0-RTT non-replay is really the resource exhaustion, throttle
exhaustion and cache timing attacks. I think that's where the really
dangerous bugs are, the ones that will be exploited - maybe even
inadvertently - and that are a show-stopper for the stateless mitigation.
It just doesn't work.

Thankfully it's within our capabilities to fix this and there's nothing
logically impossible about providing non-replay for the 0-RTT sections.


> On 05/05/2017 11:28 AM, Colm MacC=C3=A1rthaigh wrote:
>
> "Client sends a request with a 0-RTT section. The attacker lets the serve=
r
> receive it, but suppresses the server responses, so the client downgrades
> and retries as a 1-RTT request over a new connection. Repeating the
> request".
>
> Does the client always downgrade?  We don't require it to do so, in TLS
> 1.3, though of course browsers would.
>

The current draft says that clients should only use tickets once, if they
do that, then the repeat attempt (even if it's still 0-RTT, with a
different ticket) is un-correlatable.

I feel like many applications that use delay-and-retry will see this and
> conclude that they should just not attempt to use 0-RTT.
>

Per the section of the original review about violation of layers and
separation of actors; this breaks the well-established relationship between
the layers. It's predictable that a site-administrator will enable 0-RTT
without any appreciation for the application-level impact. Vendors are
already providing 0-RTT in backwards compatible ways.

What is actually needed here, I think, is client-side signaling. Careful
> clients need to be made aware of the original 0-RTT failure.
>
> So for example, an SDK that writes to an eventually consistent data store
> may treat any 0-RTT failure as a hard failure, and *not* proceed to sendi=
ng
> the request over 1-RTT. Instead it
>
>
> Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT; the
> application can decide it's willing to take the risk or use some other
> strategy.  But I'm not convinced that the TLS stack needs to decide on it=
s
> own, without application input.
>

I'm just describing the only backwards compatible safe-by-default scheme I
can concoct, it's definitely kludgey and awkward. For this thread, my main
take-away from it is that separating streams doesn't actually help the
application; instead, it's a timing thing.


> Does a careful client really need the TLS stack to signal connection
> error?  Surely the TLS stack will provide a mechanism to inquire as to th=
e
> connection state, and whether 0-RTT was rejected.  The application could
> implement its own delay.
>

Yep, absolutely; but it'd be client-side signaling, and it's not
backwards-compatible or safe-by-default to rely on.


> And I read what you wrote in the github issue about how saying "don't use
> 0-RTT" is not practical, but I don't believe that it is universally true.
> Some (careful) applications will rightly consider the tradeoffs and decid=
e
> to not use it.  On the web ... there are different forces at play, and it
> may well take a (security bug) name and website to cause webapp creators
> and framework authors to take proper notice.  But I am having a hard time
> squaring your point about careful clients with the point about
> non-practicality.  If there are careful clients, they will heed warnings;
> if just using warnings is not practical, then what are the careful client=
s
> doing?
>

I actually share the optimism here. I think it's workable for careful
clients, and I wouldn't hold 0-RTT hostage to the DKG corner case. I think
we should ship it. All I'm trying to get at is that separate streams are
needless complexity, and they seem to be getting ignored by implementors
anyway.

Right now there's a very weird take in the draft: let the server figure it
out by marking the data as replay-able. Well actually that doesn't work; on
the server side, the sections can't always be correlated, and even if they
were an application would still need its own anti-retry strategy. It's
well-meaning; but doesn't work. We should take it out.

Here's an example. Client has two tickets: AA and BB.

T1. Client makes 0-RTT request for /foo/ with ticket AA. Servers receives
the request and marks as replayable-data, maybe uses AA to derive a
convenient idempotency/anti-replay key (like the X- header trick).

T2. Client was blocked, Tries again, doesn't re-use the ticket, per the
draft. So repeats with 0-RTT again, with ticket BB. Same as before, except
now the key is derived from BB.

T3. Client tries again, this time over 1RTT. Per the draft, there's *no*
signaling of repayable data.

What on earth is a server side application suppose to do with this sequence
of events? None of these 3 requests can be correlated, unless the
application author added their own key ... in which case they don't need
any of this TLS-layer stuff.

Some applications mitigate this kind of problem client side, what I'm
pointing out there is that to work robustly, then a client needs to 1) know
about the 0-RTT failure, 2) know for how long the 0-RTT request may be
replayed.  With that small modification; a client can actually repair
failures too.

So if we want to fully mitigate DKG attacks, I think it is useful to hard
> cap the replay, say that it MUST be at most 10 seconds. And then worst
> case, a client that needs to be careful can wait 10 seconds. Note that th=
e
> TLS implementation can do this on the client's behalf, by inserting a
> delay. Of course that means that for these kinds of applications, this
> means that 0-RTT delivers speed most of the time, but may occasionally sl=
ow
> things down by 10 seconds. I think that's an ok trade-off to make for
> backwards compatibility.
>
>
> Again, does this need to be in the TLS implementation or can the (careful=
)
> application do it?
>

I don't think a careful application can do it without a hard-cap; otherwise
a zombie write could come along at any time and invalidate its state.

That's one reason why the review suggests something else too:  just lock
> careful applications out, but in a mechanistic way rather than a "good
> intentions" way, by having TLS implementations *intentionally* duplicate
> 0-RTT sections.
>
>
> Err, regularly locking out careful applications is supposed to be a good
> thing?
>

Well, it locks out the careless ones, so yes ime, same as GREASE really :)


> (Again, the mandatory 10-second delay on 0-RTT rejection introduces huge
> processing time variance, which is a no-go in some environments.)
>

It needn't be mandatory; just the default. A careful client could do as
you're suggesting; handle this at a different layer.

--=20
Colm

--001a11471c00da9dcf054f395286
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, May 10, 2017 at 10:00 PM, Benjamin Kaduk <=
bkaduk@akamai.com> wrote:

      However, I'm still not convinced that requiring strong 0-RTT
      non-replay is feasible/the right thing to do.=C2=A0 

[ I've cut a lot for brevity, but hopefully =
what I've replied with can address this, and the rest ]

<=
/div>
The case for requiring servers, and especially middle-boxes to pr=
ovide strong 0-RTT non-replay is really the resource exhaustion, throttle e=
xhaustion and cache timing attacks. I think that's where the really dan=
gerous bugs are, the ones that will be exploited - maybe even inadvertently=
 - and that are a show-stopper for the stateless mitigation. It just doesn&=
#39;t work.=C2=A0

Thankfully it's within our c=
apabilities to fix this and there's nothing logically impossible about =
providing non-replay for the 0-RTT sections.=C2=A0
=C2=A0

    
On 05/05/2017=
 11:28 AM, Colm
      MacC=C3=A1rthaigh wrote:

     =20
      

       =20
       =20
        
"Client sends a request with a 0-RTT section. The attacke=
r
          lets the server receive it, but suppresses the server
          responses, so the client downgrades and retries as a 1-RTT
          request over a new connection. Repeating the request".=C2=A0=


    Does the client always downgrade?=C2=A0 We don't require it to do s=
o, in
    TLS 1.3, though of course browsers would.

The current draft says that clients should only use tickets once, =
if they do that, then the repeat attempt (even if it's still 0-RTT, wit=
h a different ticket) is un-correlatable.=C2=A0


    I feel like many applications that use delay-and-retry will see this
    and conclude that they should just not attempt to use 0-RTT.

Per the section of the original review about vi=
olation of layers and separation of actors; this breaks the well-establishe=
d relationship between the layers. It's predictable that a site-adminis=
trator will enable 0-RTT without any appreciation for the application-level=
 impact. Vendors are already providing 0-RTT in backwards compatible ways.=
=C2=A0


    

      

        

          
 

          
What is actually needed here, I think, is client-side
            signaling. Careful clients need to be made aware of the
            original 0-RTT failure.=C2=A0

          


          

          
So for example, an SDK that writes to an eventually
            consistent data store may treat any 0-RTT failure as a hard
            failure, and *not* proceed to sending the request over
            1-RTT. Instead it 

        

      

    

    

    Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT;
    the application can decide it's willing to take the risk or use som=
e
    other strategy.=C2=A0 But I'm not convinced that the TLS stack need=
s to
    decide on its own, without application input.
I'm just describing the only backwards compatible safe-by-=
default scheme I can concoct, it's definitely kludgey and awkward. For =
this thread, my main take-away from it is that separating streams doesn'=
;t actually help the application; instead, it's a timing thing.=C2=A0


    

    Does a careful client really need the TLS stack to signal connection
    error?=C2=A0 Surely the TLS stack will provide a mechanism to inquire a=
s
    to the connection state, and whether 0-RTT was rejected.=C2=A0 The
    application could implement its own delay.
<=
br>
Yep, absolutely; but it'd be client-side signaling, and i=
t's not backwards-compatible or safe-by-default to rely on.=C2=A0
=

=C2=A0

    And I read what you wrote in the github issue about how saying
    "don't use 0-RTT" is not practical, but I don't belie=
ve that it is
    universally true.=C2=A0 Some (careful) applications will rightly consid=
er
    the tradeoffs and decide to not use it.=C2=A0 On the web ... there are
    different forces at play, and it may well take a (security bug) name
    and website to cause webapp creators and framework authors to take
    proper notice.=C2=A0 But I am having a hard time squaring your point
    about careful clients with the point about non-practicality.=C2=A0 If
    there are careful clients, they will heed warnings; if just using
    warnings is not practical, then what are the careful clients doing?

I actually share the optimism here. I th=
ink it's workable for careful clients, and I wouldn't hold 0-RTT ho=
stage to the DKG corner case. I think we should ship it. All I'm trying=
 to get at is that separate streams are needless complexity, and they seem =
to be getting ignored by implementors anyway.=C2=A0

Right now there's a very weird take in the draft: let the server figu=
re it out by marking the data as replay-able. Well actually that doesn'=
t work; on the server side, the sections can't always be correlated, an=
d even if they were an application would still need its own anti-retry stra=
tegy. It's well-meaning; but doesn't work. We should take it out.=
=C2=A0

Here's an example. Client has two ticke=
ts: AA and BB.=C2=A0

T1. Client makes 0-RTT reques=
t for /foo/ with ticket AA. Servers receives the request and marks as repla=
yable-data, maybe uses AA to derive a convenient idempotency/anti-replay ke=
y (like the X- header trick).

T2. Client was block=
ed, Tries again, doesn't re-use the ticket, per the draft. So repeats w=
ith 0-RTT again, with ticket BB. Same as before, except now the key is deri=
ved from BB.

T3. Client tries again, this time ove=
r 1RTT. Per the draft, there's *no* signaling of repayable data.
<=
div>
What on earth is a server side application suppose to do=
 with this sequence of events? None of these 3 requests can be correlated, =
unless the application author added their own key ... in which case they do=
n't need any of this TLS-layer stuff.=C2=A0

So=
me applications mitigate this kind of problem client side, what I'm poi=
nting out there is that to work robustly, then a client needs to 1) know ab=
out the 0-RTT failure, 2) know for how long the 0-RTT request may be replay=
ed.=C2=A0 With that small modification; a client can actually repair failur=
es too.=C2=A0


        
So if we want to fully mitigate DKG attacks, I think it is
          useful to hard cap the replay, say that it MUST be at most 10
          seconds. And then worst case, a client that needs to be
          careful can wait 10 seconds. Note that the TLS implementation
          can do this on the client's behalf, by inserting a delay. Of
          course that means that for these kinds of applications, this
          means that 0-RTT delivers speed most of the time, but may
          occasionally slow things down by 10 seconds. I think that's a=
n
          ok trade-off to make for backwards compatibility.

        


        

      

    

    

    Again, does this need to be in the TLS implementation or can the
    (careful) application do it?

=
I don't think a careful application can do it without a hard-cap; other=
wise a zombie write could come along at any time and invalidate its state.=
=C2=A0


    

      

        
 

        
That's one reason why the review suggests something else
          too: =C2=A0just lock careful applications out, but in a mechanist=
ic
          way rather than a "good intentions" way, by having TLS
          implementations *intentionally* duplicate 0-RTT sections.=C2=A0
        


        

      

    

    

    Err, regularly locking out careful applications is supposed to be a
    good thing?

Well, it locks out th=
e careless ones, so yes ime, same as GREASE really :)
=C2=A0

    (Again, the mandatory 10-second delay on 0-RTT rejection introduces
    huge processing time variance, which is a no-go in some
    environments.)

It needn't=
 be mandatory; just the default. A careful client could do as you're su=
ggesting; handle this at a different layer.=C2=A0

-- 
Colm




--001a11471c00da9dcf054f395286--


From nobody Thu May 11 01:21:43 2017
Return-Path: 
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 C5433129AEA for ; Thu, 11 May 2017 01:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level: 
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 ihwyzXEj7zpX for ; Thu, 11 May 2017 01:21:39 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4191B129AC9 for ; Thu, 11 May 2017 01:21:39 -0700 (PDT)
Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 84E138BD for ; Thu, 11 May 2017 09:21:33 +0100 (BST)
Received: by mail-it0-f42.google.com with SMTP id c15so39487270ith.0 for ; Thu, 11 May 2017 01:21:33 -0700 (PDT)
X-Gm-Message-State: AODbwcD7+QhtRV4NIFSTUTGb/lA8Vw0qXv2zENQDK1LAT+Q4zhWoUEBL pSj7Or9CfZ8z538tgTXVK1aJM2G67g==
X-Received: by 10.36.127.200 with SMTP id r191mr9494400itc.91.1494490892025; Thu, 11 May 2017 01:21:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.127.79 with HTTP; Thu, 11 May 2017 01:21:31 -0700 (PDT)
In-Reply-To: 
References:  
From: Matt Caswell 
Date: Thu, 11 May 2017 09:21:31 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Martin Thomson 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [TLS] Alerts
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 08:21:41 -0000

On 10 May 2017 at 21:51, Martin Thomson  wrote:
> On 11 May 2017 at 01:21, Matt Caswell  wrote:
>> Do we really need all of these alerts?
>
> NSS uses these, but in ways that I don't really understand.  I think
> that this is part of the general issue that TLS does and doesn't
> really include requirements about how to handle the certificate chain.

OpenSSL is quite inconsistent in its use of alerts. That's how this
issue came up for me - I was reviewing what the spec said about alerts
and comparing it to the OpenSSL implementation (checking we failed
everywhere we are supposed to fail, and with the correct alert).
OpenSSL is currently using the more specific alerts for certificate
failures, although this is in contradiction to what it says in the
"Server Certificate Selection" section.

If the view is that the more specific alerts are helpful, then I'd
suggest amending the wording in the "Server Certificate Selection"
section to remove the bit about the "unsupported_certificate" alert
and (possibly) replace with a reference to the set of alerts that
might be sent instead.

Alternatively, if the more specific alerts are not helpful, then
perhaps we should prune down the list in section 6 to a much smaller
list.

Matt


From nobody Thu May 11 01:52:26 2017
Return-Path: 
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 51C8A12EB7E for ; Thu, 11 May 2017 01:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 VgSWu5Qu4Aur for ; Thu, 11 May 2017 01:52:23 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C65A5124D85 for ; Thu, 11 May 2017 01:52:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 822FE21CE8; Thu, 11 May 2017 11:52:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZAn_6AMcjmnD; Thu, 11 May 2017 11:52:19 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 53BCA2313; Thu, 11 May 2017 11:52:19 +0300 (EEST)
Date: Thu, 11 May 2017 11:52:18 +0300
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" 
Message-ID: <20170511085217.GA13126@LK-Perkele-V2.elisa-laajakaista.fi>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 08:52:25 -0000

On Thu, May 11, 2017 at 12:00:17AM -0500, Benjamin Kaduk wrote:
> 
> First off, it seems somewhat self-evident that if we guarantee 0-RTT
> non-replay, then of course it makes sense to just concatenate the
> streams.  That is, if 0-RTT data is not replayable, there's not much
> special about it to merit separating it off from normal application
> data.  This isn't quite exactly true because of the DKG attack, but it
> may be close enough to not matter.
> 
> However, I'm still not convinced that requiring strong 0-RTT non-replay
> is feasible/the right thing to do.  So, I do not consider the question
> of single stream vs. block-of-early-data + 1-RTT stream to be settled.

There are deeper problems than that:

- Strict HTTP clients can't allow autoreplay if 0-RTT contains a POST
  (and any HTTP client that isn't strict is a lost cause anyway).
- Ensuring that there is no race causing possible data corruption if
  the server rejects 0-RTT.
- Concatenation seems to play poorly with 0-RTT exporters (which start
  to seem like an attractive nuisance...).


Also, turns out that unordered replay is just fundamential. So any
_existing_ systems that don't handle unordered replay can be broken,
and there isn't anything TLS can do about that.

Which leaves the "loads of replays" problem from lack of strong 0-RTT
replay protection.



-Ilari


From nobody Thu May 11 04:01:55 2017
Return-Path: 
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 C858912EC29 for ; Thu, 11 May 2017 04:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.024
X-Spam-Level: 
X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 HEeE09UMZeCL for ; Thu, 11 May 2017 04:01:52 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB91129404 for ; Thu, 11 May 2017 03:59:42 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 795D23D943; Thu, 11 May 2017 10:59:42 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 795D23D943
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 795D23D943
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4652C7D509; Thu, 11 May 2017 10:59:42 +0000 (UTC)
From: Hubert Kario 
To: Ilari Liusvaara 
Cc: "tls@ietf.org" 
Date: Thu, 11 May 2017 12:59:40 +0200
Message-ID: <2189201.HeVcJDlHJs@pintsize.usersys.redhat.com>
In-Reply-To: <20170510192848.GA11915@LK-Perkele-V2.elisa-laajakaista.fi>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <20170510192848.GA11915@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1524605.55TmeF9BDk"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 11 May 2017 10:59:42 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 11:01:54 -0000

--nextPart1524605.55TmeF9BDk
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 10 May 2017 21:28:48 CEST Ilari Liusvaara wrote:
> On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> > Yes, encrypted SNI was discussed and ultimately rejected.
> >=20
> > But do we really have to send the literal value? Don't we need to just
> > make
> > sure that the client and server agree on the host that the client wants=
 to
> > connect?
> >=20
> > Couldn't we "encrypt" the SNI by hashing the host name with a salt,
> > sending
> > the salt and the resulting hash, making the server calculate the same h=
ash
> > with each of the virtual host names it supports and comparing with the
> > client provided value?
>=20
> What makes encrypting SNI nasty is replay attacks.

What if we specify that the salt is the client key share?


=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart1524605.55TmeF9BDk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZFEQcAAoJEJKo0bgB0vX1HacP/0AXOlYii3t7n/Ti8rqTUOAD
A8W0nw7v2uoVCYiuCaXeHX/F7GZRWYax18wdVZ+3krlLvlcfLIB0Kct5OuSnaI6o
nt5WkEKziSge84tqDEkWdvmYFEH6QTciJOxPiX3qR81QQHFv99DNgj9B8q2mZDqf
66aeLEtnkn1RDprRnFKfJd3l5yPAjOyXfOh7AYHE0IsJNicjeethWmARuPVRsn3V
rK8stzYBzykC1INk5dHTHTF7zi8H9m1CmU5Yp2IDUwK+TxIGhzLaarGRdUPzNQpv
3QZNxxpoq4fbr/fd5cFqpd7YqBVUgCz/JdPB3r5Fu6U2TdITup8Q2IvqDmXGwZmU
bLPcR1flgB+6R4WUS0DI9zdWJgMfi51/LZNSxZK/rSb6e7X8q8HVg3UsviYId2tV
beNiCtj9vf0tB6wO9+HLDzDnSxH1a3+rPBCVdcNuPgzB+fiIYOshC60Hfy/pgPzO
1w+nL0+5jAreFidrR24oyLUdoIIJYtNFaQlhzDLtF4QHEeNOGNtoVaxp+GgFPczA
TCpQU7jJH2o3zhVsv2lnJFLXlRgYYZPDzYT3uTAHuQyp/ROgGu/ycCUKoU+KysAD
sMfLREFfRrBiKula0pofQ5tkrB8Zuj7F8kwXsINTz6cUG9Xyb9N47cYpOW3E73+O
qH8Thrgz6aJbgGO/v8gk
=jKde
-----END PGP SIGNATURE-----

--nextPart1524605.55TmeF9BDk--


From nobody Thu May 11 04:11:08 2017
Return-Path: 
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 6CC4512EC3D for ; Thu, 11 May 2017 04:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ch43Yd9XJq8R for ; Thu, 11 May 2017 04:11:05 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B8F12EC40 for ; Thu, 11 May 2017 04:08:48 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 480427F7AE; Thu, 11 May 2017 10:58:29 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 480427F7AE
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 480427F7AE
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F05125C8AE; Thu, 11 May 2017 10:58:28 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 11 May 2017 12:58:21 +0200
Message-ID: <2045926.sutFeuuH9X@pintsize.usersys.redhat.com>
In-Reply-To: <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart14513970.6hmDUg8LNm"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 11 May 2017 10:58:29 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 11:11:07 -0000

--nextPart14513970.6hmDUg8LNm
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 10 May 2017 21:04:53 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
> >=20
> > But in general, I wonder if we didn't approach the SNI from the wrong s=
ide
> > - as I said, we may not need to encrypt it, we just make sure that clie=
nt
> > and server agree on the virtual host the connection is going to.
>=20
> They can do that with a name in the clear.  If the name is to be hidden
> from passive observers, then you do need encryption so that only the
> client and server, and not the passive observers, can recover the name.

You are going in the exact direction I'm saying we should not go, for the s=
ame=20
reason you said:

> I do believe this was discussed at some length previously.

There are multiple schemes that allow the peers to make sure that both of t=
hem=20
mean X without outright saying "X". Salting and hashing is one, including i=
t=20
in key exchange, (SRP style) is another.
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart14513970.6hmDUg8LNm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZFEPNAAoJEJKo0bgB0vX1cesQAKFtRoeWnrTCQYX69bKIFmbN
hdLUVTwumiJo2w+KtTkgxhn32rg+nTaCnxUhnjmdffZOynphfXUsdD0Ai51894Nd
j3a7qPcPMZNs1/HyTTPoPtFkBJxjVDkmGjthHQXsOT46auBXTS8uNWMw8Ot5B28y
fBUH6943j839xqzLDgwvd29wzxMXq7BEUIJUan88OR0xEKiBFcNM3MYXFiHaEDjb
32nPZQE422ruQTPzq68m7T3vZTFq/vhvybI8Ap4ZcPU0PnMcMQEJJXFt2LZUDd5o
vyZdviaZl1gyX5Sv2BpJclMhhq39XQwYifsTZfLjDfCVUWtZ5MWQ2kpFfG/tUdyA
BLGsBzdJBMvasUUj5wc0GBtzgim0suH4RNNI3sSrhxsiBMcPd0Cos4OxrDK951RW
BA5KtSyNrytMIIlnxlNJhNM/8710wzL+rcypmV7/erLogC1CXLl0TyLIlJXbDIBt
QbU3iQPY6Lcyl8qQaqRZSlhjqfTjHhx+WSpct9AboKiKWJUfAKNps9IzRpTgi+yw
8UnljHQnXKTunL7tbtDUswPKfv6X2gKoFNra1XGhztfEU3FoAkg+Ox+INIFgwm56
mb0BgOkIy+18aOdpkvKjMdQoRJW9UyZ/2KQoprc/qCRSX+kXC1h/f6BKl4CKIiRb
69rxF5NkxdbqtbKMLSVW
=xQ6h
-----END PGP SIGNATURE-----

--nextPart14513970.6hmDUg8LNm--


From nobody Thu May 11 07:38:12 2017
Return-Path: 
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 E85B9127B5A for ; Thu, 11 May 2017 07:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.803
X-Spam-Level: 
X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0FLRU_2XI8An for ; Thu, 11 May 2017 07:38:09 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id C775713147C for ; Thu, 11 May 2017 07:31:27 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5A3C4200019; Thu, 11 May 2017 14:31:27 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 43DCA200008; Thu, 11 May 2017 14:31:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494513087; bh=W38lspmMkOzfzN9v7kzes6QJJDrIjis/q3yZ2UG6fNU=; l=1412; h=From:To:In-Reply-To:References:Date:From; b=CFeDV65Pon+P1uiwQlnXXGov9F/PtY0J9OjN3LteN9r5NimQcH2rXPuPhytu/UPfK HaQ5YvWV/nfJG6kUkrnZZZBHRgB1lFtW8fDyzyvTmRXaGajxfbh0ahJwuR7QAuiAJr qQb1q/Tm/2eEvyGDIXCIfemEHEcCe+/781kxDbbg=
Received: from Tereva.local (unknown [172.19.40.142]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DFE2A1E07C; Thu, 11 May 2017 14:31:26 +0000 (GMT)
From: Brian Sniffen 
To: Daniel Kahn Gillmor , Christian Huitema , tls@ietf.org
In-Reply-To: <87ziekihp6.fsf@fifthhorseman.net>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>  <87ziekihp6.fsf@fifthhorseman.net>
Date: Thu, 11 May 2017 10:31:26 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 14:38:11 -0000

Daniel Kahn Gillmor  writes:

> On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
>> It certainly was. But then the clear text SNI is a gaping privacy hole
>> in TLS, the kind of issue that should keep us awake at night until it is
>> resolved. We need to make sure that we make progress, rather than rehash
>> the old arguments. Maybe we should invest some time and document the
>> various proposals in a draft. I am willing to work on that. Any other
>> volunteers?
>
> I agree with Christian's assessment of the problem, and i'd be
> interested in collaborating on such a draft.

Who's the audience for that draft?  If it's meant to document the blind
alleys we've found, perhaps we could list both alleys, and the walls at
the end:

  - hash the name [adversaries can hash too]
  - hash the name with a salt [adversaries can check the salted hash
    too, as if operating all the banned sites]
  - encrypt the SNI under the pre-shared key

But beware of:

  - the adversary can replay this SNI and see what site he gets
  - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
    no operations that scale linearly with number of sites hosted)
  - not everybody's going to do this, not even every TLS 1.3 instance
  - if networks can't track activity, some will push users to stay on
    TLS 1.2.

-Brian

-- 
Brian Sniffen
Akamai Technologies


From nobody Thu May 11 08:05:12 2017
Return-Path: 
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 BC51F1294E2 for ; Thu, 11 May 2017 08:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 hdsTc_gx1k3g for ; Thu, 11 May 2017 08:05:08 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 461D612FC17 for ; Thu, 11 May 2017 07:57:59 -0700 (PDT)
Received: from fifthhorseman.net (unknown [205.232.71.148]) by che.mayfirst.org (Postfix) with ESMTPSA id B4F98F993; Thu, 11 May 2017 10:57:58 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id BF6DA2068B; Thu, 11 May 2017 10:21:36 -0400 (EDT)
From: Daniel Kahn Gillmor 
To: Roland Zink , Christian Huitema , tls@ietf.org
In-Reply-To: <95423440-7d9a-6568-0e80-e58e3e27a373@zinks.de>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>  <1be2b15e-2e96-89f4-fe72-7f35a03ae99b@huitema.net> <95423440-7d9a-6568-0e80-e58e3e27a373@zinks.de>
Date: Thu, 11 May 2017 10:21:36 -0400
Message-ID: <87mvajiidr.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 15:05:10 -0000

On Thu 2017-05-11 00:03:15 +0200, Roland Zink wrote:
> Not necessarily as you may for example use the path part of a URL to 
> distinguish between services.

if we're talking about HTTPS, this approach raises a series of potential
security issues thanks to the same-origin policy and other host- or
domain-specific features of the web security model.  It doesn't solve
the situation where you'd like the services to be independent.

                --dkg


From nobody Thu May 11 11:07:30 2017
Return-Path: 
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 9DFFB129405 for ; Thu, 11 May 2017 11:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 rLjbAbX8nW-G for ; Thu, 11 May 2017 11:07:27 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BCC1293DF for ; Thu, 11 May 2017 11:02:07 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60B39C059741; Thu, 11 May 2017 18:02:06 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 60B39C059741
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 60B39C059741
Received: from pintsize.usersys.redhat.com (ovpn-200-17.brq.redhat.com [10.40.200.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC11F18019; Thu, 11 May 2017 18:02:05 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 11 May 2017 20:01:58 +0200
Message-ID: <2687686.v67HcTzOUq@pintsize.usersys.redhat.com>
In-Reply-To: 
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <87ziekihp6.fsf@fifthhorseman.net> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart31140468.tutHbUG5nQ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 11 May 2017 18:02:06 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 18:07:29 -0000

--nextPart31140468.tutHbUG5nQ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, 11 May 2017 16:31:26 CEST Brian Sniffen wrote:
> Daniel Kahn Gillmor  writes:
> > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> >> It certainly was. But then the clear text SNI is a gaping privacy hole
> >> in TLS, the kind of issue that should keep us awake at night until it =
is
> >> resolved. We need to make sure that we make progress, rather than reha=
sh
> >> the old arguments. Maybe we should invest some time and document the
> >> various proposals in a draft. I am willing to work on that. Any other
> >> volunteers?
> >=20
> > I agree with Christian's assessment of the problem, and i'd be
> > interested in collaborating on such a draft.
>=20
> Who's the audience for that draft?  If it's meant to document the blind
> alleys we've found, perhaps we could list both alleys, and the walls at
> the end:
>=20
>   - hash the name [adversaries can hash too]
>   - hash the name with a salt [adversaries can check the salted hash
>     too, as if operating all the banned sites]
>   - encrypt the SNI under the pre-shared key
>=20
> But beware of:
>=20
>   - the adversary can replay this SNI and see what site he gets
>   - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
>     no operations that scale linearly with number of sites hosted)

Doesn't that create a Catch 22?

I need to get the key to encrypt the SNI. But if we don't want the names to=
=20
leak, how do I authenticate the key without telling the server what=20
certificate I will accept to authenticate the key?

That doesn't look to me like a problem we can solve with typical symmetric =
or=20
asymmetric crypto - it looks to me like more of a zero-knowledge proof issu=
e.

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart31140468.tutHbUG5nQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZFKcWAAoJEJKo0bgB0vX15WYP/3RrgLhLK4DKLzItTnQYtHtf
DLel+zQ/VQHkaQUuBqRDlX4Z2BN4SA/aHoho9b+Xd2aBq6B0kxQis9Sg/hHV7zX1
qszjrV4j8B/SJM8cOKF58Badl9oEdmSacMnXdXIN1YL+4b3Gt01W4everrxP3bbI
2C32UcCNs1ZY4l3AI1RDoDv+y82DBbNngOYJH4v2mHpg/smtpMChTl8LIJ8Jpz0T
YxxOMqK0Hj9UrpN0KvWO+kgm1361wQxv6v7R06T9WJjOUib38Z694AIhTz3TM0qc
c+QibVr7Bj0tOrrYqXzS+/mFlp01CNOezIFptclQbH1QvrMJVrDIw3N6dnYxJqNK
ymmdSo0O4pL3xtlFIT5ljxT6q9sNM0GP641SGdbAf/EVnziDNc24ojUBzvf569TP
e9JRVB3dCCsds2VqCXmIsze80lcKOI1WuI00poogiE0DgOoo6F7OT1BvpIytCtIs
XaqHhU3Y4YAWKlM84qiisHKbpTc2LXChmlCdYmbyWpGubTguI+fAm/bUThfEZ7Rx
BfsRgldAiklIrAN189bBoB2Y6dTcSGn+fOjc0rocM3lZ0L5ZP0rDqGDJOfENjGxC
TfKqEDClkUV54G0JM7Y3xd1E6UtUfVBiOa51i6lHzfpJiMGvoYbUuZq8cUr1kR1D
whjjJ07tXwD9EUMps3wv
=dF0O
-----END PGP SIGNATURE-----

--nextPart31140468.tutHbUG5nQ--


From nobody Thu May 11 11:40:41 2017
Return-Path: 
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 36DD112944A for ; Thu, 11 May 2017 11:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 hZtlxqLgg06j for ; Thu, 11 May 2017 11:40:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C75129C41 for ; Thu, 11 May 2017 11:35:15 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 751677A3309; Thu, 11 May 2017 18:35:14 +0000 (UTC)
Date: Thu, 11 May 2017 18:35:14 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20170511183514.GE25754@mournblade.imrryr.org>
Reply-To: tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <87ziekihp6.fsf@fifthhorseman.net>  <2687686.v67HcTzOUq@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2687686.v67HcTzOUq@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Subject: Re: [TLS] "Encrypted" SNI
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 18:40:40 -0000

On Thu, May 11, 2017 at 08:01:58PM +0200, Hubert Kario wrote:

> > But beware of:
> > 
> >   - the adversary can replay this SNI and see what site he gets
> >   - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
> >     no operations that scale linearly with number of sites hosted)
> 
> Doesn't that create a Catch 22?
> 
> I need to get the key to encrypt the SNI. But if we don't want the names to 
> leak, how do I authenticate the key without telling the server what 
> certificate I will accept to authenticate the key?
> 
> That doesn't look to me like a problem we can solve with typical symmetric or 
> asymmetric crypto - it looks to me like more of a zero-knowledge proof issue.

No zero-knowledge schemes come to mind that are suitable to this task.

What can work, but costs latency is to do anon-(EC)DH key agreement
first, and only *then* exchange certificates under the established
keys and sign the session transcripts as required.  That is enable
encryption first, and authentication second, with SNI sent after
you have an unauthenticated encrypted channel.

Yes, an active MiTM attack could capture the SNI, but it would
prevent full session establishment, and so would be tamper-evident.

(One might imagine that initial opportunistic crypto being TCPinc,
with channel bindings extracted into a light-weight authentication
protocol on top, that no longer needs to do the key agreement bits).

The TLS 1.3 draft protocol, while eschewing weaker crypto primitives,
seems optimized more for lower-latency than for greater resistance
to traffic analysis.  I don't think that you can have both.

To really address the issue, one needs a more complete architecture,
that combines all the relevant bits of TCP, TLS and HTTP, ....
Such holistic (r)evolution is extremely difficult.

-- 
	Viktor.


From nobody Thu May 11 13:12:36 2017
Return-Path: 
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 C9CD912EAB4 for ; Thu, 11 May 2017 13:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 iHWCnX2tnwl6 for ; Thu, 11 May 2017 13:12:33 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0F0131452 for ; Thu, 11 May 2017 13:06:39 -0700 (PDT)
Received: from [10.70.192.184] (unknown [38.86.167.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B15247A32F1 for ; Thu, 11 May 2017 20:06:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Thu, 11 May 2017 16:06:37 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: <29AB09F3-AD52-4DE8-AD28-B76CB6AB6B1D@dukhovni.org>
References:   
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Alerts
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 20:12:35 -0000

> On May 11, 2017, at 4:21 AM, Matt Caswell  wrote:
> 
> If the view is that the more specific alerts are helpful, then I'd
> suggest amending the wording in the "Server Certificate Selection"
> section to remove the bit about the "unsupported_certificate" alert
> and (possibly) replace with a reference to the set of alerts that
> might be sent instead.

It can be quite difficult for users to understand why a remote peer
aborted the TLS handshake.  More specific alerts are quite helpful.
Distinguishing between expiration and insufficiently strong keys or
digests, etc., makes troubleshoots easier and does not compromise
sensitive cryptographic material.

-- 
	Viktor.


From nobody Fri May 12 06:51:24 2017
Return-Path: 
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 2C3B612EC3A for ; Fri, 12 May 2017 06:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level: 
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 GAOatRV25gWS for ; Fri, 12 May 2017 06:51:21 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE40A1294FA for ; Fri, 12 May 2017 06:46:13 -0700 (PDT)
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id D7C7B1D5A for ; Fri, 12 May 2017 14:46:11 +0100 (BST)
Received: by mail-it0-f51.google.com with SMTP id c15so10786716ith.0 for ; Fri, 12 May 2017 06:46:11 -0700 (PDT)
X-Gm-Message-State: AODbwcCExDTSi+atF4y7lmlyybXTuQkZj+nOnrqTpSztexS/Xn5ztYHJ 8mypnTSwuXoqOeomn3Rvx3bDaWMVUg==
X-Received: by 10.36.131.137 with SMTP id d131mr3717167ite.113.1494596770269;  Fri, 12 May 2017 06:46:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.127.79 with HTTP; Fri, 12 May 2017 06:46:09 -0700 (PDT)
In-Reply-To: <29AB09F3-AD52-4DE8-AD28-B76CB6AB6B1D@dukhovni.org>
References:    <29AB09F3-AD52-4DE8-AD28-B76CB6AB6B1D@dukhovni.org>
From: Matt Caswell 
Date: Fri, 12 May 2017 14:46:09 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: TLS WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Alerts
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 May 2017 13:51:23 -0000

On 11 May 2017 at 21:06, Viktor Dukhovni  wrote:
>
>> On May 11, 2017, at 4:21 AM, Matt Caswell  wrote:
>>
>> If the view is that the more specific alerts are helpful, then I'd
>> suggest amending the wording in the "Server Certificate Selection"
>> section to remove the bit about the "unsupported_certificate" alert
>> and (possibly) replace with a reference to the set of alerts that
>> might be sent instead.
>
> It can be quite difficult for users to understand why a remote peer
> aborted the TLS handshake.  More specific alerts are quite helpful.
> Distinguishing between expiration and insufficiently strong keys or
> digests, etc., makes troubleshoots easier and does not compromise
> sensitive cryptographic material.

That seems reasonable to me.

https://github.com/tlswg/tls13-spec/pull/1013

Matt


From nobody Fri May 12 07:47:56 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A04712EC43; Fri, 12 May 2017 07:47:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: The IESG , Sean Turner , draft-ietf-tls-rfc4492bis@ietf.org, Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org, sean@sn3rd.com, tls-chairs@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149460046103.13483.10879441412915115092.idtracker@ietfa.amsl.com>
Date: Fri, 12 May 2017 07:47:41 -0700
Archived-At: 
Subject: [TLS] Protocol Action: 'Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier' to Proposed Standard (draft-ietf-tls-rfc4492bis-17.txt)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 12 May 2017 14:47:41 -0000

The IESG has approved the following document:
- 'Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
   Security (TLS) Versions 1.2 and Earlier'
  (draft-ietf-tls-rfc4492bis-17.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working
Group.

The IESG contact persons are Kathleen Moriarty and Eric Rescorla.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/





Technical Summary

 This document adds Elliptic Curve Cryptography (ECC) cipher suites to
 TLS 1.0-1.2.  These cipher suites have some technical
 advantages over the currently defined RSA and DH/DSS cipher suites in
 terms of key size and performance.  This document does not entail any
 changes to the TLS base specification.

 Note that Appendix B lists the changes from RFC 4492.

Working Group Summary

 The WG was able to achieve consensus on advancing this
 document to Proposed Standard.  Moving RFC 4492 to Standards
 Track was the main reason for the draft.  It seemed odd to specify
 MTI algorithms based on ECC in TLS1.3 and have the TLS1.0-1.2
 RFC for the same algorithms be Informational.

Note that we needed to consult the CFRG on the "use of contexts".
Our thanks to them for contributing to this work.

Document Quality

 This is a bis draft so the majority of the draft has been reviewed by
 the IETF already.  The -00 version of the individual draft allows easy
 diff to what was published as RFC 4492.  Note that more was taken
 out than put in.

Personnel

 Sean Turner is the Document Shepherd.
 Kathleen Moriarty is the responsible AD.


From nobody Fri May 12 19:11:16 2017
Return-Path: 
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 9933212EBC6 for ; Fri, 12 May 2017 19:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8OZroHmGcFMH for ; Fri, 12 May 2017 19:11:14 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C15129B26 for ; Fri, 12 May 2017 19:08:18 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id q125so18098398pgq.2 for ; Fri, 12 May 2017 19:08:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=hfDOzwYpxTAPM5vjodUUQSsSlkIAZ5ttCxFEZLF+i4U=; b=YWTPZYPDQuVonCT5CyUSd+rONOw1tak/1BC0ON7XRA3jcNcC7MUzP2g7KgogtxSYuO K/rquM5fjRRn10I4evlwBkh5NoaBgPL2FpakNV4NFJjjGaJP6uIA82RxN5qvge9SCsnM ABuWYweZmug2+F90tUaF2por4XdczGRJlreXjPc2xov3iR25RDcRJEfhEu68/hTGHUmz lgGIhtXIr/FbB8T7uV7cFDlKRq/KwUM1QnFbGJnXfZX66c2PnSOFu4Iz733DpcIPkWJq jVQ3aaxh1KiNH9ZYS0Y5agvg2xX6oBhX3DPWcGhmIkbIuHC60rS9GtvmX4Jf6NeZB46v KXTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hfDOzwYpxTAPM5vjodUUQSsSlkIAZ5ttCxFEZLF+i4U=; b=UH2LCmXhbXQ9XIsh8C/7HTMhbLXRsGH5BNiLWxUPA8Uv2Ra4tt2QrRXYzHQ7Tn6VHk ssajTmJMeJSZdx/OO2M4jqLSeb+qpnLixsOfiSKUydELAAJfwJ0q7kPbpl1FScHOIF7i oc5KMCnRGWzI62PZ8e+reMdALm+MElw6pLqL6tFJ5ZmUyDlSRS81Mi2k2Qb53eUo3Mbz vO9zwxHGBkAMQyC9Zra35S9eog52iDrnCYYCe0wTAc1YPR5jt6HWGzdVnyglWSKnEsjK 1Z7AzwjRfrWIGRPx7E/KV/jGGvEBK+LAP2/fKSMWLNz1/OrqE06Z5Oumn3fN9HoIV7Qn NLdQ==
X-Gm-Message-State: AODbwcAq5+xLd165LSzmlEl2I9joek2iHA0aREIr30YVqb46eF+klwJ2 h4O9fY5uuml50XLw3KUbpse+XygRMM5Y
X-Received: by 10.98.141.199 with SMTP id p68mr3803527pfk.55.1494641298216; Fri, 12 May 2017 19:08:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.161.226 with HTTP; Fri, 12 May 2017 19:07:37 -0700 (PDT)
From: Kathleen Moriarty 
Date: Fri, 12 May 2017 22:07:37 -0400
Message-ID: 
To: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 02:11:16 -0000

Hello,

Thank you all for your work on TLS 1.3.  The list has still been
active on a few topics, so I want to see how that all settles out in
addition to the questions I have on the draft below.

Introduction:

1. Since this is going for IETF last call soon and there has been
review of the draft (workshop, but is clearly ongoing from the list
discussions), should the first sentence of the Introductions be
removed?

   DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
   significant security analysis.

2. Section 4.2.9 - There should be some mention or pointer to the
security considerations and recommendations on replay attacks for
0-RTT from this section.  I don't see any mention of discouraging
0-RTT from being a default and think that would be good for
applications that use TLS expecting replay protection.  I know the WG
agreed to keeping 0-RTT, but I think it's very important to make the
issues clear and not have this come up as a default in any
implementation/deployment for unsuspecting users.  Part of this will
get down to implementation specifics and configuration options, but
offering some guidance is important. This document will be read by
many, not just developers.

Since clients have to initiate 0-RTT, the user has to have some idea
that replay attacks are possible and accept that risk.  If this were
used in web applications, then all servers that don't want to see
replay attacks (banking, etc.), would have to have explicitly reject
this usage.  As such, there needs to be very strong guidance to this
point. Would it be that browsers configure this as a default or
something users would have to turn on or just leave it as an option
(with warnings) for a client to enable?  Would servers have clear
information in configuration files (or setup) about the implications
of this option for those that don't read the RFC and are not aware of
this problem?

Most of this discussion belongs directly in the security consideration
section, but there has to be mention of it with a reference from
section 4.2.9.  It's not just an API consideration, this is for
developers, implementers, and users of the protocol. Many other
protocols use TLS beside HTTP and do so with the expectation of replay
protection.

While Appendix C1 is helpful, I don't think it's enough.  It's
disappointing to see a protocol with a replay attack written as a
prominent feature of TLS 1.3 and little discouragement from use.


3. Section 4.2.

   "In general, detailed certificate validation procedures are out of
   scope for TLS (see [RFC5280]).  This section provides TLS-specific
   requirements."

I don't see an explanation of why it is out-of-scope.  The reference
is just to RFC5280, which seems odd.  I would expect the reference to
be to something that explains why it is out-of-scope.

RFC7525 has use of RFC5280 as a best practice for server identity
verification and revocation checks for TLS 1.2.  Is this just for TLS
1.3?  Why?
RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
explanation here would be helpful since this seems to be a departure
(or reference to the changes section).

If RFC5280 remains out-of-scope, this section should fully describe
the certificate validation process for TLS 1.3. I think you need to
list out everything that should be checked as opposed to just
including one example:

   "Also, if some aspect of the certificate chain was
   unacceptable (e.g., it was not signed by a known, trusted CA), the
   server MAY at its discretion either continue the handshake
   (considering the client unauthenticated) or abort the handshake."


4. Section 6.2 Error Alerts

In addition to sending the error, I don't see any mention of the error
being logged on the server side, shouldn't that be specified?  Logging
errors (at least in debug modes when needed) provides valuable
troubleshooting information and many applications don't do an adequate
job of logging, so I think it's important to call that out here as a
recommendation.



-- 

Best regards,
Kathleen


From nobody Fri May 12 20:01:59 2017
Return-Path: 
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 BF67112942F for ; Fri, 12 May 2017 20:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 trnOkor3SP5D for ; Fri, 12 May 2017 20:01:55 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240431293FD for ; Fri, 12 May 2017 19:58:52 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id y201so61648066qka.0 for ; Fri, 12 May 2017 19:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=n4r+Y+GSXfHWVMfWeraWL8r3J5iKZq8ekRO9CE5U8bw=; b=vcBj3xQHsUGMq2qFwmU2zPz22Me5gvkWKUsZoR2Wb31moxBkaapNykqhfZcI33xIzl AA2qBHwroe7i0AqAiJN60nmFwD79zJLU+57EhUI7Uhapi7nAa1tQ+9ThIG8YhqYdVK23 ++PdpXQLtId1lhn8HOsco66vwu4oJl661o1rsqtND4UqQrME90NhhBGl6dwsMgZvlgCv MYflH+gh2aCj0S3VgRRhs66PeE9pTcCQvBCz339+na3KSIQJfo5SBJHkwtREZck7wpkc hc8NgfCUHQQ81yHEOgS3GcIHY+ZSRA9nzk5Xt0VV5RkNh63RIuYm296SAnNwN3d7tHoH oY6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=n4r+Y+GSXfHWVMfWeraWL8r3J5iKZq8ekRO9CE5U8bw=; b=tEA1PepJWxyfjuujI6cYtvolp3e1GoEd+lKpXxjtKiS/Bi17uxzyVzd4r7t0Wkuq5f dgawTVipyCS6TL4NyvmTgmjyhUYY0orh4ylYtdpsO+5L7VNaNXEMuT1RGDa3S2wt+QJ2 EHx+2N53ULe0PjmGQEZCEWS41SEb0BiCKOAa5mLgvHSLQv7pjpQiymlZWZHajJgNnUP7 Letr8q3mgluja7iPvCQHZpyzDNJEGlZOkLIA0Pc+Zjv48H9hW+pahFsEleFn75GNdQQo iTo8nCyyzD/Mb+HHuhRXC+gua4qQ8+91tkdSyUEXBg+TFEScPxSxqfuSIs/JQGLeqizA g39g==
X-Gm-Message-State: AODbwcAqBu80+tvOTT/FFZVK6oqg08NDV4YQ+0MpTUIlXf9yG1Ht3clU cMZ9ReH/gDNsMQ==
X-Received: by 10.55.90.199 with SMTP id o190mr2285883qkb.120.1494644331211; Fri, 12 May 2017 19:58:51 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id f201sm2223196qka.59.2017.05.12.19.58.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 12 May 2017 19:58:50 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 12 May 2017 22:58:48 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>  <87ziekihp6.fsf@fifthhorseman.net>
In-Reply-To: <87ziekihp6.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201705122258.49117.davemgarrett@gmail.com>
Archived-At: 
Subject: [TLS]  Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 03:01:57 -0000

On Wednesday, May 10, 2017 03:28:48 pm Ilari Liusvaara wrote:
> On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> > Yes, encrypted SNI was discussed and ultimately rejected.
> > 
> > But do we really have to send the literal value? Don't we need to just make 
> > sure that the client and server agree on the host that the client wants to 
> > connect?
> > 
> > Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
> > the salt and the resulting hash, making the server calculate the same hash 
> > with each of the virtual host names it supports and comparing with the client 
> > provided value?
> 
> What makes encrypting SNI nasty is replay attacks.
> 
> There also was proposal for putting SNI mapping into DNS (which limits the
> leakage if DNS lookups are private). However, I came up with a way to use
> that to attack HTTPS (the usual "default vhost" attacks).

On Wednesday, May 10, 2017 04:24:05 pm Daniel Kahn Gillmor wrote:
> On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> > It certainly was. But then the clear text SNI is a gaping privacy hole
> > in TLS, the kind of issue that should keep us awake at night until it is
> > resolved. We need to make sure that we make progress, rather than rehash
> > the old arguments. Maybe we should invest some time and document the
> > various proposals in a draft. I am willing to work on that. Any other
> > volunteers?
> 
> I agree with Christian's assessment of the problem, and i'd be
> interested in collaborating on such a draft.
> 
> The DNS folks are making strides to protect name information (the other
> main place where this kind of data is leaking).  TLS needs to keep up.

Encrypted SNI has been talked to death, and coming up with new schemes that warrant air quotes in the subject around "encrypted" feels like a waste of time. Wouldn't it be better to just focus on finishing the encrypt-all-the-things approach and plan out a way to distribute a host DH key (+ a few params, e.g. port(s)+protocol(s) to use with encrypted hellos) via DNS to encrypt everything straight from the ClientHello? Stick a supported_groups in there as well and we can make HRR unneeded while we're at it. This would also protect against 3rd parties attempting to fingerprint clients via ClientHello parameters. (probably a few other things that could be listed that could be helped, too)

Simply put, some of us were convinced a while ago that encrypted SNI isn't nearly as useful as it first seems, however fully encrypted hellos address that problem and more. I think it'd be better to work towards a more complete solution here than just worrying about SNI.


Dave


From nobody Fri May 12 20:20:28 2017
Return-Path: 
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 E10EA12EA8C for ; Fri, 12 May 2017 20:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 I0VEqvzbteUp for ; Fri, 12 May 2017 20:20:20 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22201275AB for ; Fri, 12 May 2017 20:17:51 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d9NYz-0006sa-Gp for tls@ietf.org; Sat, 13 May 2017 05:17:49 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d9NYw-0007jy-WA for tls@ietf.org; Fri, 12 May 2017 23:17:47 -0400
Received: (qmail 25325 invoked from network); 13 May 2017 03:17:46 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 May 2017 03:17:46 -0000
To: Dave Garrett , tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>  <87ziekihp6.fsf@fifthhorseman.net> <201705122258.49117.davemgarrett@gmail.com>
From: Christian Huitema 
Message-ID: <156700d9-b0fa-fbee-befe-7245bc768ab5@huitema.net>
Date: Fri, 12 May 2017 20:17:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <201705122258.49117.davemgarrett@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.234
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.26)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49FXKwZbSflcvTu2SSy6NnOlTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpFhIrfazkiIQ2S64PDBtdgRcOb18WfxGyg6Om6u4YYmyY2Uciy+YsO2eLh j7pTswg5hjoyEb9Oq0NWpyO3vrfYzS02aeiYw+GANPqwVsDMNz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBcKaDTe3QRRhTm1Fh3Md1t3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0VTUxNuBj oncVGg5uN2OqgLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa3gnTgPyST4gCHH+dS+0nfbQ44+/NmJ+fq0I Iixf9GclxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 03:20:27 -0000

On 5/12/2017 7:58 PM, Dave Garrett wrote:
> Encrypted SNI has been talked to death, and coming up with new schemes =
that warrant air quotes in the subject around "encrypted" feels like a wa=
ste of time. Wouldn't it be better to just focus on finishing the encrypt=
-all-the-things approach and plan out a way to distribute a host DH key (=
+ a few params, e.g. port(s)+protocol(s) to use with encrypted hellos) vi=
a DNS to encrypt everything straight from the ClientHello? Stick a suppor=
ted_groups in there as well and we can make HRR unneeded while we're at i=
t. This would also protect against 3rd parties attempting to fingerprint =
clients via ClientHello parameters. (probably a few other things that cou=
ld be listed that could be helped, too)
The "server DH Key" poses a significant forward secrecy issue. Suppose
that the key is compromised. Now the secret police can find out what
nasty sites was accessed by whom. That can be plus plus not good for
said dissidents.
> Simply put, some of us were convinced a while ago that encrypted SNI is=
n't nearly as useful as it first seems, however fully encrypted hellos ad=
dress that problem and more. I think it'd be better to work towards a mor=
e complete solution here than just worrying about SNI.
EKR did propose a TLS in TLS tunnel back in December 2015:
https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw.
It would effectively encrypt the "inner" Client Hello.

-- Christian Huitema


From nobody Fri May 12 22:23:16 2017
Return-Path: 
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 B3F24127B5A for ; Fri, 12 May 2017 22:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5cZpEt-I3Tjo for ; Fri, 12 May 2017 22:23:13 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB6C12944A for ; Fri, 12 May 2017 22:21:09 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id y201so62667629qka.0 for ; Fri, 12 May 2017 22:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=LoqyiocEvUm4wyf5Je90THIJtI40CZczKDSEXkMNsG4=; b=S7gMhmRw7nKrE9rPboCLjn9rVTWqMo0WD1TjtWm6ahQdy/CCjpmtoeXr4coxT3mGpc A9Ut9jDsD/buruIAjH0RUEpbLucf27d2ZwpuyuyswxieG4/GIJQRlo7FNSv8jPBMyWv7 5oEIaA2FNYamvEu25k5UUYACGDkihsJivTsYvEhmUObCI2rV+E8dUb0vc5KrMJRgH8yV tzWEfbQ/01Ryf69L0+lrGWZHB4JCMKvF+RV1hD7hayqJurW/g+u3HDTKINB1/UZ8gyRa PmuLvZiQBPmg853O73CcInAD6Y3VwyZ6CbVLU4NAoB7qgS5XzpeQ3Fk4S+/lDmTxbR5h u7sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=LoqyiocEvUm4wyf5Je90THIJtI40CZczKDSEXkMNsG4=; b=qir9U/X1LqM80kbc+WjNtAcDbVbbKOJpLP27aOCb0I+lmNViG9e52N47fV2GmeOraC d2mHpfFEAeESbCxp1PsRawJIBWpI+UKr1KGUg3DOqfgqGYISqu6UU3CWr2HEZbu82S4J HZZzGfIpGDUGYpQZY862+mRkukRQ82xF0gIVmT/NlmNuApNJIbyb91q0VWdeXXbED7Dm 4W7LVw+bfPhT73019rlDU3xIxmrAjBcT0Z6ov7AgCvIWZ9Rzbbh2kYgEYDdddEMKQqLw YDPErv+cb/sIkepJF0XxbT9e0gbfjH1pzhaJZQRctD7ozG9hkLKkEGpXC9rA5S8CAbuw aPxA==
X-Gm-Message-State: AODbwcBhxXybpKPuN2se84NC/uh7qyywhxTWGW+keJw1EWgBG7JtJeSa 34OjaQuiviGuZw==
X-Received: by 10.55.204.23 with SMTP id r23mr7419356qki.72.1494652868657; Fri, 12 May 2017 22:21:08 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id k184sm3821369qkb.48.2017.05.12.22.21.07 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 12 May 2017 22:21:08 -0700 (PDT)
From: Dave Garrett 
To: Christian Huitema 
Date: Sat, 13 May 2017 01:21:06 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
Cc: tls@ietf.org, Daniel Kahn Gillmor , Ilari Liusvaara , Hubert Kario 
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <201705122258.49117.davemgarrett@gmail.com> <156700d9-b0fa-fbee-befe-7245bc768ab5@huitema.net>
In-Reply-To: <156700d9-b0fa-fbee-befe-7245bc768ab5@huitema.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Message-Id: <201705130121.06879.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 05:23:15 -0000

On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> The "server DH Key" poses a significant forward secrecy issue. Suppose
> that the key is compromised. Now the secret police can find out what
> nasty sites was accessed by whom. That can be plus plus not good for
> said dissidents.

*This is the current situation.* "If the fix is broken, then it won't be fixed anymore" is not really that compelling of an argument, by itself.

Of course the host DH key has an FS risk; it'd need to have a limited validity time and be rotated regularly. (probably weekly) The private key would need to be protected and managed by the host (not the virtual servers), and the public key would need to be given to the virtual servers to be listed in DNS for their domains. An attacker that can get that private key can revert the security to the current status quo, but the handshake would still set up an ephemeral DH key for FS of everything after the hellos (as is the current case, with the well known caveats with 0RTT data).

An attacker that can reliably exfiltrate or completely control that key/host will almost certainly be able to surviel which virtual hosts are connected to no matter what we do. (or more precisely, I think that any gains you can make there are likely to be a lost cause) The only simple solution virtual servers have there is to not use a host you can't actually trust.

Of course, if everyone just switched to IPv6, everyone can get their own unique IP, the offending virtual server nonsense becomes obsolete, and servers could opt-out of SNI entirely (e.g. via a flag in DNS). (yeah, those IPs are of course trackable, though more easily rotatable, but you're not going to get a perfect solution here without something like Tor)

> EKR did propose a TLS in TLS tunnel back in December 2015:
> https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw.
> It would effectively encrypt the "inner" Client Hello.

Same basic concept, different implementation. TLS tunneling would provide some backwards compatibility; ClientHellos would still look like ClientHellos. I was just suggesting the simple generic route of encrypting everything in a non-backwards-compatible way (sent to a specified port that is set up to only handle that and reject everything else). I'd rather let stupid/incompatible stuff just break if we're designing a new opt-in system.

The argument I'm making here isn't about implementation; it's about what to think about implementing to deal with the issues here.


Dave


From nobody Sat May 13 11:12:43 2017
Return-Path: 
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 12A4B12E856 for ; Sat, 13 May 2017 11:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 rkj3wgpLjHlo for ; Sat, 13 May 2017 11:12:39 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4D3129411 for ; Sat, 13 May 2017 11:10:01 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id 132so1996472ybq.1 for ; Sat, 13 May 2017 11:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7G6ZAEdPen+ege1yvKbdEzXLtzycwVBnxFxVTYt0Kos=; b=FWiROjyN6sN69j/WACXpnak5UqWT0F21dCvxcF+8vouGnsfq8zWxoPBsKGUPyfG0OI KeHhwVklXQyO5mTsKMsWxn3CxgR00CgATfrpgbO/0EQSMhIYPz3eZnBP2qehAnCE8NnZ tyc2S8MjoQPpEyTT5B5jTj3oRLfJHqhzizdgaqa3Neeq7t28OHF4KY98Og5cx9wF0s47 PaHcGRBQ/jaOBsnDYfJiFWtQv7XUNeXx+MTGVaRsf03iHt68wIsBDWEMmOhivlXDDfsb SzVYiqnpL4FModRg+3DOapfu5YxNSbLrA4SLZj+myLPtS5DoerPNj9m5QPelbCbUK1fw /4nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7G6ZAEdPen+ege1yvKbdEzXLtzycwVBnxFxVTYt0Kos=; b=am8QyH42vcJUau+UtX5SbboSNCzGlerj8oq4tBXbYO/jtHOMC0ICJcI90IMJ9h6fOm Tz0LsCzpo51MzSvS69RyEXe4EkqPo0umOiA/3RTT0QAQJObhPjHlhose5fp3yPrxI8yE aFYJEshiBASlTNCaXY4Nxxaeh6DCf7RVNEuEjRO+1sUeuJatCEZ8qHJkRi1Z6SwgwT1k UNIfHaiQIZOsPhyICbNs/1UQZcAt5XqxFfwCSHlnZifi+X+BpdJ/yx5Sg6e2NSU4AepG CYt/UDqVefDuEUfJRD6JAed0YlHhA8ds0TJ3liaRKrZ/St+xjfDtSCJ3nJcKV+UozR5T vP6g==
X-Gm-Message-State: AODbwcBUSLbTgjUNtWcoJB+naUcuoWlzQrhYeqSjENbCTNRazttCIy1r qPFEfpW265k3s5MSfJaQmPsMA/n9bw==
X-Received: by 10.37.220.15 with SMTP id y15mr7856032ybe.16.1494699000946; Sat, 13 May 2017 11:10:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Sat, 13 May 2017 11:09:20 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Sat, 13 May 2017 11:09:20 -0700
Message-ID: 
To: Kathleen Moriarty 
Cc: "" 
Content-Type: multipart/alternative; boundary="94eb2c18f092ff76fb054f6bba4c"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 18:12:42 -0000

--94eb2c18f092ff76fb054f6bba4c
Content-Type: text/plain; charset="UTF-8"

Hi Kathleen,

Thanks for your review.


> 1. Since this is going for IETF last call soon and there has been
> review of the draft (workshop, but is clearly ongoing from the list
> discussions), should the first sentence of the Introductions be
> removed?
>
>    DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
>    significant security analysis.

Yeah, we'll remove this.


> 2. Section 4.2.9 - There should be some mention or pointer to the
> security considerations and recommendations on replay attacks for
> 0-RTT from this section.  I don't see any mention of discouraging
> 0-RTT from being a default and think that would be good for
> applications that use TLS expecting replay protection.  I know the WG
> agreed to keeping 0-RTT, but I think it's very important to make the
> issues clear and not have this come up as a default in any
> implementation/deployment for unsuspecting users.  Part of this will
> get down to implementation specifics and configuration options, but
> offering some guidance is important. This document will be read by
> many, not just developers.
>
> Since clients have to initiate 0-RTT, the user has to have some idea
> that replay attacks are possible and accept that risk.  If this were
> used in web applications, then all servers that don't want to see
> replay attacks (banking, etc.), would have to have explicitly reject
> this usage.  As such, there needs to be very strong guidance to this
> point. Would it be that browsers configure this as a default or
> something users would have to turn on or just leave it as an option
> (with warnings) for a client to enable?  Would servers have clear
> information in configuration files (or setup) about the implications
> of this option for those that don't read the RFC and are not aware of
> this problem?
>
> Most of this discussion belongs directly in the security consideration
> section, but there has to be mention of it with a reference from
> section 4.2.9.  It's not just an API consideration, this is for
> developers, implementers, and users of the protocol. Many other
> protocols use TLS beside HTTP and do so with the expectation of replay
> protection.
>
> While Appendix C1 is helpful, I don't think it's enough.  It's
> disappointing to see a protocol with a replay attack written as a
> prominent feature of TLS 1.3 and little discouragement from use.

I agree this should figure more prominently. I'm working on a PR
for this now which addresses at least some of these points, so
I'll hold off on responding to this for now and maybe we can
revisit once that PR has been completed.


> 3. Section 4.2.
>
>    "In general, detailed certificate validation procedures are out of
>    scope for TLS (see [RFC5280]).  This section provides TLS-specific
>    requirements."
>
> I don't see an explanation of why it is out-of-scope.  The reference
> is just to RFC5280, which seems odd.  I would expect the reference to
> be to something that explains why it is out-of-scope.

In general, TLS's policy (dating back to TLS 1.0) has been that the
job of TLS is to carry the certificates and other authentication
material but to leave it up to other parts of the system to
interpret them. It's been a long time since that decision was made,
but from my perspective, there are a number of major reasons:

1. Most of PKI processing (path construction, etc.) is generic and
   not specific to TLS. What is specific to TLS is:

   * How to indicate what your PKI capabilities are
     (see, e.g, S 4.2.4 and 4.3.2)
   * How to stuff the PKI material into the protocol
     (principally S 4.4.2)
   * How to determine whether a given certificate is suitable for
     use in TLS 4.4.4.2 and 4.3.2.1).

   So we want to outsource the generic PKI part


2. It matches the software architecture that people often use,
   which is to have a TLS stack but separate PKI validation. For
   instance, Firefox uses NSS for TLS but moz::pkix for
   validation. Similarly, Chrome uses BoringSSL for TLS
   but the system PKI libraries for validation.


In this case, I think that this text was more intended to
say "and go read 5280 to learn how to do this". To that end,
I suggest we say"


    "In general detailed certificate validation procedures are out of
    scope for TLS. [RFC5280] provides general procedures for
    certificate validation. This section provides TLS-specific
    requirements."


> RFC7525 has use of RFC5280 as a best practice for server identity
> verification and revocation checks for TLS 1.2.  Is this just for TLS
> 1.3?  Why?

I think that these requirements apply equally to TLS 1.3, it's
just that 7525 is older.


> RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
> explanation here would be helpful since this seems to be a departure
> (or reference to the changes section).

This is part of our generalized attempt to update to point to
the latest RFCs in our references. I'll add something to the
references section.
https://github.com/tlswg/tls13-spec/issues/1015


> If RFC5280 remains out-of-scope, this section should fully describe
> the certificate validation process for TLS 1.3. I think you need to
> list out everything that should be checked as opposed to just
> including one example:
>
>    "Also, if some aspect of the certificate chain was
>    unacceptable (e.g., it was not signed by a known, trusted CA), the
>    server MAY at its discretion either continue the handshake
>    (considering the client unauthenticated) or abort the handshake."

In general, I think we'd prefer to avoid providing a catalog of
all the ways that things can go wrong, because there are a lot.
The point of the text here is just supposed to be that servers
don't have to fail if they ask for client auth but they are then
sad about what the client provides. That's actually generally kind
of true, but it's more obvious with client auth because in many
cases the server has many ways of authenticating the client and
can fall back if it doesn't like the cert.


> 4. Section 6.2 Error Alerts
>
> In addition to sending the error, I don't see any mention of the error
> being logged on the server side, shouldn't that be specified?  Logging
> errors (at least in debug modes when needed) provides valuable
> troubleshooting information and many applications don't do an adequate
> job of logging, so I think it's important to call that out here as a
> recommendation.

I agree. I think it would be useful to say something about this. I've
filed https://github.com/tlswg/tls13-spec/issues/1014 to track this.

-Ekr


On Fri, May 12, 2017 at 7:07 PM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> Hello,
>
> Thank you all for your work on TLS 1.3.  The list has still been
> active on a few topics, so I want to see how that all settles out in
> addition to the questions I have on the draft below.
>
> Introduction:
>
> 1. Since this is going for IETF last call soon and there has been
> review of the draft (workshop, but is clearly ongoing from the list
> discussions), should the first sentence of the Introductions be
> removed?
>
>    DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
>    significant security analysis.
>
> 2. Section 4.2.9 - There should be some mention or pointer to the
> security considerations and recommendations on replay attacks for
> 0-RTT from this section.  I don't see any mention of discouraging
> 0-RTT from being a default and think that would be good for
> applications that use TLS expecting replay protection.  I know the WG
> agreed to keeping 0-RTT, but I think it's very important to make the
> issues clear and not have this come up as a default in any
> implementation/deployment for unsuspecting users.  Part of this will
> get down to implementation specifics and configuration options, but
> offering some guidance is important. This document will be read by
> many, not just developers.
>
> Since clients have to initiate 0-RTT, the user has to have some idea
> that replay attacks are possible and accept that risk.  If this were
> used in web applications, then all servers that don't want to see
> replay attacks (banking, etc.), would have to have explicitly reject
> this usage.  As such, there needs to be very strong guidance to this
> point. Would it be that browsers configure this as a default or
> something users would have to turn on or just leave it as an option
> (with warnings) for a client to enable?  Would servers have clear
> information in configuration files (or setup) about the implications
> of this option for those that don't read the RFC and are not aware of
> this problem?
>
> Most of this discussion belongs directly in the security consideration
> section, but there has to be mention of it with a reference from
> section 4.2.9.  It's not just an API consideration, this is for
> developers, implementers, and users of the protocol. Many other
> protocols use TLS beside HTTP and do so with the expectation of replay
> protection.
>
> While Appendix C1 is helpful, I don't think it's enough.  It's
> disappointing to see a protocol with a replay attack written as a
> prominent feature of TLS 1.3 and little discouragement from use.
>
>
> 3. Section 4.2.
>
>    "In general, detailed certificate validation procedures are out of
>    scope for TLS (see [RFC5280]).  This section provides TLS-specific
>    requirements."
>
> I don't see an explanation of why it is out-of-scope.  The reference
> is just to RFC5280, which seems odd.  I would expect the reference to
> be to something that explains why it is out-of-scope.
>
> RFC7525 has use of RFC5280 as a best practice for server identity
> verification and revocation checks for TLS 1.2.  Is this just for TLS
> 1.3?  Why?
> RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
> explanation here would be helpful since this seems to be a departure
> (or reference to the changes section).
>
> If RFC5280 remains out-of-scope, this section should fully describe
> the certificate validation process for TLS 1.3. I think you need to
> list out everything that should be checked as opposed to just
> including one example:
>
>    "Also, if some aspect of the certificate chain was
>    unacceptable (e.g., it was not signed by a known, trusted CA), the
>    server MAY at its discretion either continue the handshake
>    (considering the client unauthenticated) or abort the handshake."
>
>
> 4. Section 6.2 Error Alerts
>
> In addition to sending the error, I don't see any mention of the error
> being logged on the server side, shouldn't that be specified?  Logging
> errors (at least in debug modes when needed) provides valuable
> troubleshooting information and many applications don't do an adequate
> job of logging, so I think it's important to call that out here as a
> recommendation.
>
>
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c18f092ff76fb054f6bba4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Kathleen,

Thanks for your=
 review.


> 1. Since this is goin=
g for IETF last call soon and there has been
> review of the d=
raft (workshop, but is clearly ongoing from the list
> discuss=
ions), should the first sentence of the Introductions be
> rem=
oved?
>=C2=A0
> =C2=A0 =C2=A0DISCLAIMER: This is =
a WIP draft of TLS 1.3 and has not yet seen
> =C2=A0 =C2=A0sig=
nificant security analysis.

Yeah, we'll remove=
 this.


> 2. Section 4.2.9 - Ther=
e should be some mention or pointer to the
> security consider=
ations and recommendations on replay attacks for
> 0-RTT from =
this section.=C2=A0 I don't see any mention of discouraging
&=
gt; 0-RTT from being a default and think that would be good for
&=
gt; applications that use TLS expecting replay protection.=C2=A0 I know the=
 WG
> agreed to keeping 0-RTT, but I think it's very impor=
tant to make the
> issues clear and not have this come up as a=
 default in any
> implementation/deployment for unsuspecting u=
sers.=C2=A0 Part of this will
> get down to implementation spe=
cifics and configuration options, but
> offering some guidance=
 is important. This document will be read by
> many, not just =
developers.
>=C2=A0
> Since clients have to initi=
ate 0-RTT, the user has to have some idea
> that replay attack=
s are possible and accept that risk.=C2=A0 If this were
> used=
 in web applications, then all servers that don't want to see
> replay attacks (banking, etc.), would have to have explicitly reject<=
/div>
> this usage.=C2=A0 As such, there needs to be very strong gui=
dance to this
> point. Would it be that browsers configure thi=
s as a default or
> something users would have to turn on or j=
ust leave it as an option
> (with warnings) for a client to en=
able?=C2=A0 Would servers have clear
> information in configur=
ation files (or setup) about the implications
> of this option=
 for those that don't read the RFC and are not aware of
> =
this problem?
>=C2=A0
> Most of this discussion b=
elongs directly in the security consideration
> section, but t=
here has to be mention of it with a reference from
> section 4=
.2.9.=C2=A0 It's not just an API consideration, this is for
&=
gt; developers, implementers, and users of the protocol. Many other
> protocols use TLS beside HTTP and do so with the expectation of rep=
lay
> protection.
>=C2=A0
> While Ap=
pendix C1 is helpful, I don't think it's enough.=C2=A0 It's
> disappointing to see a protocol with a replay attack written as=
 a
> prominent feature of TLS 1.3 and little discouragement fr=
om use.

I agree this should figure more prominentl=
y. I'm working on a PR
for this now which addresses at least =
some of these points, so
I'll hold off on responding to this =
for now and maybe we can
revisit once that PR has been completed.=



> 3. Section 4.2.
>=
;=C2=A0
> =C2=A0 =C2=A0"In general, detailed certificate =
validation procedures are out of
> =C2=A0 =C2=A0scope for TLS =
(see [RFC5280]).=C2=A0 This section provides TLS-specific
> =
=C2=A0 =C2=A0requirements."
>=C2=A0
> I don&=
#39;t see an explanation of why it is out-of-scope.=C2=A0 The reference
> is just to RFC5280, which seems odd.=C2=A0 I would expect the r=
eference to
> be to something that explains why it is out-of-s=
cope.

In general, TLS's policy (dating back to=
 TLS 1.0) has been that the
job of TLS is to carry the certificat=
es and other authentication
material but to leave it up to other =
parts of the system to
interpret them. It's been a long time =
since that decision was made,
but from my perspective, there are =
a number of major reasons:

1. Most of PKI processi=
ng (path construction, etc.) is generic and
=C2=A0 =C2=A0not spec=
ific to TLS. What is specific to TLS is:

=C2=A0 =
=C2=A0* How to indicate what your PKI capabilities are
=C2=A0 =C2=
=A0 =C2=A0(see, e.g, S 4.2.4 and 4.3.2)
=C2=A0 =C2=A0* How to stu=
ff the PKI material into the protocol
=C2=A0 =C2=A0 =C2=A0(princi=
pally S 4.4.2)
=C2=A0 =C2=A0* How to determine whether a given ce=
rtificate is suitable for
=C2=A0 =C2=A0 =C2=A0use in TLS 4.4.4.2 =
and 4.3.2.1).
=C2=A0
=C2=A0 =C2=A0So we want to outsour=
ce the generic PKI part


2. It match=
es the software architecture that people often use,
=C2=A0 =C2=A0=
which is to have a TLS stack but separate PKI validation. For
=C2=
=A0 =C2=A0instance, Firefox uses NSS for TLS but moz::pkix for
=
=C2=A0 =C2=A0validation. Similarly, Chrome uses BoringSSL for TLS
=C2=A0 =C2=A0but the system PKI libraries for validation.


In this case, I think that this text was more inten=
ded to
say "and go read 5280 to learn how to do this". =
To that end,
I suggest we say"

=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 "=
;In general detailed certificate validation procedures are out of
=C2=A0 =C2=A0 scope for TLS. [RFC5280] provides general procedures for
=C2=A0 =C2=A0 certificate validation. This section provides TLS-spec=
ific
=C2=A0 =C2=A0 requirements."

<=
br>
> RFC7525 has use of RFC5280 as a best practice for server=
 identity
> verification and revocation checks for TLS 1.2.=C2=
=A0 Is this just for TLS
> 1.3?=C2=A0 Why?

I think that these requirements apply equally to TLS 1.3, it's
just that 7525 is older.


&g=
t; RFC3280 is cited for revocation in the TLS 1.2 RFC.=C2=A0 I think a litt=
le
> explanation here would be helpful since this seems to be =
a departure
> (or reference to the changes section).

This is part of our generalized attempt to update to point =
to
the latest RFCs in our references. I'll add something to t=
he
references section.


> If RFC5280 remains out-of=
-scope, this section should fully describe
> the certificate v=
alidation process for TLS 1.3. I think you need to
> list out =
everything that should be checked as opposed to just
> includi=
ng one example:
>=C2=A0
> =C2=A0 =C2=A0"Also=
, if some aspect of the certificate chain was
> =C2=A0 =C2=A0u=
nacceptable (e.g., it was not signed by a known, trusted CA), the
> =C2=A0 =C2=A0server MAY at its discretion either continue the handsha=
ke
> =C2=A0 =C2=A0(considering the client unauthenticated) or =
abort the handshake."

In general, I think we&=
#39;d prefer to avoid providing a catalog of
all the ways that th=
ings can go wrong, because there are a lot.
The point of the text=
 here is just supposed to be that servers
don't have to fail =
if they ask for client auth but they are then
sad about what the =
client provides. That's actually generally kind
of true, but =
it's more obvious with client auth because in many
cases the =
server has many ways of authenticating the client and
can fall ba=
ck if it doesn't like the cert.


> 4. Section 6.2 Error Alerts
>=C2=A0
> In ad=
dition to sending the error, I don't see any mention of the error
=

> being logged on the server side, shouldn't that be specified?=
=C2=A0 Logging
> errors (at least in debug modes when needed) =
provides valuable
> troubleshooting information and many appli=
cations don't do an adequate
> job of logging, so I think =
it's important to call that out here as a
> recommendation=
.

I agree. I think it would be useful to say somet=
hing about this. I've


=


On Fri, May 12, 2=
017 at 7:07 PM, Kathleen Moriarty <kathleen.moriarty.ietf@g=
mail.com> wrote:
Hello,


Thank you all for your work on TLS 1.3.=C2=A0 The list has still been

active on a few topics, so I want to see how that all settles out in

addition to the questions I have on the draft below.



Introduction:



1. Since this is going for IETF last call soon and there has been

review of the draft (workshop, but is clearly ongoing from the list

discussions), should the first sentence of the Introductions be

removed?



=C2=A0 =C2=A0DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet see=
n

=C2=A0 =C2=A0significant security analysis.



2. Section 4.2.9 - There should be some mention or pointer to the

security considerations and recommendations on replay attacks for

0-RTT from this section.=C2=A0 I don't see any mention of discouraging<=
br>
0-RTT from being a default and think that would be good for

applications that use TLS expecting replay protection.=C2=A0 I know the WG<=
br>
agreed to keeping 0-RTT, but I think it's very important to make the
issues clear and not have this come up as a default in any

implementation/deployment for unsuspecting users.=C2=A0 Part of this will
get down to implementation specifics and configuration options, but

offering some guidance is important. This document will be read by

many, not just developers.



Since clients have to initiate 0-RTT, the user has to have some idea

that replay attacks are possible and accept that risk.=C2=A0 If this were
used in web applications, then all servers that don't want to see

replay attacks (banking, etc.), would have to have explicitly reject

this usage.=C2=A0 As such, there needs to be very strong guidance to this
point. Would it be that browsers configure this as a default or

something users would have to turn on or just leave it as an option

(with warnings) for a client to enable?=C2=A0 Would servers have clear

information in configuration files (or setup) about the implications

of this option for those that don't read the RFC and are not aware of
this problem?



Most of this discussion belongs directly in the security consideration

section, but there has to be mention of it with a reference from

section 4.2.9.=C2=A0 It's not just an API consideration, this is for
developers, implementers, and users of the protocol. Many other

protocols use TLS beside HTTP and do so with the expectation of replay

protection.



While Appendix C1 is helpful, I don't think it's enough.=C2=A0 It&#=
39;s

disappointing to see a protocol with a replay attack written as a

prominent feature of TLS 1.3 and little discouragement from use.





3. Section 4.2.



=C2=A0 =C2=A0"In general, detailed certificate validation procedures a=
re out of

=C2=A0 =C2=A0scope for TLS (see [RFC5280]).=C2=A0 This section provides TLS=
-specific

=C2=A0 =C2=A0requirements."



I don't see an explanation of why it is out-of-scope.=C2=A0 The referen=
ce

is just to RFC5280, which seems odd.=C2=A0 I would expect the reference to<=
br>
be to something that explains why it is out-of-scope.



RFC7525 has use of RFC5280 as a best practice for server identity

verification and revocation checks for TLS 1.2.=C2=A0 Is this just for TLS<=
br>
1.3?=C2=A0 Why?

RFC3280 is cited for revocation in the TLS 1.2 RFC.=C2=A0 I think a little<=
br>
explanation here would be helpful since this seems to be a departure

(or reference to the changes section).



If RFC5280 remains out-of-scope, this section should fully describe

the certificate validation process for TLS 1.3. I think you need to

list out everything that should be checked as opposed to just

including one example:



=C2=A0 =C2=A0"Also, if some aspect of the certificate chain was

=C2=A0 =C2=A0unacceptable (e.g., it was not signed by a known, trusted CA),=
 the

=C2=A0 =C2=A0server MAY at its discretion either continue the handshake

=C2=A0 =C2=A0(considering the client unauthenticated) or abort the handshak=
e."





4. Section 6.2 Error Alerts



In addition to sending the error, I don't see any mention of the error<=
br>
being logged on the server side, shouldn't that be specified?=C2=A0 Log=
ging

errors (at least in debug modes when needed) provides valuable

troubleshooting information and many applications don't do an adequate<=
br>
job of logging, so I think it's important to call that out here as a
recommendation.







--



Best regards,

Kathleen



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c18f092ff76fb054f6bba4c--


From nobody Sat May 13 13:27:48 2017
Return-Path: 
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 3C510129329 for ; Sat, 13 May 2017 13:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 4FpgAzKAWQFb for ; Sat, 13 May 2017 13:27:44 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A83F7129423 for ; Sat, 13 May 2017 13:24:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1BD66226A9; Sat, 13 May 2017 23:24:53 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id bdaciRD6GTeg; Sat, 13 May 2017 23:24:52 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id AC87B2313; Sat, 13 May 2017 23:24:52 +0300 (EEST)
Date: Sat, 13 May 2017 23:24:51 +0300
From: Ilari Liusvaara 
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= 
Cc: "Salz, Rich" , "tls@ietf.org" 
Message-ID: <20170513202451.GA14826@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>  <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>  <20170509181227.GA9346@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] The case for a single stream of data
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 20:27:47 -0000

On Tue, May 09, 2017 at 11:44:14AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara 
> wrote:

> 
> Because HTTP specification expressly forbids any and all updates and
> > writes using safe methods. Ignoring that causes very severe security
> > vulernabilities even today (e.g., causes essentially undefendable CSRF
> > attacks).
> >
> 
> These aren't browser requests, they can be SDK and other clients making
> HTTP API requests. That's much more common too, by volume. CSRF isn't an
> issue in cases like that.

Hope your API is actually idempotent, because the HTTP code, which sits
below the SDK code can replay requests on its own...
 
> I think everything I'm writing applies even for a careful REST-compliant
> case too. Even if the client is using PUT or POST or DELETE or whatever,
> the same kind of transactional semantics apply. All it takes is a
> disconnect between the settings in any of the middle transport layers and
> the expectations of the underlying protocol. I just think that disconnect
> is very predictable.

PUT and DELETE are also subject to autoretry. Which means that any
PUT or DELETE in failed 0-RTT can be immediately replayed as 1-RTT by
the HTTP code.

However, POST is not subject to autoretry. Which means that any POST
in failed 0-RTT must be reported to next layer as "error: connection to
server lost before reply was received". Which is the same error if
server somehow sent a TLS close_notify with pending POST (which is
considered autenticated close!).

(In HTTP/2, if the server explicitly refuses the stream POST is on,
that does not count as fatal failure, and the http library can
autoretry).

The next layer can then decide to retry the request upon getting the
connection lost error. However, in such situation, one _always_ needs
to handle possible reordering, _regardless_ of 0-RTT or TLS version!



Unified-stream model has the following to keep in mind:

- The client TLS library APIs must not be subject to races that may
  cause data corruption if server rejects 0-RTT (_including_ selecting
  different application-layer protocol).
- The 0-RTT data may not be suitable for replay, even if application-
  layer protocol matches. And 0-RTT containing HTTP POSTs is the not
  the only case even in HTTP (e.g. what Tokbind has specified so far
  renders such replay unsafe even for GET).



Two recommendations:

- Always require strong 0-RTT anti-replay, even accross servers. The
  attacks raising from failing to do this are just too severe and
  virtually impossible to address in any other way.
- Clients shall treat any 0-RTT data sent as potentially received by
  the server, _even_ if server refuses the 0-RTT.




-Ilari


From nobody Mon May 15 03:46:54 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7D0126E64; Mon, 15 May 2017 03:46:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu 
To: 
Cc: draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, ietf@ietf.org, tls@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149484519593.2843.448630358757818654@ietfa.amsl.com>
Date: Mon, 15 May 2017 03:46:35 -0700
Archived-At: 
Subject: [TLS] Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 15 May 2017 10:46:36 -0000

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-ecdhe-psk-aead-??
Reviewer: Dan Romascanu
Review Date: 2017-05-15
IETF LC End Date: 2017-05-18
IESG Telechat date: 2017-05-25

Summary:

This is a straight-forward and clear document that defines several new
cipher suites for the Transport Layer Security (TLS) protocol version
1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
with Pre-Shared Key (ECDHE_PSK) key exchange together with the
Authenticated Encryption with Associated Data (AEAD) algorithms
AES-GCM and AES-CCM. The document is well written and I appreciate the
effort to clarify in the Introduction the context, what was missing,
and why the document is necessary. The document is Ready, there is one
issue about support for TLS version 1.3 and higher that may need some
text clarification. 

Major issues:

Minor issues:

Section 4 ('Applicable TLS Versions') describes in details how the
cipher suites defined in the document make use of the authenticated
encryption with additional data (AEAD) defined in TLS 1.2 [RFC5246]
and DTLS 1.2 [RFC6347]. About TLS 1.3 it just says: 

' TLS 1.3 and above version, negotiate and support these cipher suites
in a different way.'

This may raise some concerns as 'in a different way' is ambiguous,
especially compared to the details included for TLS 1.2. Moreover, TLS
1.3 is still work-in-progress, and I believe that this document when
approved needs to wait for TLS 1.3 to be approved for publication.
Will anything change, or need to be added? Some better clarification
text would help IMO. 

Nits/editorial comments: 



From nobody Mon May 15 05:01:44 2017
Return-Path: 
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 877DC124BFA for ; Mon, 15 May 2017 05:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.223
X-Spam-Level: 
X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0KFLsFoTGvYE for ; Mon, 15 May 2017 05:01:40 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29816129AB6 for ; Mon, 15 May 2017 04:56:53 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E84C04E02D; Mon, 15 May 2017 11:56:51 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E84C04E02D
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E84C04E02D
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5E44E60465; Mon, 15 May 2017 11:56:51 +0000 (UTC)
From: Hubert Kario 
To: Dave Garrett 
Cc: Christian Huitema , tls@ietf.org, Daniel Kahn Gillmor , Ilari Liusvaara 
Date: Mon, 15 May 2017 13:56:44 +0200
Message-ID: <4227474.urTlPk55X7@pintsize.usersys.redhat.com>
In-Reply-To: <201705130121.06879.davemgarrett@gmail.com>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <156700d9-b0fa-fbee-befe-7245bc768ab5@huitema.net> <201705130121.06879.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1634888.hoYrUcqyKQ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 15 May 2017 11:56:52 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 12:01:42 -0000

--nextPart1634888.hoYrUcqyKQ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote:
> On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> > The "server DH Key" poses a significant forward secrecy issue. Suppose
> > that the key is compromised. Now the secret police can find out what
> > nasty sites was accessed by whom. That can be plus plus not good for
> > said dissidents.
>=20
> *This is the current situation.* "If the fix is broken, then it won't be
> fixed anymore" is not really that compelling of an argument, by itself.
>=20
> Of course the host DH key has an FS risk; it'd need to have a limited
> validity time and be rotated regularly. (probably weekly)

you then need mechanism to indicate which DNS key share client is using or =
all=20
the connections would start failing on key rollover. And have to deal with =
all=20
the "fun" stuff related to key rollovers.

> The private key
> would need to be protected and managed by the host (not the virtual
> servers)

yes, the key MUST be assigned to a specific IP, not virtual host

> > EKR did propose a TLS in TLS tunnel back in December 2015:
> > https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw.
> > It would effectively encrypt the "inner" Client Hello.
>=20
> Same basic concept, different implementation. TLS tunneling would provide
> some backwards compatibility; ClientHellos would still look like
> ClientHellos. I was just suggesting the simple generic route of encrypting
> everything in a non-backwards-compatible way (sent to a specified port th=
at
> is set up to only handle that and reject everything else). I'd rather let
> stupid/incompatible stuff just break if we're designing a new opt-in
> system.
>=20
> The argument I'm making here isn't about implementation; it's about what =
to
> think about implementing to deal with the issues here.

I respectfully disagree. That system requires tight coupling between the TL=
S=20
implementation and DNS. This is not something that facilitates TLS deployme=
nt.=20
We want more TLS/HTTPS deployment, not less.

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart1634888.hoYrUcqyKQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZGZd8AAoJEJKo0bgB0vX1u0EP/07zlCYYnBfRi7mM36ZXdoyP
YYnUeV2NwZ42laXp/H9n9VrEFd4UmDZqt2vpHw/h4OtW7N3dwFr43fXZPBUYg9NN
fV68AsBG0/8dCQO/UBNGIGyk+a+6YGAej6IkbcUnhSYxwWKlXE7Q45Hd0QawaGcX
ekOJyecx6DZrY0LdKjQbXwZX+jU3okhjVkoRgiwmfRj2Pr62Sb+hwPsK697TFSqZ
5331s03QtTvZQcQHfOKh6UE8vTYVouNAznPAC2H28u9iYjXiUIZYyxRB4QThEgZ8
ENoxLGzKwgeDwNNmp1BuAVV6TvDUDOuqCdq7h13J7HrjTJDuGw9+m0gWYoMDEDvS
YbSOXXRFo3qRm4I4oMCm2eSGvbGsBct28tXCzDTQITFRd3UlfqNX8rypOlRYMi30
olOA4pWT66cz1rygR0vGDekmrxg3YF6CULs9HW9sAkLCc+qGllj0YiRASzQqBpz2
Lf0OfR/rKb2ZrMTTwmz9j2oHcc54CZOdd134+BRRdzzddLN62U7+nAhKvAu0Mxtf
msBNS5gOpWJSJe7Uv6GGRj93YraPZvrwQKP8Md+d/x49SZJdUb4HSv9nTH5gSngJ
4d6AZ+X9Zsx/jQRMKqXh7z/8BIQMlJ+7dWQgPyfyBpDVUnut+equUsu9PuhEHNXI
4Cx9BIPr0EWrAc2S26xL
=BQiZ
-----END PGP SIGNATURE-----

--nextPart1634888.hoYrUcqyKQ--


From nobody Mon May 15 07:12:11 2017
Return-Path: 
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 19B6D126B6E for ; Mon, 15 May 2017 07:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 4vqcxuXjT32h for ; Mon, 15 May 2017 07:12:07 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C26812EB17 for ; Mon, 15 May 2017 07:05:53 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 709077A32F1 for ; Mon, 15 May 2017 14:05:52 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <98E0B43D-2225-460A-99EB-E0B67711FEC0@dukhovni.org>
Date: Mon, 15 May 2017 10:05:50 -0400
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] FYI: SMTP TLS Milestone
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 14:12:09 -0000

In the most recent Google email transparency reports:

	https://www.google.com/transparencyreport/saferemail/

we see for the first time an essentially equal (and some days slightly
greater) fraction of inbound and outbound email using STARTTLS.

Between Apr 15th and May 6th the STARTTLS use ranges are:

	Outbound: 85% -- 88%
	Inbound:  84% -- 87%

At current trends crossing 90% seems plausible within a year.  Non
STARTTLS SMTP is gradually heading for extinction.

-- 
	Viktor.


From nobody Mon May 15 09:51:00 2017
Return-Path: 
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 569751294B7 for ; Mon, 15 May 2017 09:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xf11k0rzJFEy for ; Mon, 15 May 2017 09:50:56 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339AD128954 for ; Mon, 15 May 2017 09:47:38 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id x64so43403122pgd.3 for ; Mon, 15 May 2017 09:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5n7XUCgIpu2DfWTkLj/2n9qcASiVVfR3We8Mt6kFRvs=; b=eTMXNt4/UFuiv92hxlTz6yXhtlXmnUcqlbCMci3CCcCL3Zwf7vBfWSAyi/09mumIO9 MJEgyBUC3+EKZHZ1AcYWt6SsNxcFZ6dmmbNH0PVTnxT4Ymwx4ZTUEIzld26Ic+7MfLET PQiwEm+RAyVky82AZzTFPAfvERE8xvZztc4ekCOse9sTEz+x/cqp8BDJeNg339VHk5JW UF3TAu5zx0V6gLkkgmlHOPgJ/DP7dxPs+cRaWy+t5Yeu2EO966mHTX5WSniE7FTTPLwc OVKrz1phWyY43vyCDUphk7gZSLBjCksMy2+0z4zuGjcw44/2iYPwikuNpIgxZu/K81I9 eReQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5n7XUCgIpu2DfWTkLj/2n9qcASiVVfR3We8Mt6kFRvs=; b=dOKXx/tiOvzqGAOnl0hVK0l9cc0AGtUgF8bUZac+vqMR+KQTR6wVk8wGH5bWwF4pWN mBdh+qc4X9N2OG/AYZk2Z539v7W90u9xQJmc/jF/VlhUs0igKMd4upO3tDF64UCTzGvE s0Xuv3IiacBiY6UzhQSTD4U/V1GQjCxbJk3dR/Mzk8UWd0XaLVRuzXv4DQY6nYycR1/i 4M+KSBj8JTUF5Vr5Iyu/FrpG0JHuxXcnW3z1UwIKtbumz6nwy/z+DGPPSB0i+fopBrgG Kl4VCm/yp2wavE1PwdJVSdcWuDV6E0XKbTVSvzh6WUxtScmJ4fLOi/Qh1pLlQXPPJU+A 09rQ==
X-Gm-Message-State: AODbwcBc6ZF0OLkb/H2UQGI28vnb0V1n3ZaT7BU/G7oCk6WdJCHT0MvJ lU0EDCUgVudyfdAGimXg+hWZhJE/uw==
X-Received: by 10.84.241.132 with SMTP id b4mr9831729pll.107.1494866857616; Mon, 15 May 2017 09:47:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Mon, 15 May 2017 09:46:56 -0700 (PDT)
In-Reply-To: 
References:  
From: Kathleen Moriarty 
Date: Mon, 15 May 2017 12:46:56 -0400
Message-ID: 
To: Eric Rescorla 
Cc: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 16:50:59 -0000

Hi Eric,

Thanks for your response.  Sorry for the delay, I'v been traveling.
The responses sound good, I do have a clarification and will respond
inline.

On Sat, May 13, 2017 at 2:09 PM, Eric Rescorla  wrote:
> Hi Kathleen,
>
> Thanks for your review.
>
>
>> 1. Since this is going for IETF last call soon and there has been
>> review of the draft (workshop, but is clearly ongoing from the list
>> discussions), should the first sentence of the Introductions be
>> removed?
>>
>>    DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
>>    significant security analysis.
>
> Yeah, we'll remove this.
>
>
>> 2. Section 4.2.9 - There should be some mention or pointer to the
>> security considerations and recommendations on replay attacks for
>> 0-RTT from this section.  I don't see any mention of discouraging
>> 0-RTT from being a default and think that would be good for
>> applications that use TLS expecting replay protection.  I know the WG
>> agreed to keeping 0-RTT, but I think it's very important to make the
>> issues clear and not have this come up as a default in any
>> implementation/deployment for unsuspecting users.  Part of this will
>> get down to implementation specifics and configuration options, but
>> offering some guidance is important. This document will be read by
>> many, not just developers.
>>
>> Since clients have to initiate 0-RTT, the user has to have some idea
>> that replay attacks are possible and accept that risk.  If this were
>> used in web applications, then all servers that don't want to see
>> replay attacks (banking, etc.), would have to have explicitly reject
>> this usage.  As such, there needs to be very strong guidance to this
>> point. Would it be that browsers configure this as a default or
>> something users would have to turn on or just leave it as an option
>> (with warnings) for a client to enable?  Would servers have clear
>> information in configuration files (or setup) about the implications
>> of this option for those that don't read the RFC and are not aware of
>> this problem?
>>
>> Most of this discussion belongs directly in the security consideration
>> section, but there has to be mention of it with a reference from
>> section 4.2.9.  It's not just an API consideration, this is for
>> developers, implementers, and users of the protocol. Many other
>> protocols use TLS beside HTTP and do so with the expectation of replay
>> protection.
>>
>> While Appendix C1 is helpful, I don't think it's enough.  It's
>> disappointing to see a protocol with a replay attack written as a
>> prominent feature of TLS 1.3 and little discouragement from use.
>
> I agree this should figure more prominently. I'm working on a PR
> for this now which addresses at least some of these points, so
> I'll hold off on responding to this for now and maybe we can
> revisit once that PR has been completed.
>

Thank you.
>
>> 3. Section 4.2.
>>
>>    "In general, detailed certificate validation procedures are out of
>>    scope for TLS (see [RFC5280]).  This section provides TLS-specific
>>    requirements."
>>
>> I don't see an explanation of why it is out-of-scope.  The reference
>> is just to RFC5280, which seems odd.  I would expect the reference to
>> be to something that explains why it is out-of-scope.
>
> In general, TLS's policy (dating back to TLS 1.0) has been that the
> job of TLS is to carry the certificates and other authentication
> material but to leave it up to other parts of the system to
> interpret them. It's been a long time since that decision was made,
> but from my perspective, there are a number of major reasons:
>
> 1. Most of PKI processing (path construction, etc.) is generic and
>    not specific to TLS. What is specific to TLS is:
>
>    * How to indicate what your PKI capabilities are
>      (see, e.g, S 4.2.4 and 4.3.2)
>    * How to stuff the PKI material into the protocol
>      (principally S 4.4.2)
>    * How to determine whether a given certificate is suitable for
>      use in TLS 4.4.4.2 and 4.3.2.1).
>
>    So we want to outsource the generic PKI part
>
>
> 2. It matches the software architecture that people often use,
>    which is to have a TLS stack but separate PKI validation. For
>    instance, Firefox uses NSS for TLS but moz::pkix for
>    validation. Similarly, Chrome uses BoringSSL for TLS
>    but the system PKI libraries for validation.
>
>
> In this case, I think that this text was more intended to
> say "and go read 5280 to learn how to do this". To that end,
> I suggest we say"
>
>
>     "In general detailed certificate validation procedures are out of
>     scope for TLS. [RFC5280] provides general procedures for
>     certificate validation. This section provides TLS-specific
>     requirements."
>

This reads much better, thank you.  However, shouldn't it say TLS1.3
since TLS 1.2 referenced RFC3280 and subsequently in RFC7525 includes
use of RFC5280 as a best practice.  It may be true for TLS 1.0 and
1.1, but it changed for TLS 1.2/

>
>> RFC7525 has use of RFC5280 as a best practice for server identity
>> verification and revocation checks for TLS 1.2.  Is this just for TLS
>> 1.3?  Why?
>
> I think that these requirements apply equally to TLS 1.3, it's
> just that 7525 is older.

I think this was poor phrasing on my part for the point.  and is
hopefully clarified in my response above.  RFC7525 came after TLS 1.2
and updated it's guidance recommending 5280.

>
>
>> RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
>> explanation here would be helpful since this seems to be a departure
>> (or reference to the changes section).
>
> This is part of our generalized attempt to update to point to
> the latest RFCs in our references. I'll add something to the
> references section.
> https://github.com/tlswg/tls13-spec/issues/1015
>
>
>> If RFC5280 remains out-of-scope, this section should fully describe
>> the certificate validation process for TLS 1.3. I think you need to
>> list out everything that should be checked as opposed to just
>> including one example:
>>
>>    "Also, if some aspect of the certificate chain was
>>    unacceptable (e.g., it was not signed by a known, trusted CA), the
>>    server MAY at its discretion either continue the handshake
>>    (considering the client unauthenticated) or abort the handshake."
>
> In general, I think we'd prefer to avoid providing a catalog of
> all the ways that things can go wrong, because there are a lot.
> The point of the text here is just supposed to be that servers
> don't have to fail if they ask for client auth but they are then
> sad about what the client provides. That's actually generally kind
> of true, but it's more obvious with client auth because in many
> cases the server has many ways of authenticating the client and
> can fall back if it doesn't like the cert.

>From list discussions, the underspecification seems to be causing some
interoperability problems.  Maybe a response to the list discussion
with this point will result in something to improve this section and
clarity for developers.  I'll look in the next update.  Thank you.

>
>
>> 4. Section 6.2 Error Alerts
>>
>> In addition to sending the error, I don't see any mention of the error
>> being logged on the server side, shouldn't that be specified?  Logging
>> errors (at least in debug modes when needed) provides valuable
>> troubleshooting information and many applications don't do an adequate
>> job of logging, so I think it's important to call that out here as a
>> recommendation.
>
> I agree. I think it would be useful to say something about this. I've
> filed https://github.com/tlswg/tls13-spec/issues/1014 to track this.

Thank you, this is very helpful.

Best regards,
Kathleen

>
> -Ekr
>
>
> On Fri, May 12, 2017 at 7:07 PM, Kathleen Moriarty
>  wrote:
>>
>> Hello,
>>
>> Thank you all for your work on TLS 1.3.  The list has still been
>> active on a few topics, so I want to see how that all settles out in
>> addition to the questions I have on the draft below.
>>
>> Introduction:
>>
>> 1. Since this is going for IETF last call soon and there has been
>> review of the draft (workshop, but is clearly ongoing from the list
>> discussions), should the first sentence of the Introductions be
>> removed?
>>
>>    DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
>>    significant security analysis.
>>
>> 2. Section 4.2.9 - There should be some mention or pointer to the
>> security considerations and recommendations on replay attacks for
>> 0-RTT from this section.  I don't see any mention of discouraging
>> 0-RTT from being a default and think that would be good for
>> applications that use TLS expecting replay protection.  I know the WG
>> agreed to keeping 0-RTT, but I think it's very important to make the
>> issues clear and not have this come up as a default in any
>> implementation/deployment for unsuspecting users.  Part of this will
>> get down to implementation specifics and configuration options, but
>> offering some guidance is important. This document will be read by
>> many, not just developers.
>>
>> Since clients have to initiate 0-RTT, the user has to have some idea
>> that replay attacks are possible and accept that risk.  If this were
>> used in web applications, then all servers that don't want to see
>> replay attacks (banking, etc.), would have to have explicitly reject
>> this usage.  As such, there needs to be very strong guidance to this
>> point. Would it be that browsers configure this as a default or
>> something users would have to turn on or just leave it as an option
>> (with warnings) for a client to enable?  Would servers have clear
>> information in configuration files (or setup) about the implications
>> of this option for those that don't read the RFC and are not aware of
>> this problem?
>>
>> Most of this discussion belongs directly in the security consideration
>> section, but there has to be mention of it with a reference from
>> section 4.2.9.  It's not just an API consideration, this is for
>> developers, implementers, and users of the protocol. Many other
>> protocols use TLS beside HTTP and do so with the expectation of replay
>> protection.
>>
>> While Appendix C1 is helpful, I don't think it's enough.  It's
>> disappointing to see a protocol with a replay attack written as a
>> prominent feature of TLS 1.3 and little discouragement from use.
>>
>>
>> 3. Section 4.2.
>>
>>    "In general, detailed certificate validation procedures are out of
>>    scope for TLS (see [RFC5280]).  This section provides TLS-specific
>>    requirements."
>>
>> I don't see an explanation of why it is out-of-scope.  The reference
>> is just to RFC5280, which seems odd.  I would expect the reference to
>> be to something that explains why it is out-of-scope.
>>
>> RFC7525 has use of RFC5280 as a best practice for server identity
>> verification and revocation checks for TLS 1.2.  Is this just for TLS
>> 1.3?  Why?
>> RFC3280 is cited for revocation in the TLS 1.2 RFC.  I think a little
>> explanation here would be helpful since this seems to be a departure
>> (or reference to the changes section).
>>
>> If RFC5280 remains out-of-scope, this section should fully describe
>> the certificate validation process for TLS 1.3. I think you need to
>> list out everything that should be checked as opposed to just
>> including one example:
>>
>>    "Also, if some aspect of the certificate chain was
>>    unacceptable (e.g., it was not signed by a known, trusted CA), the
>>    server MAY at its discretion either continue the handshake
>>    (considering the client unauthenticated) or abort the handshake."
>>
>>
>> 4. Section 6.2 Error Alerts
>>
>> In addition to sending the error, I don't see any mention of the error
>> being logged on the server side, shouldn't that be specified?  Logging
>> errors (at least in debug modes when needed) provides valuable
>> troubleshooting information and many applications don't do an adequate
>> job of logging, so I think it's important to call that out here as a
>> recommendation.
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>



-- 

Best regards,
Kathleen


From nobody Mon May 15 12:41:48 2017
Return-Path: 
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 1C1F2129AF9 for ; Mon, 15 May 2017 12:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 BQcgjTSS0JXj for ; Mon, 15 May 2017 12:41:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CD012EAA1 for ; Mon, 15 May 2017 12:38:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 42367300581 for ; Mon, 15 May 2017 15:38:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CZtYQHRxf6Ms for ; Mon, 15 May 2017 15:38:40 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 678F030056B; Mon, 15 May 2017 15:38:40 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley 
In-Reply-To: 
Date: Mon, 15 May 2017 15:38:43 -0400
Cc: IETF TLS 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>
References:  
To: Eric Rescorla , Kathleen Moriarty 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 19:41:47 -0000

Just commenting on Section 4.2 =E2=80=A6

>=20
> > 3. Section 4.2.
> >=20
> >    "In general, detailed certificate validation procedures are out =
of
> >    scope for TLS (see [RFC5280]).  This section provides =
TLS-specific
> >    requirements."
> >=20
> > I don't see an explanation of why it is out-of-scope.  The reference
> > is just to RFC5280, which seems odd.  I would expect the reference =
to
> > be to something that explains why it is out-of-scope.

I think the the separation of certificate path validation from the TLS =
protocol is correct, but perhaps this can be explained differently.  =
Perhaps the approach should be that TLS depends upon certificate path =
validation as described in RFC 5280.

> In general, TLS's policy (dating back to TLS 1.0) has been that the
> job of TLS is to carry the certificates and other authentication
> material but to leave it up to other parts of the system to
> interpret them. It's been a long time since that decision was made,
> but from my perspective, there are a number of major reasons:
>=20
> 1. Most of PKI processing (path construction, etc.) is generic and
>    not specific to TLS. What is specific to TLS is:
>=20
>    * How to indicate what your PKI capabilities are
>      (see, e.g, S 4.2.4 and 4.3.2)
>    * How to stuff the PKI material into the protocol
>      (principally S 4.4.2)
>    * How to determine whether a given certificate is suitable for
>      use in TLS 4.4.4.2 and 4.3.2.1).
> =20
>    So we want to outsource the generic PKI part
>=20
>=20
> 2. It matches the software architecture that people often use,
>    which is to have a TLS stack but separate PKI validation. For
>    instance, Firefox uses NSS for TLS but moz::pkix for
>    validation. Similarly, Chrome uses BoringSSL for TLS
>    but the system PKI libraries for validation.
>=20
>=20
> In this case, I think that this text was more intended to
> say "and go read 5280 to learn how to do this". To that end,
> I suggest we say"
>=20
>             =20
>     "In general detailed certificate validation procedures are out of
>     scope for TLS. [RFC5280] provides general procedures for
>     certificate validation. This section provides TLS-specific
>     requirements.=E2=80=9D

I agree with the reasoning, however the dependency on RFC 5280 should be =
called out in a MUST statement.  I suggest something like:

    "TLS depends on certificate path validation, and a conformant
    TLS implementation MUST implement certificate paths validation
    in a manner that achieves the same result as [RFC5280]. This
    section provides TLS-specific requirements.=E2=80=9D

Note that RFC 5280 is already a normative reference.

Russ


From nobody Mon May 15 13:13:51 2017
Return-Path: 
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 E7058129A97 for ; Mon, 15 May 2017 13:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xwmGwSTAHUaG for ; Mon, 15 May 2017 13:13:48 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1358B129482 for ; Mon, 15 May 2017 13:10:04 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id c13so46122668qtc.1 for ; Mon, 15 May 2017 13:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=FrNWW/ByXOUB8DEZA+lHd+vt5vHF64+yteGzHNQ1zF4=; b=qPkNPjHr+zLwbUlk2dnfSBEFB1l5dzL4kdopvnFdiYpUSGYfvmcm91R5w9SeA2GeR9 FLJ+pTNlKqKtXsG74hoWqQwN/ZH3o/cGv44B+mKH4f6TQFtBRBYeq1TbdeEQBXDD/xNr UhzKgK/OMJZWqzWribne8yVvpTiLRHRaTVaoiGtEJEt4qbIMiPQqF1L3+9biK/t08ogW 6wckbN1YPYEC/r3olObdvLmdjcMNbMwkF7ltyL4M0GwgqTRG/iXJosHgkZZb4RFroGt8 sPA14gDmdSZmcT8Siz+V/aFe+fqeKx1fCqDpIT24lD6iyyqh6W+JKblOopSLJhaMTXqV f+Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=FrNWW/ByXOUB8DEZA+lHd+vt5vHF64+yteGzHNQ1zF4=; b=YCkjhNOB2Kjuhi1EHI/ngQfppscCbDjgArMig/JmUIt629u3cGZPJPkb8oTCw0hcEe Ekz0gRBPdV5iJeqH8OLB266brBJp33Vs+FdTuw3ZEMjG0xeDF+CF+JAWqMGI1OXJPpIo x28nJ3Uh+inBfpTtJHNk9i+zg4/+MgqQe34e8EIr0BJtS6C/UvThgp0eOA2OUB8Xjyz7 SAloT84DopmNj+KAyJT///dC33ENz2jOmAjKwVAqVMa8FhmxEH4qIumJ3estA5qH4pDH A8U7EsLwUcn4XkrHrnp4C9Zp7SVXd1KmBNrNmkWvlTmdxdEDmeifbueM2p7nQTFvf0i6 pzVw==
X-Gm-Message-State: AODbwcCs33t0FsShsu2tjpbxbca5wAsZx+AEOH+qyIrj2bJia8/rRblV pO88AmftzqMRfQ==
X-Received: by 10.237.60.74 with SMTP id u10mr6896489qte.205.1494879003053; Mon, 15 May 2017 13:10:03 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id c18sm9099419qkg.32.2017.05.15.13.10.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 May 2017 13:10:02 -0700 (PDT)
From: Dave Garrett 
To: Hubert Kario 
Date: Mon, 15 May 2017 16:10:00 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
Cc: Christian Huitema , tls@ietf.org, Daniel Kahn Gillmor , Ilari Liusvaara 
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <201705130121.06879.davemgarrett@gmail.com> <4227474.urTlPk55X7@pintsize.usersys.redhat.com>
In-Reply-To: <4227474.urTlPk55X7@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201705151610.01070.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 20:13:50 -0000

On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote:
> On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote:
> > On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> > > The "server DH Key" poses a significant forward secrecy issue. Suppose
> > > that the key is compromised. Now the secret police can find out what
> > > nasty sites was accessed by whom. That can be plus plus not good for
> > > said dissidents.
> > 
> > *This is the current situation.* "If the fix is broken, then it won't be
> > fixed anymore" is not really that compelling of an argument, by itself.
> > 
> > Of course the host DH key has an FS risk; it'd need to have a limited
> > validity time and be rotated regularly. (probably weekly)
> 
> you then need mechanism to indicate which DNS key share client is using or all 
> the connections would start failing on key rollover. And have to deal with all 
> the "fun" stuff related to key rollovers.

It's possible to conceive of a way to do this with minimal trial decryption,
or instead, we could just rotate the port with the key. (confusing firewalls
is of course a problem, but that's something that could be dealt with)

> > The private key
> > would need to be protected and managed by the host (not the virtual
> > servers)
> 
> yes, the key MUST be assigned to a specific IP, not virtual host
> 
> > > EKR did propose a TLS in TLS tunnel back in December 2015:
> > > https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw.
> > > It would effectively encrypt the "inner" Client Hello.
> > 
> > Same basic concept, different implementation. TLS tunneling would provide
> > some backwards compatibility; ClientHellos would still look like
> > ClientHellos. I was just suggesting the simple generic route of encrypting
> > everything in a non-backwards-compatible way (sent to a specified port that
> > is set up to only handle that and reject everything else). I'd rather let
> > stupid/incompatible stuff just break if we're designing a new opt-in
> > system.
> > 
> > The argument I'm making here isn't about implementation; it's about what to
> > think about implementing to deal with the issues here.
> 
> I respectfully disagree. That system requires tight coupling between the TLS 
> implementation and DNS. This is not something that facilitates TLS deployment. 
> We want more TLS/HTTPS deployment, not less.

I completely understand why you'd disagree on these grounds. My argument is
that whilst this does require a significant amount of coordination, it's a more
productive route than just focusing on SNI encryption, which still has its own
share of problems. (hence us not agreeing on a way to do it yet)

The most practical short-term route would likely be to continue to hold our noses
and expect cleartext SNI, but maybe provide a very simple way for servers to put
a flag in a DNS record to opt-out entirely when they can do without.


Dave


From nobody Mon May 15 13:21:57 2017
Return-Path: 
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 6E4C7127ABE for ; Mon, 15 May 2017 13:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 2nbXmYyFfni5 for ; Mon, 15 May 2017 13:21:54 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3523E129463 for ; Mon, 15 May 2017 13:19:09 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 68F407A32F1 for ; Mon, 15 May 2017 20:19:08 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>
Date: Mon, 15 May 2017 16:19:07 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: 
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 20:21:55 -0000

> On May 15, 2017, at 3:38 PM, Russ Housley  wrote:
> 
>>> I don't see an explanation of why it is out-of-scope.  The reference
>>> is just to RFC5280, which seems odd.  I would expect the reference to
>>> be to something that explains why it is out-of-scope.
> 
> I think the the separation of certificate path validation from the TLS
> protocol is correct, but perhaps this can be explained differently.
> Perhaps the approach should be that TLS depends upon certificate path
> validation as described in RFC 5280.

That's not always true.  With DANE-EE(3) TLSA records there is no
path validation.  You just validate the EE certificate directly.

With DANE-EE(2), there's an RFC5280 chain, but it terminates on
a trust-anchor provided by the peer as part of its chain, with
a hash in DNS.

With unauthenticated opportunistic TLS, the peer's chain is ignored
entirely.

How and whether the peer's certificate message is used is properly
outside TLS.

-- 
	Viktor.


From nobody Mon May 15 16:05:12 2017
Return-Path: 
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 DC3BD129B6A for ; Mon, 15 May 2017 16:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 S9hxt509ucjK for ; Mon, 15 May 2017 16:05:06 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012A712EAAC for ; Mon, 15 May 2017 16:02:35 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id p143so31384129yba.2 for ; Mon, 15 May 2017 16:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z9F5S9PZFu3BleSu/wO0k7VLjkvB9/CqM0Fj/sO1GLU=; b=JOk9dgA0Ca0Bn9z5WgNmvdt59VyTbRL0IN4S/cZdMlgCnW1xF8vqIbvbekJGAbaXT4 4sigI+EpWB8eQ42weHKwZgjKWCg2q1LqzzhLq2pWfIB3QySfJO5wznrlJI00YM+Wdcet +P3rjQQ0f1XNmh7ktdaAE4XAnxdb3HazseWbr3zt7s9TjMw/b0i5p9MxXTXOupgLPXVD 2cUlBKjjaGxwhOHcm6lKghZUZmoWroW6pLhdm//KzdzsJ1cZdaQ2EASg79fE6NAmwLMA n8iSgKLye81MTwX55tPzM+AbiWFSV1RCS0ki9TXTPftvUeEbn5UfqlO16voDJjsb1C2D wDxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z9F5S9PZFu3BleSu/wO0k7VLjkvB9/CqM0Fj/sO1GLU=; b=Blvxr8s8gqecEaxdi7E/wgg+KdQhTmPPgrqhbIjB3yPI2DkH3fnoATJvtZJBZtElDe HRa40K44X6ZWTwDn8BIOsg2MLLiBlSue8jNmO4RuoZmvOrPEFDGUJ40ZPrngf1y5W5HR gWXyyNFU6XHwNGTnoGWlcD0oLTunJFZX1XSPOFgbUrXdfN5gLqsJZc4SRTh3Wy/+pO1M 7Vlj29bfLEdurTtWrI2S9YUKu69/nteSbg0tLEzISySs4/eoFXluV70vJW7KwdLSuNwm 5l6RAw6aqOyHRs1NAVAMMU8VpPinJPzHFRWJRyzIP4RLy2q5Fwzqr4mvv/TAUoTeuqoG uhXg==
X-Gm-Message-State: AODbwcAz7syUYWVX4sbdgHLbSzDQgAH1aAbz9+0X8zxhS8VFSQuwxB1e CATrBySBkSwLCaDQ5PC0I2fFgnYV0Q==
X-Received: by 10.37.218.10 with SMTP id n10mr6882271ybf.117.1494889354187; Mon, 15 May 2017 16:02:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Mon, 15 May 2017 16:01:53 -0700 (PDT)
In-Reply-To: <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>
From: Eric Rescorla 
Date: Mon, 15 May 2017 16:01:53 -0700
Message-ID: 
To: Russ Housley 
Cc: Kathleen Moriarty , IETF TLS 
Content-Type: multipart/alternative; boundary="94eb2c07ceaeef6f48054f980c9a"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 23:05:11 -0000

--94eb2c07ceaeef6f48054f980c9a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 15, 2017 at 12:38 PM, Russ Housley  wrote=
:

> Just commenting on Section 4.2 =E2=80=A6
>
> >
> > > 3. Section 4.2.
> > >
> > >    "In general, detailed certificate validation procedures are out of
> > >    scope for TLS (see [RFC5280]).  This section provides TLS-specific
> > >    requirements."
> > >
> > > I don't see an explanation of why it is out-of-scope.  The reference
> > > is just to RFC5280, which seems odd.  I would expect the reference to
> > > be to something that explains why it is out-of-scope.
>
> I think the the separation of certificate path validation from the TLS
> protocol is correct, but perhaps this can be explained differently.
> Perhaps the approach should be that TLS depends upon certificate path
> validation as described in RFC 5280.
>
> > In general, TLS's policy (dating back to TLS 1.0) has been that the
> > job of TLS is to carry the certificates and other authentication
> > material but to leave it up to other parts of the system to
> > interpret them. It's been a long time since that decision was made,
> > but from my perspective, there are a number of major reasons:
> >
> > 1. Most of PKI processing (path construction, etc.) is generic and
> >    not specific to TLS. What is specific to TLS is:
> >
> >    * How to indicate what your PKI capabilities are
> >      (see, e.g, S 4.2.4 and 4.3.2)
> >    * How to stuff the PKI material into the protocol
> >      (principally S 4.4.2)
> >    * How to determine whether a given certificate is suitable for
> >      use in TLS 4.4.4.2 and 4.3.2.1).
> >
> >    So we want to outsource the generic PKI part
> >
> >
> > 2. It matches the software architecture that people often use,
> >    which is to have a TLS stack but separate PKI validation. For
> >    instance, Firefox uses NSS for TLS but moz::pkix for
> >    validation. Similarly, Chrome uses BoringSSL for TLS
> >    but the system PKI libraries for validation.
> >
> >
> > In this case, I think that this text was more intended to
> > say "and go read 5280 to learn how to do this". To that end,
> > I suggest we say"
> >
> >
> >     "In general detailed certificate validation procedures are out of
> >     scope for TLS. [RFC5280] provides general procedures for
> >     certificate validation. This section provides TLS-specific
> >     requirements.=E2=80=9D
>
> I agree with the reasoning, however the dependency on RFC 5280 should be
> called out in a MUST statement.  I suggest something like:
>
>     "TLS depends on certificate path validation, and a conformant
>     TLS implementation MUST implement certificate paths validation
>     in a manner that achieves the same result as [RFC5280]. This
>     section provides TLS-specific requirements.=E2=80=9D
>
> Note that RFC 5280 is already a normative reference.
>

A MUST here would be a pretty material change to historical TLS practice.
As Viktor says, there are TLS-using applications that just don't validate
the cert via 5280 at all.

-Ekr


> Russ
>
>

--94eb2c07ceaeef6f48054f980c9a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, May 15, 2017 at 12:38 PM, Russ Housley <housley@vigilsec.co=
m> wrote:
Just commenting o=
n Section 4.2 =E2=80=A6



>

> > 3. Section 4.2.

> >

> >=C2=A0 =C2=A0 "In general, detailed certificate validation pr=
ocedures are out of

> >=C2=A0 =C2=A0 scope for TLS (see [RFC5280]).=C2=A0 This section pr=
ovides TLS-specific

> >=C2=A0 =C2=A0 requirements."

> >

> > I don't see an explanation of why it is out-of-scope.=C2=A0 T=
he reference

> > is just to RFC5280, which seems odd.=C2=A0 I would expect the ref=
erence to

> > be to something that explains why it is out-of-scope.



I think the the separation of certificate path validation from the T=
LS protocol is correct, but perhaps this can be explained differently.=C2=
=A0 Perhaps the approach should be that TLS depends upon certificate path v=
alidation as described in RFC 5280.




> In general, TLS's policy (dating back to TLS 1.0) has been that th=
e

> job of TLS is to carry the certificates and other authentication

> material but to leave it up to other parts of the system to

> interpret them. It's been a long time since that decision was made=
,

> but from my perspective, there are a number of major reasons:

>

> 1. Most of PKI processing (path construction, etc.) is generic and

>=C2=A0 =C2=A0 not specific to TLS. What is specific to TLS is:

>

>=C2=A0 =C2=A0 * How to indicate what your PKI capabilities are

>=C2=A0 =C2=A0 =C2=A0 (see, e.g, S 4.2.4 and 4.3.2)

>=C2=A0 =C2=A0 * How to stuff the PKI material into the protocol

>=C2=A0 =C2=A0 =C2=A0 (principally S 4.4.2)

>=C2=A0 =C2=A0 * How to determine whether a given certificate is suitabl=
e for

>=C2=A0 =C2=A0 =C2=A0 use in TLS 4.4.4.2 and 4.3.2.1).

>

>=C2=A0 =C2=A0 So we want to outsource the generic PKI part

>

>

> 2. It matches the software architecture that people often use,

>=C2=A0 =C2=A0 which is to have a TLS stack but separate PKI validation.=
 For

>=C2=A0 =C2=A0 instance, Firefox uses NSS for TLS but moz::pkix for

>=C2=A0 =C2=A0 validation. Similarly, Chrome uses BoringSSL for TLS

>=C2=A0 =C2=A0 but the system PKI libraries for validation.

>

>

> In this case, I think that this text was more intended to

> say "and go read 5280 to learn how to do this". To that end,=


> I suggest we say"

>

>

>=C2=A0 =C2=A0 =C2=A0"In general detailed certificate validation pr=
ocedures are out of

>=C2=A0 =C2=A0 =C2=A0scope for TLS. [RFC5280] provides general procedure=
s for

>=C2=A0 =C2=A0 =C2=A0certificate validation. This section provides TLS-s=
pecific


>=C2=A0 =C2=A0 =C2=A0requirements.=E2=80=9D



I agree with the reasoning, however the dependency on RFC 5280 should be ca=
lled out in a MUST statement.=C2=A0 I suggest something like:



=C2=A0 =C2=A0 "TLS depends on certificate path validation, and a confo=
rmant

=C2=A0 =C2=A0 TLS implementation MUST implement certificate paths validatio=
n

=C2=A0 =C2=A0 in a manner that achieves the same result as [RFC5280]. This<=
br>
=C2=A0 =C2=A0 section provides TLS-specific requirements.=E2=80=9D



Note that RFC 5280 is already a normative reference.
<=
br>
A MUST here would be a pretty material change to historical T=
LS practice.
As Viktor says, there are TLS-using applications tha=
t just don't validate
the cert via 5280 at all.
-Ekr




Russ







--94eb2c07ceaeef6f48054f980c9a--


From nobody Tue May 16 04:38:46 2017
Return-Path: 
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 9E42712950B for ; Tue, 16 May 2017 04:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.522
X-Spam-Level: 
X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 4LFIr3XKUI4R for ; Tue, 16 May 2017 04:38:39 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DFE127867 for ; Tue, 16 May 2017 04:35:27 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D65380C27; Tue, 16 May 2017 11:35:21 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2D65380C27
Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2D65380C27
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 197E0889A4; Tue, 16 May 2017 11:35:18 +0000 (UTC)
From: Hubert Kario 
To: Dave Garrett 
Cc: Christian Huitema , tls@ietf.org, Daniel Kahn Gillmor , Ilari Liusvaara 
Date: Tue, 16 May 2017 13:35:16 +0200
Message-ID: <2347596.YMnKhrj8b1@pintsize.usersys.redhat.com>
In-Reply-To: <201705151610.01070.davemgarrett@gmail.com>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <4227474.urTlPk55X7@pintsize.usersys.redhat.com> <201705151610.01070.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1918567.K44z8E1iTr"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 16 May 2017 11:35:26 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 11:38:43 -0000

--nextPart1918567.K44z8E1iTr
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote:
> On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote:
> > On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote:
> > > On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> > > > EKR did propose a TLS in TLS tunnel back in December 2015:
> > > > https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90F=
tw.
> > > > It would effectively encrypt the "inner" Client Hello.
> > >=20
> > > Same basic concept, different implementation. TLS tunneling would
> > > provide
> > > some backwards compatibility; ClientHellos would still look like
> > > ClientHellos. I was just suggesting the simple generic route of
> > > encrypting
> > > everything in a non-backwards-compatible way (sent to a specified port
> > > that
> > > is set up to only handle that and reject everything else). I'd rather
> > > let
> > > stupid/incompatible stuff just break if we're designing a new opt-in
> > > system.
> > >=20
> > > The argument I'm making here isn't about implementation; it's about w=
hat
> > > to
> > > think about implementing to deal with the issues here.
> >=20
> > I respectfully disagree. That system requires tight coupling between the
> > TLS implementation and DNS. This is not something that facilitates TLS
> > deployment. We want more TLS/HTTPS deployment, not less.
>=20
> I completely understand why you'd disagree on these grounds. My argument =
is
> that whilst this does require a significant amount of coordination, it's a
> more productive route than just focusing on SNI encryption, which still h=
as
> its own share of problems. (hence us not agreeing on a way to do it yet)

Is there anything else sensitive in the Client Hello? Either way, to proper=
ly=20
encrypt SNI with forward secrecy requires the same system that would be=20
necessary to encrypt the whole Client Hello.

> The most practical short-term route would likely be to continue to hold o=
ur
> noses and expect cleartext SNI, but maybe provide a very simple way for
> servers to put a flag in a DNS record to opt-out entirely when they can do
> without.

The point of encrypting SNI is so that you can hide a website on a shared=20
hosting host. If you have just one website on a host, there's nothing to=20
hide... Opting out by servers also makes the interesting targets more visib=
le=20
(see also: email encryption).

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart1918567.K44z8E1iTr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJZGuP0AAoJEJKo0bgB0vX1MZYP/iIV92cy/VmU8JrgVGh3ovoy
Wf/6jJKzQRINRiN0c89bX5/MTidq4oPtwI87pMbb7c8mJ2UuaKgJ8Lzjr4Y/Y2BU
rAfi+8z1FfD/IBXz/nbZhwdTFXb5+FNmH1+AmOTVPxqjkrzC/s+eTe3ZbzfNC+Rq
Jw51qdf5cNoYaButFqGHRk961kL3oGPZP87knkOcekLpjQsxHrcp8lxFCvmJifjG
24UpFoGC3+KvdqXNJUOvuIB5c5Hfr5NPLhFjItiI3v8mAVQl5/gUvnpTYToeFHGZ
yFgufqbLoLVS0aZ+3n7vl0yc/VuaOB85/cOE5hADfIZMdmXQEJQFDxOgTPVw5D1E
HycZl47cIMjTZXcaAO/6mPlairBjRPhMpDaASJFr7c8sOCfLQlxeQ3FprYya34ut
UBx8h1kV7EpiH52jgu2i4WePnlKJ8Z5J/Kh6yq+Top+99C19X8mDM38dyRDkmvQH
iIaZNHmX5JtEt4HRN7rZCTwUvsp6rqZ1Rl9DK0oEmvCddROeeEne6WZCuWC3Mkjm
T6FR3bbgxBdTJ8BTS6B+J4mXDoTrIfAGviULGYf0o0xZQ2UyRO/+Gw69AcHl6wVN
zl0tgppRnQ6+U+R0+zONOIzJoZL0AMspKVTlfAhDOasRswOX+sPtQuv+qB3SsdOq
VS1oJ42KiBGNAv90TvJP
=Hm0B
-----END PGP SIGNATURE-----

--nextPart1918567.K44z8E1iTr--


From nobody Tue May 16 05:53:47 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1912EBA8; Tue, 16 May 2017 05:53:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149493922093.11951.17556682083036312398.idtracker@ietfa.amsl.com>
Date: Tue, 16 May 2017 05:53:40 -0700
Archived-At: 
Subject: [TLS] The TLS WG has placed draft-ghedini-tls-certificate-compression in state "Call For Adoption By WG Issued"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 16 May 2017 12:53:41 -0000

The TLS WG has placed draft-ghedini-tls-certificate-compression in state

Call For Adoption By WG Issued (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/


From nobody Tue May 16 05:56:24 2017
Return-Path: 
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 7E89412EB6D for ; Tue, 16 May 2017 05:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 vqnZK5RAMWao for ; Tue, 16 May 2017 05:56:21 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A394129C48 for ; Tue, 16 May 2017 05:52:33 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id f102so92354737ioi.2 for ; Tue, 16 May 2017 05:52:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=QjbRTMYwp8e349jA3/BuwOa0j7/tdXS583aukLQPvhI=; b=aqm1sO9o9vKMqUn9565V1MT4bGA9OJdIGQFX/uV6Yb57EjeDd+IrqMs5iPHpGTrmtH zkTX6pmAizH2NmU14mznXTAoKwPFeL8SfuSBEhnM43ZQyRjBOSBQeJzcLhEOTR7K5rY1 tEfS32pUagOqiot+vS2ce64vm6ko/AQC8kBfk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=QjbRTMYwp8e349jA3/BuwOa0j7/tdXS583aukLQPvhI=; b=D2LbzpPzekDUXWTmY8loSQTQexkJxMJb++pHtSC04lRDGrubzef9xpgtEjo/euCThQ ATK03wNWEXvuUJ+mLtHj+89Dz+XYAsZK1nUFyNv2ov5nO8CVAvuXTNpDRJorsfEtHmkR EWqbKxEznkFqe2NyBVI6HfkSuMtootVNB774eT1xvK5lWQ6VwxjaTlXzqQnMLaUPQBs8 Mzvtc0PHQmM4/ztWC3ni2HQzdSdrugegOxjf4JVzmYcZMlh0dqb7YgteovWQquPMtkxG u8Cc39E6DIjxFUKAtoOAEKF+XsIvaT0cHCke2g5G/OxozmAve50OIjEM+ZqDDVv/Mpfb jB+Q==
X-Gm-Message-State: AODbwcCujuwBM1usw86SdwomQ2L9DS0/LQeMs5agZFW4BYAqefm3e13Y Ldy87SoH5GGrJQnbB2I=
X-Received: by 10.107.13.5 with SMTP id 5mr9786610ion.221.1494939152439; Tue, 16 May 2017 05:52:32 -0700 (PDT)
Received: from [5.5.33.117] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 78sm6478864iou.36.2017.05.16.05.52.30 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 05:52:31 -0700 (PDT)
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
Date: Tue, 16 May 2017 08:52:26 -0400
To: "" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 12:56:22 -0000

All,

At the IETF 98 meeting in Chicago, there was support in the room to =
adopt =
https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression=
/. We are looking for feedback on adopting this draft form the list. =
Please respond if you support the draft and are willing to review it. If =
you object to its adoption, please let us know why. Please respond to =
the list by 20170530.

Cheers,

J&S

Apologies - we dropped the ball on this adoption call, the call should =
have gone out with the others.=


From nobody Tue May 16 06:19:29 2017
Return-Path: 
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 8621812EB7F for ; Tue, 16 May 2017 06:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Pp6vtAinxqtR for ; Tue, 16 May 2017 06:19:25 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19F3126E01 for ; Tue, 16 May 2017 06:15:34 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id l14so52608438ywk.1 for ; Tue, 16 May 2017 06:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h8G3osOmTchTvJ7DPG53D+h82Yt99JA93yFvxAgEj6I=; b=umhJgAWImvwBFGVtEMsdnB/WA+zbxXYmKvF/knzd40kOi6sW5m3TVGtLqnqTnh0Cl7 So8UT8v+kKBTyyJOtYAwWcxdjCLe1/JtQko3XWoOUkQynoQ+wteERZsf4m5PeSvftZoX KBPFUqUOhkpLAvoPW40eCIn6zYniZYHRhbCHCh8NUbfbqLvIfa/RpU+LiQC8LRDdtaaE NImNR1Da0sfWcRRfUUXJ3UEm3rcQ0JUv2TRKf2G17wvUvswFJtdQM6/j5BPBvzNX8+WA BRXi2qgRakUVZ20k7DHNgw8/KxZZtpSdviXvDO0ClMARpoWEQJrjOgujnmg1JykjLFCn 54Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h8G3osOmTchTvJ7DPG53D+h82Yt99JA93yFvxAgEj6I=; b=WSC7qnklXvoQLDlJDGSS/xudDlsC/7h6rlPukP53QajMdNyUoyvCqrkw409HBfqgpT QcSlSKL3YpgL2QfU03dEF3/42UPKDq3iydoAZSFwXxC0ziHyoIvbsPl6mv2wPITnDTnV ERhSUB8R/nQNzYfQh+VzAgxWcLVhmuL1fyXUBfM5lBsSIKWm3euE9D4K6qL5yjG+yS38 0s2j7T2hexudZluxjZQBxSXKufKQ+936606b3632DwO4Y1xI/ssD5i/fNNzWm4boPZ5C Wy3j0dZK8KWVcGzYE6iaKhM1On+MqKVpSKWZDn+87GJ4MwOzPhzX/2q4EKePC2vQqLub Ay0A==
X-Gm-Message-State: AODbwcBSlb5guUq7XEYklcXryoMP3JuPLBn3ozPls/i2mZE9Jr0KOVWo bH93YSjGm7iP83ODe+aV5CsLlF35hRUD
X-Received: by 10.129.85.83 with SMTP id j80mr9204895ywb.283.1494940534093; Tue, 16 May 2017 06:15:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 06:14:53 -0700 (PDT)
In-Reply-To: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
References: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
From: Eric Rescorla 
Date: Tue, 16 May 2017 06:14:53 -0700
Message-ID: 
To: Sean Turner 
Cc: "" 
Content-Type: multipart/alternative; boundary="001a113f3cbe7ecd7c054fa3f707"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 13:19:28 -0000

--001a113f3cbe7ecd7c054fa3f707
Content-Type: text/plain; charset="UTF-8"

I am in favor of adoption

On Tue, May 16, 2017 at 5:52 AM, Sean Turner  wrote:

> All,
>
> At the IETF 98 meeting in Chicago, there was support in the room to adopt
> https://datatracker.ietf.org/doc/draft-ghedini-tls-
> certificate-compression/. We are looking for feedback on adopting this
> draft form the list. Please respond if you support the draft and are
> willing to review it. If you object to its adoption, please let us know
> why. Please respond to the list by 20170530.
>
> Cheers,
>
> J&S
>
> Apologies - we dropped the ball on this adoption call, the call should
> have gone out with the others.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113f3cbe7ecd7c054fa3f707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am in favor of adoption
=

On Tue, May 16, 2017 at 5:52 AM, Sean Turner=
 <=
sean@sn3rd.com> wrote:
All,=




At the IETF 98 meeting in Chicago, there was support in the room to adopt <=
a href=3D"https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-co=
mpression/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.o=
rg/doc/draft-ghedini-tls-certificate-compression/. We are loo=
king for feedback on adopting this draft form the list. Please respond if y=
ou support the draft and are willing to review it. If you object to its ado=
ption, please let us know why. Please respond to the list by 20170530.



Cheers,



J&S



Apologies - we dropped the ball on this adoption call, the call should have=
 gone out with the others.

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113f3cbe7ecd7c054fa3f707--


From nobody Tue May 16 06:25:19 2017
Return-Path: 
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 6004412EBB1 for ; Tue, 16 May 2017 06:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 KJCPkLXGcHiJ for ; Tue, 16 May 2017 06:25:15 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97323129B9A for ; Tue, 16 May 2017 06:20:51 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4GD85ws009902; Tue, 16 May 2017 14:20:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=oRkK4QJOY+SuYH24VsN6C+zP/DgClBevYFVwYMsmxBM=; b=XHW/LOAkJkcG3yEXaZjDuJnCVWvKsGFLLVWPN9qVe+quvAUtBHkUePm8LkI2MD0fy9fC VdtrjD0/P5RU5UTIyAYaPw+OAtEHWAqy69xNLiQXTRy9oRVypojo5jKYeSAkeJH/jLjf pfPrMCH9I0MVyjljRDpd19RQC9mJ2sEKry9aXDl71ZUZWicUIec1EjO38rGfs6rTWl2a B/OmaCUwLKgQhkcKfKYqFxEOjD5VDGB6k3RlofS9YXWrKcSvExCLOH8FnhzEDHPqQqb8 dAo7G2oKzoKFeQiazeDXx5qoyo6VCsjSAbmMxr9fNwll9YAgWqKqls1QSBa9yBjE4kuo 1g== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2ag0980nf7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 May 2017 14:20:48 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4GDGG6u027485; Tue, 16 May 2017 09:20:48 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2adwfvh0fe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 May 2017 09:20:48 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 16 May 2017 09:20:46 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 16 May 2017 09:20:45 -0400
From: "Salz, Rich" 
To: Sean Turner , "" 
Thread-Topic: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
Thread-Index: AQHSzkPWX08RdJSDgk2M2rWp04bY96H28dkg
Date: Tue, 16 May 2017 13:20:45 +0000
Message-ID: <7ccc5e9962dc4a4aa8fa3983eb6b122b@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
In-Reply-To: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.243]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-16_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160109
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-16_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160109
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 13:25:17 -0000

In favor, will review.


From nobody Tue May 16 08:21:59 2017
Return-Path: 
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 E8AFA12EAEA for ; Tue, 16 May 2017 08:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 rWHhhcTsKxGb for ; Tue, 16 May 2017 08:21:57 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60ACE12940C for ; Tue, 16 May 2017 08:17:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98AC1300538 for ; Tue, 16 May 2017 11:17:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hLKw3UQ4k8wB for ; Tue, 16 May 2017 11:17:45 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id EAEDB30029F; Tue, 16 May 2017 11:17:44 -0400 (EDT)
From: Russ Housley 
Message-Id: <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_92C1E551-7AE4-46DA-919E-1EADF32EF45A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 16 May 2017 11:17:44 -0400
In-Reply-To: 
Cc: Kathleen Moriarty , IETF TLS 
To: Eric Rescorla 
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 15:21:59 -0000

--Apple-Mail=_92C1E551-7AE4-46DA-919E-1EADF32EF45A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Mon, May 15, 2017 at 12:38 PM, Russ Housley > wrote:
> Just commenting on Section 4.2 =E2=80=A6
>=20
> >
> > > 3. Section 4.2.
> > >
> > >    "In general, detailed certificate validation procedures are out =
of
> > >    scope for TLS (see [RFC5280]).  This section provides =
TLS-specific
> > >    requirements."
> > >
> > > I don't see an explanation of why it is out-of-scope.  The =
reference
> > > is just to RFC5280, which seems odd.  I would expect the reference =
to
> > > be to something that explains why it is out-of-scope.
>=20
> I think the the separation of certificate path validation from the TLS =
protocol is correct, but perhaps this can be explained differently.  =
Perhaps the approach should be that TLS depends upon certificate path =
validation as described in RFC 5280.
>=20
> > In general, TLS's policy (dating back to TLS 1.0) has been that the
> > job of TLS is to carry the certificates and other authentication
> > material but to leave it up to other parts of the system to
> > interpret them. It's been a long time since that decision was made,
> > but from my perspective, there are a number of major reasons:
> >
> > 1. Most of PKI processing (path construction, etc.) is generic and
> >    not specific to TLS. What is specific to TLS is:
> >
> >    * How to indicate what your PKI capabilities are
> >      (see, e.g, S 4.2.4 and 4.3.2)
> >    * How to stuff the PKI material into the protocol
> >      (principally S 4.4.2)
> >    * How to determine whether a given certificate is suitable for
> >      use in TLS 4.4.4.2 and 4.3.2.1).
> >
> >    So we want to outsource the generic PKI part
> >
> >
> > 2. It matches the software architecture that people often use,
> >    which is to have a TLS stack but separate PKI validation. For
> >    instance, Firefox uses NSS for TLS but moz::pkix for
> >    validation. Similarly, Chrome uses BoringSSL for TLS
> >    but the system PKI libraries for validation.
> >
> >
> > In this case, I think that this text was more intended to
> > say "and go read 5280 to learn how to do this". To that end,
> > I suggest we say"
> >
> >
> >     "In general detailed certificate validation procedures are out =
of
> >     scope for TLS. [RFC5280] provides general procedures for
> >     certificate validation. This section provides TLS-specific
> >     requirements.=E2=80=9D
>=20
> I agree with the reasoning, however the dependency on RFC 5280 should =
be called out in a MUST statement.  I suggest something like:
>=20
>     "TLS depends on certificate path validation, and a conformant
>     TLS implementation MUST implement certificate paths validation
>     in a manner that achieves the same result as [RFC5280]. This
>     section provides TLS-specific requirements.=E2=80=9D
>=20
> Note that RFC 5280 is already a normative reference.
>=20
> A MUST here would be a pretty material change to historical TLS =
practice.
> As Viktor says, there are TLS-using applications that just don't =
validate
> the cert via 5280 at all.

I think we want to say that if the certificates are used, then the =
certification path MUST be validated in a manner that is compatible with =
Internet X.509 certificate profile [RFC5280]; however, other approaches =
to validation of the public key, such as the DANE TLSA resource record =
[RFC6698], are also acceptable.

Russ



--Apple-Mail=_92C1E551-7AE4-46DA-919E-1EADF32EF45A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On May 15, 2017, at 7:01 PM, Eric Rescorla <ekr@rtfm.com> =
wrote:



On Mon, May 15, 2017 at 12:38 PM, =
Russ Housley <housley@vigilsec.com> wrote:
Just commenting on =
Section 4.2 =E2=80=A6



>

> > 3. Section 4.2.

> >

> >    "In general, detailed certificate validation =
procedures are out of

> >    scope for TLS (see [RFC5280]).  This section =
provides TLS-specific

> >    requirements."

> >

> > I don't see an explanation of why it is out-of-scope.  =
The reference

> > is just to RFC5280, which seems odd.  I would expect the =
reference to

> > be to something that explains why it is out-of-scope.



I think the the separation of certificate path validation from =
the TLS protocol is correct, but perhaps this can be explained =
differently.  Perhaps the approach should be that TLS depends upon =
certificate path validation as described in RFC 5280.




> In general, TLS's policy (dating back to TLS 1.0) has been that =
the

> job of TLS is to carry the certificates and other authentication

> material but to leave it up to other parts of the system to

> interpret them. It's been a long time since that decision was =
made,

> but from my perspective, there are a number of major reasons:

>

> 1. Most of PKI processing (path construction, etc.) is generic =
and

>    not specific to TLS. What is specific to TLS is:

>

>    * How to indicate what your PKI capabilities are

>      (see, e.g, S 4.2.4 and 4.3.2)

>    * How to stuff the PKI material into the protocol

>      (principally S 4.4.2)

>    * How to determine whether a given certificate is =
suitable for

>      use in TLS 4.4.4.2 and 4.3.2.1).

>

>    So we want to outsource the generic PKI part

>

>

> 2. It matches the software architecture that people often use,

>    which is to have a TLS stack but separate PKI =
validation. For

>    instance, Firefox uses NSS for TLS but moz::pkix =
for

>    validation. Similarly, Chrome uses BoringSSL for =
TLS

>    but the system PKI libraries for validation.

>

>

> In this case, I think that this text was more intended to

> say "and go read 5280 to learn how to do this". To that end,

> I suggest we say"

>

>

>     "In general detailed certificate validation =
procedures are out of

>     scope for TLS. [RFC5280] provides general =
procedures for

>     certificate validation. This section provides =
TLS-specific


>     requirements.=E2=80=9D



I agree with the reasoning, however the dependency on RFC 5280 should be =
called out in a MUST statement.  I suggest something like:



    "TLS depends on certificate path validation, and a =
conformant

    TLS implementation MUST implement certificate paths =
validation

    in a manner that achieves the same result as [RFC5280]. =
This

    section provides TLS-specific requirements.=E2=80=9D



Note that RFC 5280 is already a normative reference.

A MUST here would be a pretty material change to historical =
TLS practice.
As Viktor says, there are TLS-using =
applications that just don't validate
the cert via =
5280 at all.

I think we want to say that if the certificates =
are used, then the certification path MUST be validated in a manner that =
is compatible with Internet X.509 certificate profile [RFC5280]; =
however, other approaches to validation of the public key, such as the =
DANE TLSA resource record [RFC6698], are also acceptable.

Russ


=

--Apple-Mail=_92C1E551-7AE4-46DA-919E-1EADF32EF45A--


From nobody Tue May 16 08:24:54 2017
Return-Path: 
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 1924612EB86 for ; Tue, 16 May 2017 08:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Mx2NfT6Y0ss5 for ; Tue, 16 May 2017 08:24:51 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69F41296C9 for ; Tue, 16 May 2017 08:20:46 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id n23so77080424pfb.2 for ; Tue, 16 May 2017 08:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pMYdp1DxTp/R4wNvszvLlcSnO5uRdQ0D3ARy6JsOBak=; b=B4+dyd6CUcVhF2jfP0HsNwQgTsFDIbkhMrEqxlSHiPQb3/QhS4eBPW6ZMTw+MuqQ1r Gh2qvkVHQ/J37DbIW0WBcBgqDYChmxKz8E7Z/0EmABFlHUFk4nr0netjnu0ethUGfUco eT08MgaVidudgOkjh4CFK8XAZ5/vUgxFTQmusNcf/XDxWKd9IhNcz6+8ussDUhC4F1An cXUB7i7jeZ1Q35efJzhM9c4g1kHcncVdxQudYbE1uBaFk36p9SqyRj7sJhuPTk06qcI+ b5Q5YylYghNr0iEUGwSkEhMWz8OZnoGLhPe9SD4clcJnl+aE55Ice8WLM3+F3NQH2jQI dCqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pMYdp1DxTp/R4wNvszvLlcSnO5uRdQ0D3ARy6JsOBak=; b=FEJ8VzxTsm+WVr4rh1g0vh0EJ9trK2KmZ2cyoYJkbF1OKNUPGsPmNB4KGI22VPQbVN B50RUS4nv8jv+NunU+uiTr77NUUDktMVSgGKbFi9u9Xqgtc7tb1p1vHkK3i/q1GuwW4p QDXxLwxOGKRkfGamXVb/nkQTdMstjC25j1RnuhLi9vDG7cRzIexty5dEUQwJ8ha9kWZt rGecgUql/6sZb9IO/7Y8mteRYtoWKbW1s09b2t+hDGiwb6WvbrCcLxdidxNyVlk3YDMV lNCm9Iyk1zfSnXKFK2Mc+djXNhkzICOGKdPMQ0abLvl2RlsnC+OPTgopdJj/JAWv+VO+ ABGg==
X-Gm-Message-State: AODbwcBfk36tCI4fvaV1dot0HzWDS7Q+hDQrN1IZeVBlW7sWYiuYxCum sEw5XOUIrH+RUtz7KAk6z/3Ai0sVJg==
X-Received: by 10.84.202.163 with SMTP id x32mr3307826pld.51.1494948046372; Tue, 16 May 2017 08:20:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Tue, 16 May 2017 08:20:05 -0700 (PDT)
In-Reply-To: <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>
From: Kathleen Moriarty 
Date: Tue, 16 May 2017 11:20:05 -0400
Message-ID: 
To: Russ Housley 
Cc: Eric Rescorla , IETF TLS 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 15:24:53 -0000

On Tue, May 16, 2017 at 11:17 AM, Russ Housley  wrote=
:
>
> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
>
>
>
> On Mon, May 15, 2017 at 12:38 PM, Russ Housley  wro=
te:
>>
>> Just commenting on Section 4.2 =E2=80=A6
>>
>> >
>> > > 3. Section 4.2.
>> > >
>> > >    "In general, detailed certificate validation procedures are out o=
f
>> > >    scope for TLS (see [RFC5280]).  This section provides TLS-specifi=
c
>> > >    requirements."
>> > >
>> > > I don't see an explanation of why it is out-of-scope.  The reference
>> > > is just to RFC5280, which seems odd.  I would expect the reference t=
o
>> > > be to something that explains why it is out-of-scope.
>>
>> I think the the separation of certificate path validation from the TLS
>> protocol is correct, but perhaps this can be explained differently.  Per=
haps
>> the approach should be that TLS depends upon certificate path validation=
 as
>> described in RFC 5280.
>>
>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
>> > job of TLS is to carry the certificates and other authentication
>> > material but to leave it up to other parts of the system to
>> > interpret them. It's been a long time since that decision was made,
>> > but from my perspective, there are a number of major reasons:
>> >
>> > 1. Most of PKI processing (path construction, etc.) is generic and
>> >    not specific to TLS. What is specific to TLS is:
>> >
>> >    * How to indicate what your PKI capabilities are
>> >      (see, e.g, S 4.2.4 and 4.3.2)
>> >    * How to stuff the PKI material into the protocol
>> >      (principally S 4.4.2)
>> >    * How to determine whether a given certificate is suitable for
>> >      use in TLS 4.4.4.2 and 4.3.2.1).
>> >
>> >    So we want to outsource the generic PKI part
>> >
>> >
>> > 2. It matches the software architecture that people often use,
>> >    which is to have a TLS stack but separate PKI validation. For
>> >    instance, Firefox uses NSS for TLS but moz::pkix for
>> >    validation. Similarly, Chrome uses BoringSSL for TLS
>> >    but the system PKI libraries for validation.
>> >
>> >
>> > In this case, I think that this text was more intended to
>> > say "and go read 5280 to learn how to do this". To that end,
>> > I suggest we say"
>> >
>> >
>> >     "In general detailed certificate validation procedures are out of
>> >     scope for TLS. [RFC5280] provides general procedures for
>> >     certificate validation. This section provides TLS-specific
>> >     requirements.=E2=80=9D
>>
>> I agree with the reasoning, however the dependency on RFC 5280 should be
>> called out in a MUST statement.  I suggest something like:
>>
>>     "TLS depends on certificate path validation, and a conformant
>>     TLS implementation MUST implement certificate paths validation
>>     in a manner that achieves the same result as [RFC5280]. This
>>     section provides TLS-specific requirements.=E2=80=9D
>>
>> Note that RFC 5280 is already a normative reference.
>
>
> A MUST here would be a pretty material change to historical TLS practice.
> As Viktor says, there are TLS-using applications that just don't validate
> the cert via 5280 at all.
>
>
> I think we want to say that if the certificates are used, then the
> certification path MUST be validated in a manner that is compatible with
> Internet X.509 certificate profile [RFC5280]; however, other approaches t=
o
> validation of the public key, such as the DANE TLSA resource record
> [RFC6698], are also acceptable.

I do like this a lot better as it will help with interoperability and
security, with well defined implementation guidance.

Thank you,
Kathleen

>
> Russ
>
>



--=20

Best regards,
Kathleen


From nobody Tue May 16 08:28:15 2017
Return-Path: 
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 5514112EBC1 for ; Tue, 16 May 2017 08:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 p0Nki360lgeL for ; Tue, 16 May 2017 08:28:12 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555F1127599 for ; Tue, 16 May 2017 08:23:56 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id 132so17987280ybq.1 for ; Tue, 16 May 2017 08:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hxp7ol9xvKvbTYAd8DGTxmCv59CB/OkGpn781UW8qp0=; b=l1dcbbcmWCx+is7y02Tbp/O6uHUnxrdQukZvlgd1fDQviVVeuPyZkqmHIHqXqb3FOO 83NNW2V4iTFsxJEMGbxTSRUyaWIiwN/hErrvNPdaAkmsi2MVvCYDGhJ/8FsjYU7a6Fcb KJHXgAlSpHSrvROjOYfCoh+65RtempZGXxwjDHEb9qYwXc3EWnCtDRjGCOIMGcPA/QAN P00Zw2wjKJBdWcDGxQd8yefX+d2F2MA6lhH/a7sWp1jNBqVpPtWOX7iZNIp+HCaxS8Uz kyDc9wbjj7JeiNQ18NTM/f4m8uySy5pMeWbxQVwtqoIeiSV1W5lGhsI/xMS7xcjvBQAb 3h2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hxp7ol9xvKvbTYAd8DGTxmCv59CB/OkGpn781UW8qp0=; b=ohPhoPmoKEOhzsFV9b0IyBTVB5fr2QRWYCoTpcUvxtJ2hmXAmtxpSxhf0BKo6Ne209 texYUr2bgKZKDR7RtGvDWnN9w647M55wIRSWDGConXx3m5BpYO8a/y7rFq8cMP/OKh0a RT4bm+4WrHppvgceikI6jerCl51Kljy0PGWoXkrTbykBe+AO+VGk4RwXwHNVWPi5N/cd aEC+NbIEukH95ooonhMIJa9MTpsrk7bCqf1At2Q7rtGBdQ18JJCUcJSMsnirgnJkZzyz QwWkXWvledQ6EOEftr5btMR1cEFHAdXeg2ZN5tNu1WFcxvdEGb03gUM5XxRwqC+vOPMG /rlA==
X-Gm-Message-State: AODbwcCqrppd5V9w/75HVzQCc+hCNTTQOml139h3zv49iGOBuAmqgI25 ZvujKXleEJR5Cd8XzyOniAMgyj3L8g==
X-Received: by 10.37.161.196 with SMTP id a62mr10213480ybi.9.1494948235522; Tue, 16 May 2017 08:23:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 08:23:15 -0700 (PDT)
In-Reply-To: <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>
From: Eric Rescorla 
Date: Tue, 16 May 2017 08:23:15 -0700
Message-ID: 
To: Russ Housley 
Cc: Kathleen Moriarty , IETF TLS 
Content-Type: multipart/alternative; boundary="f403045c5632897d00054fa5c2df"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 15:28:14 -0000

--f403045c5632897d00054fa5c2df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 16, 2017 at 8:17 AM, Russ Housley  wrote:

>
> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
>
>
>
> On Mon, May 15, 2017 at 12:38 PM, Russ Housley 
> wrote:
>
>> Just commenting on Section 4.2 =E2=80=A6
>>
>> >
>> > > 3. Section 4.2.
>> > >
>> > >    "In general, detailed certificate validation procedures are out o=
f
>> > >    scope for TLS (see [RFC5280]).  This section provides TLS-specifi=
c
>> > >    requirements."
>> > >
>> > > I don't see an explanation of why it is out-of-scope.  The reference
>> > > is just to RFC5280, which seems odd.  I would expect the reference t=
o
>> > > be to something that explains why it is out-of-scope.
>>
>> I think the the separation of certificate path validation from the TLS
>> protocol is correct, but perhaps this can be explained differently.
>> Perhaps the approach should be that TLS depends upon certificate path
>> validation as described in RFC 5280.
>>
>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
>> > job of TLS is to carry the certificates and other authentication
>> > material but to leave it up to other parts of the system to
>> > interpret them. It's been a long time since that decision was made,
>> > but from my perspective, there are a number of major reasons:
>> >
>> > 1. Most of PKI processing (path construction, etc.) is generic and
>> >    not specific to TLS. What is specific to TLS is:
>> >
>> >    * How to indicate what your PKI capabilities are
>> >      (see, e.g, S 4.2.4 and 4.3.2)
>> >    * How to stuff the PKI material into the protocol
>> >      (principally S 4.4.2)
>> >    * How to determine whether a given certificate is suitable for
>> >      use in TLS 4.4.4.2 and 4.3.2.1).
>> >
>> >    So we want to outsource the generic PKI part
>> >
>> >
>> > 2. It matches the software architecture that people often use,
>> >    which is to have a TLS stack but separate PKI validation. For
>> >    instance, Firefox uses NSS for TLS but moz::pkix for
>> >    validation. Similarly, Chrome uses BoringSSL for TLS
>> >    but the system PKI libraries for validation.
>> >
>> >
>> > In this case, I think that this text was more intended to
>> > say "and go read 5280 to learn how to do this". To that end,
>> > I suggest we say"
>> >
>> >
>> >     "In general detailed certificate validation procedures are out of
>> >     scope for TLS. [RFC5280] provides general procedures for
>> >     certificate validation. This section provides TLS-specific
>> >     requirements.=E2=80=9D
>>
>> I agree with the reasoning, however the dependency on RFC 5280 should be
>> called out in a MUST statement.  I suggest something like:
>>
>>     "TLS depends on certificate path validation, and a conformant
>>     TLS implementation MUST implement certificate paths validation
>>     in a manner that achieves the same result as [RFC5280]. This
>>     section provides TLS-specific requirements.=E2=80=9D
>>
>> Note that RFC 5280 is already a normative reference.
>>
>
> A MUST here would be a pretty material change to historical TLS practice.
> As Viktor says, there are TLS-using applications that just don't validate
> the cert via 5280 at all.
>
>
> I think we want to say that if the certificates are used, then the
> certification path MUST be validated in a manner that is compatible with
> Internet X.509 certificate profile [RFC5280]; however, other approaches t=
o
> validation of the public key, such as the DANE TLSA resource record
> [RFC6698], are also acceptable.
>

I can see how you would want to say that, but it's not really consistent
either
with historical practice or with the way that other standards track RFCs
use TLS
with certificates (see RFC 5763).

-Ekr


> Russ
>
>
>

--f403045c5632897d00054fa5c2df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 16, 2017 at 8:17 AM, Russ Housley <housley@vigilsec.com=
> wrote:

On May 15, 2017, at 7:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:


<=
div class=3D"gmail_extra">
On Mon, May 15, 20=
17 at 12:38 PM, Russ Housley <housley@vigilsec.com> wrote=
:
Just commenting on Section 4.2 =E2=80=
=A6



>

> > 3. Section 4.2.

> >

> >=C2=A0 =C2=A0 "In general, detailed certificate validation pr=
ocedures are out of

> >=C2=A0 =C2=A0 scope for TLS (see [RFC5280]).=C2=A0 This section pr=
ovides TLS-specific

> >=C2=A0 =C2=A0 requirements."

> >

> > I don't see an explanation of why it is out-of-scope.=C2=A0 T=
he reference

> > is just to RFC5280, which seems odd.=C2=A0 I would expect the ref=
erence to

> > be to something that explains why it is out-of-scope.



I think the the separation of certificate path validation from the T=
LS protocol is correct, but perhaps this can be explained differently.=C2=
=A0 Perhaps the approach should be that TLS depends upon certificate path v=
alidation as described in RFC 5280.




> In general, TLS's policy (dating back to TLS 1.0) has been that th=
e

> job of TLS is to carry the certificates and other authentication

> material but to leave it up to other parts of the system to

> interpret them. It's been a long time since that decision was made=
,

> but from my perspective, there are a number of major reasons:

>

> 1. Most of PKI processing (path construction, etc.) is generic and

>=C2=A0 =C2=A0 not specific to TLS. What is specific to TLS is:

>

>=C2=A0 =C2=A0 * How to indicate what your PKI capabilities are

>=C2=A0 =C2=A0 =C2=A0 (see, e.g, S 4.2.4 and 4.3.2)

>=C2=A0 =C2=A0 * How to stuff the PKI material into the protocol

>=C2=A0 =C2=A0 =C2=A0 (principally S 4.4.2)

>=C2=A0 =C2=A0 * How to determine whether a given certificate is suitabl=
e for

>=C2=A0 =C2=A0 =C2=A0 use in TLS 4.4.4.2 and 4.3.2.1).

>

>=C2=A0 =C2=A0 So we want to outsource the generic PKI part

>

>

> 2. It matches the software architecture that people often use,

>=C2=A0 =C2=A0 which is to have a TLS stack but separate PKI validation.=
 For

>=C2=A0 =C2=A0 instance, Firefox uses NSS for TLS but moz::pkix for

>=C2=A0 =C2=A0 validation. Similarly, Chrome uses BoringSSL for TLS

>=C2=A0 =C2=A0 but the system PKI libraries for validation.

>

>

> In this case, I think that this text was more intended to

> say "and go read 5280 to learn how to do this". To that end,=


> I suggest we say"

>

>

>=C2=A0 =C2=A0 =C2=A0"In general detailed certificate validation pr=
ocedures are out of

>=C2=A0 =C2=A0 =C2=A0scope for TLS. [RFC5280] provides general procedure=
s for

>=C2=A0 =C2=A0 =C2=A0certificate validation. This section provides TLS-s=
pecific


>=C2=A0 =C2=A0 =C2=A0requirements.=E2=80=9D



I agree with the reasoning, however the dependency on RFC 5280 should be ca=
lled out in a MUST statement.=C2=A0 I suggest something like:



=C2=A0 =C2=A0 "TLS depends on certificate path validation, and a confo=
rmant

=C2=A0 =C2=A0 TLS implementation MUST implement certificate paths validatio=
n

=C2=A0 =C2=A0 in a manner that achieves the same result as [RFC5280]. This<=
br>
=C2=A0 =C2=A0 section provides TLS-specific requirements.=E2=80=9D



Note that RFC 5280 is already a normative reference.
<=
br>
A MUST here would be a pretty material change to historical T=
LS practice.
As Viktor says, there are TLS-using applications tha=
t just don't validate
the cert via 5280 at all.

I think we want to =
say that if the certificates are used, then the certification path MUST be =
validated in a manner that is compatible with Internet X.509 certificate pr=
ofile [RFC5280]; however, other approaches to validation of the public key,=
 such as the DANE TLSA resource record [RFC6698], are also acceptable.

I can see how you would want to say=
 that, but it's not really consistent either
with historical =
practice or with the way that other standards track RFCs use TLS
=
with certificates (see RFC 5763).

-Ekr
<=
br>

Russ





--f403045c5632897d00054fa5c2df--


From nobody Tue May 16 08:35:35 2017
Return-Path: 
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 4A35612EB06 for ; Tue, 16 May 2017 08:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 y0s2IV-UxtAU for ; Tue, 16 May 2017 08:35:32 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0460C12EB12 for ; Tue, 16 May 2017 08:31:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5FAD8300568 for ; Tue, 16 May 2017 11:31:30 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JpQwqmzkPRcb for ; Tue, 16 May 2017 11:31:27 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9EDC7300567; Tue, 16 May 2017 11:31:27 -0400 (EDT)
From: Russ Housley 
Message-Id: <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D75D168-4206-4CE8-97DA-1B1FD326B7AD"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 16 May 2017 11:31:27 -0400
In-Reply-To: 
Cc: Kathleen Moriarty , IETF TLS 
To: Eric Rescorla 
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 15:35:34 -0000

--Apple-Mail=_7D75D168-4206-4CE8-97DA-1B1FD326B7AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 16, 2017, at 11:23 AM, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Tue, May 16, 2017 at 8:17 AM, Russ Housley > wrote:
>=20
>> On May 15, 2017, at 7:01 PM, Eric Rescorla > wrote:
>>=20
>>=20
>>=20
>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley > wrote:
>> Just commenting on Section 4.2 =E2=80=A6
>>=20
>> >
>> > > 3. Section 4.2.
>> > >
>> > >    "In general, detailed certificate validation procedures are =
out of
>> > >    scope for TLS (see [RFC5280]).  This section provides =
TLS-specific
>> > >    requirements."
>> > >
>> > > I don't see an explanation of why it is out-of-scope.  The =
reference
>> > > is just to RFC5280, which seems odd.  I would expect the =
reference to
>> > > be to something that explains why it is out-of-scope.
>>=20
>> I think the the separation of certificate path validation from the =
TLS protocol is correct, but perhaps this can be explained differently.  =
Perhaps the approach should be that TLS depends upon certificate path =
validation as described in RFC 5280.
>>=20
>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
>> > job of TLS is to carry the certificates and other authentication
>> > material but to leave it up to other parts of the system to
>> > interpret them. It's been a long time since that decision was made,
>> > but from my perspective, there are a number of major reasons:
>> >
>> > 1. Most of PKI processing (path construction, etc.) is generic and
>> >    not specific to TLS. What is specific to TLS is:
>> >
>> >    * How to indicate what your PKI capabilities are
>> >      (see, e.g, S 4.2.4 and 4.3.2)
>> >    * How to stuff the PKI material into the protocol
>> >      (principally S 4.4.2)
>> >    * How to determine whether a given certificate is suitable for
>> >      use in TLS 4.4.4.2 and 4.3.2.1).
>> >
>> >    So we want to outsource the generic PKI part
>> >
>> >
>> > 2. It matches the software architecture that people often use,
>> >    which is to have a TLS stack but separate PKI validation. For
>> >    instance, Firefox uses NSS for TLS but moz::pkix for
>> >    validation. Similarly, Chrome uses BoringSSL for TLS
>> >    but the system PKI libraries for validation.
>> >
>> >
>> > In this case, I think that this text was more intended to
>> > say "and go read 5280 to learn how to do this". To that end,
>> > I suggest we say"
>> >
>> >
>> >     "In general detailed certificate validation procedures are out =
of
>> >     scope for TLS. [RFC5280] provides general procedures for
>> >     certificate validation. This section provides TLS-specific
>> >     requirements.=E2=80=9D
>>=20
>> I agree with the reasoning, however the dependency on RFC 5280 should =
be called out in a MUST statement.  I suggest something like:
>>=20
>>     "TLS depends on certificate path validation, and a conformant
>>     TLS implementation MUST implement certificate paths validation
>>     in a manner that achieves the same result as [RFC5280]. This
>>     section provides TLS-specific requirements.=E2=80=9D
>>=20
>> Note that RFC 5280 is already a normative reference.
>>=20
>> A MUST here would be a pretty material change to historical TLS =
practice.
>> As Viktor says, there are TLS-using applications that just don't =
validate
>> the cert via 5280 at all.
>=20
> I think we want to say that if the certificates are used, then the =
certification path MUST be validated in a manner that is compatible with =
Internet X.509 certificate profile [RFC5280]; however, other approaches =
to validation of the public key, such as the DANE TLSA resource record =
[RFC6698], are also acceptable.
>=20
> I can see how you would want to say that, but it's not really =
consistent either
> with historical practice or with the way that other standards track =
RFCs use TLS
> with certificates (see RFC 5763).

Actually, that is a great example.  I accept the need for loose =
coupling.

Russ


--Apple-Mail=_7D75D168-4206-4CE8-97DA-1B1FD326B7AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On May 16, 2017, at 11:23 AM, Eric Rescorla <ekr@rtfm.com> =
wrote:



On Tue, May 16, 2017 at 8:17 AM, =
Russ Housley <housley@vigilsec.com> wrote:

On May 15, 2017, at 7:01 PM, Eric Rescorla =
<ekr@rtfm.com> wrote:



On Mon, =
May 15, 2017 at 12:38 PM, Russ Housley <housley@vigilsec.com> wrote:
Just commenting on =
Section 4.2 =E2=80=A6



>

> > 3. Section 4.2.

> >

> >    "In general, detailed certificate validation =
procedures are out of

> >    scope for TLS (see [RFC5280]).  This section =
provides TLS-specific

> >    requirements."

> >

> > I don't see an explanation of why it is out-of-scope.  =
The reference

> > is just to RFC5280, which seems odd.  I would expect the =
reference to

> > be to something that explains why it is out-of-scope.



I think the the separation of certificate path validation from =
the TLS protocol is correct, but perhaps this can be explained =
differently.  Perhaps the approach should be that TLS depends upon =
certificate path validation as described in RFC 5280.




> In general, TLS's policy (dating back to TLS 1.0) has been that =
the

> job of TLS is to carry the certificates and other authentication

> material but to leave it up to other parts of the system to

> interpret them. It's been a long time since that decision was =
made,

> but from my perspective, there are a number of major reasons:

>

> 1. Most of PKI processing (path construction, etc.) is generic =
and

>    not specific to TLS. What is specific to TLS is:

>

>    * How to indicate what your PKI capabilities are

>      (see, e.g, S 4.2.4 and 4.3.2)

>    * How to stuff the PKI material into the protocol

>      (principally S 4.4.2)

>    * How to determine whether a given certificate is =
suitable for

>      use in TLS 4.4.4.2 and 4.3.2.1).

>

>    So we want to outsource the generic PKI part

>

>

> 2. It matches the software architecture that people often use,

>    which is to have a TLS stack but separate PKI =
validation. For

>    instance, Firefox uses NSS for TLS but moz::pkix =
for

>    validation. Similarly, Chrome uses BoringSSL for =
TLS

>    but the system PKI libraries for validation.

>

>

> In this case, I think that this text was more intended to

> say "and go read 5280 to learn how to do this". To that end,

> I suggest we say"

>

>

>     "In general detailed certificate validation =
procedures are out of

>     scope for TLS. [RFC5280] provides general =
procedures for

>     certificate validation. This section provides =
TLS-specific


>     requirements.=E2=80=9D



I agree with the reasoning, however the dependency on RFC 5280 should be =
called out in a MUST statement.  I suggest something like:



    "TLS depends on certificate path validation, and a =
conformant

    TLS implementation MUST implement certificate paths =
validation

    in a manner that achieves the same result as [RFC5280]. =
This

    section provides TLS-specific requirements.=E2=80=9D



Note that RFC 5280 is already a normative reference.

A MUST here would be a pretty material change to historical =
TLS practice.
As Viktor says, there are TLS-using =
applications that just don't validate
the cert via =
5280 at all.

I think we want to say that =
if the certificates are used, then the certification path MUST be =
validated in a manner that is compatible with Internet X.509 certificate =
profile [RFC5280]; however, other approaches to validation of the public =
key, such as the DANE TLSA resource record [RFC6698], are also =
acceptable.

I can see how you would want to say =
that, but it's not really consistent either
with =
historical practice or with the way that other standards track RFCs use =
TLS
with certificates (see RFC =
5763).

Actually, that is a great example.  I accept the =
need for loose coupling.

Russ

=

--Apple-Mail=_7D75D168-4206-4CE8-97DA-1B1FD326B7AD--


From nobody Tue May 16 08:41:28 2017
Return-Path: 
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 64E54126C89 for ; Tue, 16 May 2017 08:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 v5i0DOCB0k6u for ; Tue, 16 May 2017 08:41:24 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE1412EBAA for ; Tue, 16 May 2017 08:37:16 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id e193so82231364pfh.0 for ; Tue, 16 May 2017 08:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NhQYaox2DMOIV75emBmWjWYrSMxIwCjfiHDB8FMg0bc=; b=deAc/atLUrIRVE9H0L1rwB54ZMUXdHevIa5B1i0bszq7QLMyOuGilzJjX2pFalYzZz dVaAKPotlbFAALvFnAwqQGEZF54fX3DxIPaa4X8cpSiH+20Y6qK/PPCKf30mnEhPLw9v R26hPujpkzG4jalXKYjVn/uTorNZt8YTXfLR/Pd1Z+Jxw1R7kR8E+FyNLloVOjwbCAQj 9wSvGVtBzaA2F4KntxIsS57zH6DAqlUMuoisSGLZoMcH4uAXdbXjX7beV3IlNC69idIm PgdHxd5RWsrFhNc7WN439f3CLB51mWHroJHyP3nsuOMd0Bk6kUO0TnPvCKJVYd/VE7oS ZcHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NhQYaox2DMOIV75emBmWjWYrSMxIwCjfiHDB8FMg0bc=; b=LcphGVsDh8Rbn64Zgw6/heussw1T2iRbaI/TXZBIHStS/SXRJU3givYmKjQ6Bfj11N 2wx0EOy1uIMuz/R/A8pTvVtkgl79xmgL8UGhAnF3G9hPnkybnh8gtmLt1h6EV0yQ8Cm8 j8zOCJL4Hi0wSHoZigL4AgorARnNagSlK4ciHMyARXwmSIY7hENKeQdb13FsnIB63z+s 4j3FzPiGsel9jLjgcnAst/+z9dEFuRwt6KjzmCnpJhQeqqeQ8XtF/iSbspi+bpts5zbP 8h8Sr6EBsTC4mOM4l9PKB18R38x2Vn5MbmrausWU3nnehZ/+74hlyIbEbI9zzV6L3WJi 0ZIw==
X-Gm-Message-State: AODbwcCD4oEHP/yJPFS7GQfrhkK75Xn5W9EtJEytW+PiWajBF/olH6/n ORyD7pP/tRHjU+uve7/DOk79Sanfkg==
X-Received: by 10.99.126.20 with SMTP id z20mr12463127pgc.158.1494949036540; Tue, 16 May 2017 08:37:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Tue, 16 May 2017 08:36:36 -0700 (PDT)
In-Reply-To: <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com>
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>  <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com>
From: Kathleen Moriarty 
Date: Tue, 16 May 2017 11:36:36 -0400
Message-ID: 
To: Russ Housley 
Cc: Eric Rescorla , IETF TLS 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 15:41:26 -0000

On Tue, May 16, 2017 at 11:31 AM, Russ Housley  wrote=
:
>
> On May 16, 2017, at 11:23 AM, Eric Rescorla  wrote:
>
>
>
> On Tue, May 16, 2017 at 8:17 AM, Russ Housley  wrot=
e:
>>
>>
>> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
>>
>>
>>
>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley 
>> wrote:
>>>
>>> Just commenting on Section 4.2 =E2=80=A6
>>>
>>> >
>>> > > 3. Section 4.2.
>>> > >
>>> > >    "In general, detailed certificate validation procedures are out =
of
>>> > >    scope for TLS (see [RFC5280]).  This section provides TLS-specif=
ic
>>> > >    requirements."
>>> > >
>>> > > I don't see an explanation of why it is out-of-scope.  The referenc=
e
>>> > > is just to RFC5280, which seems odd.  I would expect the reference =
to
>>> > > be to something that explains why it is out-of-scope.
>>>
>>> I think the the separation of certificate path validation from the TLS
>>> protocol is correct, but perhaps this can be explained differently.  Pe=
rhaps
>>> the approach should be that TLS depends upon certificate path validatio=
n as
>>> described in RFC 5280.
>>>
>>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
>>> > job of TLS is to carry the certificates and other authentication
>>> > material but to leave it up to other parts of the system to
>>> > interpret them. It's been a long time since that decision was made,
>>> > but from my perspective, there are a number of major reasons:
>>> >
>>> > 1. Most of PKI processing (path construction, etc.) is generic and
>>> >    not specific to TLS. What is specific to TLS is:
>>> >
>>> >    * How to indicate what your PKI capabilities are
>>> >      (see, e.g, S 4.2.4 and 4.3.2)
>>> >    * How to stuff the PKI material into the protocol
>>> >      (principally S 4.4.2)
>>> >    * How to determine whether a given certificate is suitable for
>>> >      use in TLS 4.4.4.2 and 4.3.2.1).
>>> >
>>> >    So we want to outsource the generic PKI part
>>> >
>>> >
>>> > 2. It matches the software architecture that people often use,
>>> >    which is to have a TLS stack but separate PKI validation. For
>>> >    instance, Firefox uses NSS for TLS but moz::pkix for
>>> >    validation. Similarly, Chrome uses BoringSSL for TLS
>>> >    but the system PKI libraries for validation.
>>> >
>>> >
>>> > In this case, I think that this text was more intended to
>>> > say "and go read 5280 to learn how to do this". To that end,
>>> > I suggest we say"
>>> >
>>> >
>>> >     "In general detailed certificate validation procedures are out of
>>> >     scope for TLS. [RFC5280] provides general procedures for
>>> >     certificate validation. This section provides TLS-specific
>>> >     requirements.=E2=80=9D
>>>
>>> I agree with the reasoning, however the dependency on RFC 5280 should b=
e
>>> called out in a MUST statement.  I suggest something like:
>>>
>>>     "TLS depends on certificate path validation, and a conformant
>>>     TLS implementation MUST implement certificate paths validation
>>>     in a manner that achieves the same result as [RFC5280]. This
>>>     section provides TLS-specific requirements.=E2=80=9D
>>>
>>> Note that RFC 5280 is already a normative reference.
>>
>>
>> A MUST here would be a pretty material change to historical TLS practice=
.
>> As Viktor says, there are TLS-using applications that just don't validat=
e
>> the cert via 5280 at all.
>>
>>
>> I think we want to say that if the certificates are used, then the
>> certification path MUST be validated in a manner that is compatible with
>> Internet X.509 certificate profile [RFC5280]; however, other approaches =
to
>> validation of the public key, such as the DANE TLSA resource record
>> [RFC6698], are also acceptable.
>
>
> I can see how you would want to say that, but it's not really consistent
> either
> with historical practice or with the way that other standards track RFCs =
use
> TLS
> with certificates (see RFC 5763).
>
>
> Actually, that is a great example.  I accept the need for loose coupling.

OK, does that put us back to the suggested wording:

    "TLS depends on certificate path validation, and a conformant
     TLS implementation MUST implement certificate paths validation
     in a manner that achieves the same result as [RFC5280]. This
     section provides TLS-specific requirements.=E2=80=9D

For any developers following, does this help enough with any
interoperability questions?

Thanks,
Kathleen

>
> Russ
>



--=20

Best regards,
Kathleen


From britta.hale@ntnu.no  Tue May 16 08:34:54 2017
Return-Path: 
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 BAE19129C06 for ; Tue, 16 May 2017 08:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.503
X-Spam-Level: 
X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 NUxLTbBVuxUy for ; Tue, 16 May 2017 08:34:53 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7B6128B90 for ; Tue, 16 May 2017 08:30:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id DF6A7480089 for ; Tue, 16 May 2017 17:30:52 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XysAoeEp_D7w for ; Tue, 16 May 2017 17:30:52 +0200 (CEST)
Received: from [192.168.1.168] (84-52-238.131.3p.ntebredband.no [84.52.238.131]) by samson.item.ntnu.no (Postfix) with ESMTPSA id 5C7B4480087 for ; Tue, 16 May 2017 17:30:52 +0200 (CEST)
To: tls@ietf.org
From: Britta Hale 
Message-ID: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
Date: Tue, 16 May 2017 17:30:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 15:46:42 -0000

On the Sunday 30/05 TLS:DIV workshop there was mention of the
EndOfEarlyData message and its status as a handshake message or alert
message.

The main argument mentioned for making EndOfEarlyData a handshake
message is that alert messages usually signal "abortive closure of the
connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
misleading (i.e. possibly implying that a session is ending instead of
beginning).

However, this intuition is incorrect. Alerts signal the end-of-use of
keys, not the prohibition of further communication under other keys.
Keys should be deleted and no further data should be sent on the
connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that
session resumption is possible after a close_notify send/receipt.

It seems natural then to make EndOfEarlyData an alert message,
signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and
subsequent session key act almost as a further resumption (i.e. under a
different key).

Making EndOfEarlyData an alert message also allows for clear key
boundaries: if EndOfEarlyData is a handshake message, then we are mixing
messages protected by the the client_early_traffic_secret and
handshake_traffic_secret in the Finished message.

---
Britta


From nobody Tue May 16 09:05:35 2017
Return-Path: 
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 22B42129B9A for ; Tue, 16 May 2017 09:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2eNHdSrYmY4v for ; Tue, 16 May 2017 09:05:32 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D8E12EB91 for ; Tue, 16 May 2017 09:00:55 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id m18so14588079lfj.0 for ; Tue, 16 May 2017 09:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FJXvhcWuf/eujlHwQTTPlmk9ZAxAF/VKiE6Rv52TxIQ=; b=BJ+jVUScDzgK2cyj7Qo/6hGDMjePaf9g/a0qGWVB5oqhovKynlFZRiYvxJoore+Oms aDN+XT2wY9JjnNuw3+YXbD0Q32+Ylb2UNuz34oAnpu1mAfkr5zbZvM3cSFElu9ad2/Bj PUw4D3VVP4KcGW8ZDg7Na8gjz3Q6h5pE0Kf7etmB5Vv5/3kzOxXtHFGiVs0eng3K/9VZ tvteQcvwD4+bdGTfjEQDImhZs2GFpcAJRuCJetiPq7bnb6YmnsyBIlg0rbxmpINAO/ZI sizu0XcgJInGUiNeRD5/XI4G096gwZV0OoWeXXLVLoOyEfWxbrn4mOKZ5XOpgcd4vhP+ mCag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJXvhcWuf/eujlHwQTTPlmk9ZAxAF/VKiE6Rv52TxIQ=; b=uIbHNKmOqC++HN3GGSOeooscE30yeodkL+rH8xzFby8lJpJRz/AUR1uSRVSOqzAVHe KzavoOVbttci0pkS4G8miNbk9WFU61ftB5dCAoADoqRjCXWfwjiFKRbrMenUKawthzWG kyaX3qyL0lfBFmV8JuVs10gnNUIklyz+33W4Scn63Nc1el112h9Q/wrKVJCDn469jKO0 8RoA7a3wfdtzShrBlbQYPU/Z9PlWZ3eTGZ0AzMhmURcXxqJjcEBsA8WFpyTRF+oaV8Rn xRX5JIt6CLZl6F0SwQE9r7rJUWPbgLw5Vt+nu9kZ+Gu0Hl4IAVgQTe/lHhBtdVmIb9pa kn6Q==
X-Gm-Message-State: AODbwcBdUTbbBNniM2ZBQ6vEA3rTqUeyj8necyH4j3hTdJlxNsJ7WFve IV44jfEo0fANfGRrbOcr+YLWG7qPMg==
X-Received: by 10.25.148.20 with SMTP id w20mr3398032lfd.169.1494950453654; Tue, 16 May 2017 09:00:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Tue, 16 May 2017 09:00:53 -0700 (PDT)
In-Reply-To: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
From: Martin Thomson 
Date: Tue, 16 May 2017 12:00:53 -0400
Message-ID: 
To: Britta Hale 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 16:05:34 -0000

Would we also send an alert on key update?

On 16 May 2017 at 11:30, Britta Hale  wrote:
> On the Sunday 30/05 TLS:DIV workshop there was mention of the
> EndOfEarlyData message and its status as a handshake message or alert
> message.
>
> The main argument mentioned for making EndOfEarlyData a handshake
> message is that alert messages usually signal "abortive closure of the
> connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
> misleading (i.e. possibly implying that a session is ending instead of
> beginning).
>
> However, this intuition is incorrect. Alerts signal the end-of-use of
> keys, not the prohibition of further communication under other keys.
> Keys should be deleted and no further data should be sent on the
> connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that
> session resumption is possible after a close_notify send/receipt.
>
> It seems natural then to make EndOfEarlyData an alert message,
> signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
> followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
> that key, while in parallel the remainder of the handshake and
> subsequent session key act almost as a further resumption (i.e. under a
> different key).
>
> Making EndOfEarlyData an alert message also allows for clear key
> boundaries: if EndOfEarlyData is a handshake message, then we are mixing
> messages protected by the the client_early_traffic_secret and
> handshake_traffic_secret in the Finished message.
>
> ---
> Britta
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue May 16 09:44:01 2017
Return-Path: 
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 BB422128B51 for ; Tue, 16 May 2017 09:43:59 -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] 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 B3p4oHwFi2wx for ; Tue, 16 May 2017 09:43:58 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9758128768 for ; Tue, 16 May 2017 09:37:44 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6E66D7A32F1 for ; Tue, 16 May 2017 16:37:43 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Tue, 16 May 2017 12:37:42 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org>
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>  <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com> 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 16:44:00 -0000

> On May 16, 2017, at 11:36 AM, Kathleen Moriarty =
 wrote:
>=20
> OK, does that put us back to the suggested wording:
>=20
>    "TLS depends on certificate path validation, and a conformant
>     TLS implementation MUST implement certificate paths validation
>     in a manner that achieves the same result as [RFC5280]. This
>     section provides TLS-specific requirements.=E2=80=9D
>=20
> For any developers following, does this help enough with any
> interoperability questions?

TLS does not depend on certificate path validation.  Many TLS
*applications* rely PKIX certificate path validation (along with
RFC 6125 server identity verification), but TLS itself supports
various alternative authentication (and non-authentication) modes.

   * PSK or SRP without certificates
   * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <=3D =
1.2)
   * TOFU public key pinning
   * Static leaf key or leaf cert matching
   * RFC7250 raw public keys
   * DANE-EE(3) leaf certificate/key verification, without expiration
     or server name checks
   * DANE-EE(3) ... with name checks (where UKS attack are relevant)
   * DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
     is part of the chain, and identified via DNS TLSA records.
   * PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
   * PKIX-TA(0) which is RFC5280 + DANE CA "constraint"

Keeping in mind that many implementations of RFC5280 violate that =
specification
by interpreting EKUs in CA certificates to constrain the kinds of =
certificates
that the CA may issue.  That de-facto usage is I think much more widely =
implemented
than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

--=20
	Viktor.


From nobody Tue May 16 09:54:35 2017
Return-Path: 
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 001A0129427 for ; Tue, 16 May 2017 09:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xDEj7UTtovpW for ; Tue, 16 May 2017 09:54:30 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682481200F3 for ; Tue, 16 May 2017 09:50:20 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id u187so79080560pgb.0 for ; Tue, 16 May 2017 09:50:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=xbS/GNEn3cARmbBElQab0Lepx/zi66BHdcze1XNKGHM=; b=F1RJAaUvkdz6RUIWeL5S5xOMwsDd84qF3cn8qIFitZkJkEP6x69lR0sDr1Zlgh8961 opql8fvWEd05EidjtjuE1IZOqb5YKYfaGGgCqDE9OccL/PsGIsFxH7UEMgh/ZpIzEUqi Tiyo5psJHDkHzUYN7NflZAOdR1i/YiDpz2f/hIvfDaiB5zFiuJzGhYiq/TpZPaZ0W74s jG0EXfL19KaprbDrsh7ZaXPwRH7R1+rQ/aCAm3XIPz2l6cyQSDzjV75RZr6te3RBgmM6 pOPIpDAWswOILi0s4rrMrfNoJ5SZCxypMso9SD3L+/nrSZ/35B0A6jm/ywsErdZaiSVP 9G6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=xbS/GNEn3cARmbBElQab0Lepx/zi66BHdcze1XNKGHM=; b=CFhNNeOXIa5Sen0YQi7b+WUzJFpjcF2wFK9XRQ7g+dqceYow9F9FyJjU31Zrlc3AaO en6ypUB74xQ/kF8539OstLpvpjHBCkTqzg8nYO00TE+Thfg5qbNVxO6npmuJ4UcdvZZl 8MrKLrWBDpWADJ++dlalhWiySwiqVUQbxwgSO9OLRzhZiliE8sbRdlM9uPY6qB5Iiwmz MBZ6jtq/9j9ihjoXy0Fgg/nxdtjb6wz/1+9VlZRIlLgy72EPC5yPMuadJnRPQh9Y3VZd u+vV1gyG2I49KUM2n+H3m4UlVXHEG9JTVvyp93sPUayKUNN/JjW5OfcuI0S64GIOdRV9 fSWQ==
X-Gm-Message-State: AODbwcCQi216TXkvYBKKvVtLVYDYw5wTx8xg28zDGOR/x9mec3DVsnbI 8M2kFdrGUKBjtkfD0wPhbBlwk1GIGtl5
X-Received: by 10.84.193.129 with SMTP id f1mr17400602pld.129.1494953419912; Tue, 16 May 2017 09:50:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Tue, 16 May 2017 09:49:39 -0700 (PDT)
In-Reply-To: <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org>
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>  <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com>  <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org>
From: Kathleen Moriarty 
Date: Tue, 16 May 2017 12:49:39 -0400
Message-ID: 
To: TLS WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 16:54:34 -0000

On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni
 wrote:
>
>> On May 16, 2017, at 11:36 AM, Kathleen Moriarty  wrote:
>>
>> OK, does that put us back to the suggested wording:
>>
>>    "TLS depends on certificate path validation, and a conformant
>>     TLS implementation MUST implement certificate paths validation
>>     in a manner that achieves the same result as [RFC5280]. This
>>     section provides TLS-specific requirements.=E2=80=9D
>>
>> For any developers following, does this help enough with any
>> interoperability questions?
>
> TLS does not depend on certificate path validation.  Many TLS
> *applications* rely PKIX certificate path validation (along with
> RFC 6125 server identity verification), but TLS itself supports
> various alternative authentication (and non-authentication) modes.
>
>    * PSK or SRP without certificates
>    * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <=3D=
 1.2)
>    * TOFU public key pinning
>    * Static leaf key or leaf cert matching
>    * RFC7250 raw public keys
>    * DANE-EE(3) leaf certificate/key verification, without expiration
>      or server name checks
>    * DANE-EE(3) ... with name checks (where UKS attack are relevant)
>    * DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
>      is part of the chain, and identified via DNS TLSA records.
>    * PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
>    * PKIX-TA(0) which is RFC5280 + DANE CA "constraint"
>
> Keeping in mind that many implementations of RFC5280 violate that specifi=
cation
> by interpreting EKUs in CA certificates to constrain the kinds of certifi=
cates
> that the CA may issue.  That de-facto usage is I think much more widely i=
mplemented
> than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

Sorry, I grabbed the wrong text as I was ineffective at multi-tasking.
I think we are back to the following text and would like to confirm
that and make sure it is agreeable to the WG and implementers:

    "In general detailed certificate validation procedures are out of
    scope for TLS. [RFC5280] provides general procedures for
    certificate validation. This section provides TLS-specific
    requirements."

There's also a thread that was discussing some interoperability
problems related to validation and I'd like to see the resolution for
that as well.

Thanks,
Kathleen

>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--=20

Best regards,
Kathleen


From britta.hale@item.ntnu.no  Mon May 15 08:21:07 2017
Return-Path: 
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 0CD3F129486 for ; Mon, 15 May 2017 08:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.503
X-Spam-Level: 
X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 gCiX4LR7suCn for ; Mon, 15 May 2017 08:21:05 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E13E124281 for ; Mon, 15 May 2017 08:16:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id 72EB648008D for ; Mon, 15 May 2017 17:16:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK_pi8CjM4Kl for ; Mon, 15 May 2017 17:16:03 +0200 (CEST)
Received: from [129.241.200.211] (dhcp-200-211.item.ntnu.no [129.241.200.211]) by samson.item.ntnu.no (Postfix) with ESMTPSA id E19D7480087 for ; Mon, 15 May 2017 17:16:03 +0200 (CEST)
From: Britta Hale 
To: tls@ietf.org
Message-ID: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>
Date: Mon, 15 May 2017 17:16:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Ug5FEA3AGIdaMMwf8dmWIE4J6dujax7M"
Archived-At: 
X-Mailman-Approved-At: Tue, 16 May 2017 10:31:45 -0700
Subject: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 15:48:22 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1Ug5FEA3AGIdaMMwf8dmWIE4J6dujax7M
Content-Type: multipart/mixed; boundary="K1qx4EPkksrQcvcAKSoPevNhWXxR5cwcg";
 protected-headers="v1"
From: Britta Hale 
To: tls@ietf.org
Message-ID: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>
Subject: Comments on EndOfEarlyData

--K1qx4EPkksrQcvcAKSoPevNhWXxR5cwcg
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On the Sunday 30/05 TLS:DIV workshop there was mention of the
EndOfEarlyData message and its status as a handshake message or alert
message.

The main argument mentioned for making EndOfEarlyData a handshake
message is that alert messages usually signal "abortive closure of the
connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
misleading (i.e. possibly implying that a session is ending instead of
beginning).

However, this intuition is incorrect. Alerts signal the end-of-use of
keys, not the prohibition of further communication under other keys.
Keys should be deleted and no further data should be sent on the
connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that
session resumption is possible after a close_notify send/receipt.

It seems natural then to make EndOfEarlyData an alert message,
signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and
subsequent session key act almost as a further resumption (i.e. under a
different key).

Making EndOfEarlyData an alert message also allows for clear key
boundaries: if EndOfEarlyData is a handshake message, then we are mixing
messages protected by the the client_early_traffic_secret and
handshake_traffic_secret in the Finished message.

---
Britta


--K1qx4EPkksrQcvcAKSoPevNhWXxR5cwcg--

--1Ug5FEA3AGIdaMMwf8dmWIE4J6dujax7M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJZGcYzAAoJEH5jOW80LQAqSmQP/Av3Mlw9lO1SIVFqpdz8BM1U
BDpg6Fr+nJJWYmU17ZAPRokc2HkVEO6Ax6ijRsUHE3pJSPCvg/6cx4YAdTAHc/F7
kv8xiksDCS9sakiq00hCIPza5dIFpqyN979MYwZXdVgJrCvI3W3oDSfe4ozNR1lq
FGuDwWO0KHd4/MqcveFzcSjmfnWvuDsd8QHTUbJgRRD+Ufj5Dpwh4P+0H07hj8FX
jZEHdP1gVT6XW+INF/RaSV6BGNzyLKQDdk3o6FiLfzky62j570rG+0z/QGzT8nY6
wMo/IRFygMEfF0KxM716PHfECd8LQKp72melgUAq6njucxWRNlJaWxpFNXbvPkWd
Y7a+JiX+6W4EzMIAds0Lsri2jBWO2rK82pbliFHWwze7I7xGS+VVNmHZYdcT6sVz
rYQBoGkbRXeO2on5AJ27Xb1e7e7tPkbXNqn7ULD4d0yixPL5Pe1deRhkzRTp2xYa
AVgsAYVh/aj+JDAdWfnzWbcjzDnPuX9yg2l01HsxkCuplxJZKQ6TOItwyi9Au2Zl
kgICz9WedEyUCo4R6a1uuc1enWSnIqaz6Oi/9WWaU9zZyXcUg1XCTWR+1f5QEBs7
4OdygS+e9OQyp73/SwIoL/MNqGIrSXdVRpB//jSDRS6imtQfL4g6eVg9nmdKf3wS
KFK/hav5EnFevh1VYnp+
=SjA+
-----END PGP SIGNATURE-----

--1Ug5FEA3AGIdaMMwf8dmWIE4J6dujax7M--


From nobody Tue May 16 10:32:12 2017
Return-Path: 
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 342DB12EAB3 for ; Wed, 10 May 2017 13:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level: 
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_XBL=0.375, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 G2frv9g8smyj for ; Wed, 10 May 2017 13:17:18 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87D212EAA7 for ; Wed, 10 May 2017 13:17:06 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id v4AKFtXw029772; Wed, 10 May 2017 13:15:55 -0700
Message-Id: <201705102015.v4AKFtXw029772@new.toad.com>
To: RFC Errata System 
cc: pwouters@redhat.com, Hannes.Tschofenig@gmx.net, gnu@toad.com, weiler@tislabs.com, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com, x@example.net, tls@ietf.org
In-reply-to: <20170510064522.66A00B81089@rfc-editor.org> 
References: <20170510064522.66A00B81089@rfc-editor.org>
Comments: In-reply-to RFC Errata System  message dated "Tue, 09 May 2017 23:45:22 -0700."
Date: Wed, 10 May 2017 13:15:55 -0700
From: John Gilmore 
Archived-At: 
X-Mailman-Approved-At: Tue, 16 May 2017 10:32:09 -0700
Subject: Re: [TLS] [Technical Errata Reported] RFC7250 (5013)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 20:17:19 -0000

I agree that the erratum is an editorial, not technical, change.

It is a slight improvement on the current wording, but is in no way
required for interoperability, since the same information is available
at the source already cited in the paragraph (the TLS ExtensionType
Values subregistry at IANA).

I recommend that we keep it in the editorial queue for folding
in if/when the RFC is ever revised for other reasons.

	John


From nobody Tue May 16 10:48:34 2017
Return-Path: 
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 BC4A71293F3 for ; Tue, 16 May 2017 10:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 omrdzUyg3YqR for ; Tue, 16 May 2017 10:48:29 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B495912944C for ; Tue, 16 May 2017 10:43:34 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id w50so81330075wrc.0 for ; Tue, 16 May 2017 10:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xm/lnQOuqLkXzG+/WtR0Hr+YFtvpzTyoqD701kS4qkY=; b=ri8leqZFXGNv88ljZHhcHo9fsY5u8/R1YXu7Sz9JvwF8pLNObAZmd9PFJ2BlkV5Kol amma4w3+ZcrXRZx+RCcdrtMC7NWnNztfXp65szPt1gm63lZ9UIGWwEKMlGQDQepbK71/ 0iPSSJVooUvhY2tGBFSYr6HzSNappwEGD5he433Sd8FSv/PCNnxQ/BlPBynbGvQOhw1F Zoyw2y0nMOtV31X9KN0vi5jXjEzCgLyp4BsLm/70yl0LQIPr14E2xMSC3aV89BEK/vI3 23+CvmsDYzgom9/d+LqQmEJwHKi9lC/mlX68d2PWQv8AjYW7nXs5azXpCgmVC/c9b5g8 334g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xm/lnQOuqLkXzG+/WtR0Hr+YFtvpzTyoqD701kS4qkY=; b=lpluAuMY0F9NJe0/xl98mzDc35Q2VtFjz3r0Q8b2y5JW6BY0kJjeGDe94XKYhNSQby QwSOCIpaAs6RSYpmekPaPEvXZCnJ1tCqHqCthy1cMx1eeGOuvP2eEsLAlc/GXiXfftg+ kVByEtWCs01trarreix++uXtjN39VtlYI/Ho+GvyU8AWMUfJRrLavj3P28hUeDaHB0J+ /8dXTIcD94707Ro7CfT5/NbYiTvPqZFGgYAnrfEQb9DvwpGfNUMEpxOR3BCp++brpkzi lKf4RJGeVqoXi+L+hBPMlEDyJWU7P4YCZ+H4n0J2FtzevrUpGujLvhLQf/TU0tXli63w l9yA==
X-Gm-Message-State: AODbwcBTuybXGjWLO3XAVj6cUnU7pIbB7pyGlc1QYyCD191X+WpbFRbx TifKIWfK6NGwEPCdlKY+mp5qPMjOUNRk
X-Received: by 10.223.142.135 with SMTP id q7mr8327185wrb.180.1494956613068; Tue, 16 May 2017 10:43:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.179.68 with HTTP; Tue, 16 May 2017 10:43:32 -0700 (PDT)
In-Reply-To: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>
References: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>
From: Richard Barnes 
Date: Tue, 16 May 2017 13:43:32 -0400
Message-ID: 
To: Britta Hale 
Cc: "" 
Content-Type: multipart/alternative; boundary="f403045f4ec4e0a2f9054fa7b55b"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 17:48:32 -0000

--f403045f4ec4e0a2f9054fa7b55b
Content-Type: text/plain; charset="UTF-8"

On Mon, May 15, 2017 at 11:16 AM, Britta Hale 
wrote:

> On the Sunday 30/05 TLS:DIV workshop there was mention of the
> EndOfEarlyData message and its status as a handshake message or alert
> message.
>
> The main argument mentioned for making EndOfEarlyData a handshake
> message is that alert messages usually signal "abortive closure of the
> connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
> misleading (i.e. possibly implying that a session is ending instead of
> beginning).
>
> However, this intuition is incorrect. Alerts signal the end-of-use of
> keys, not the prohibition of further communication under other keys.
> Keys should be deleted and no further data should be sent on the
> connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that
> session resumption is possible after a close_notify send/receipt.
>
> It seems natural then to make EndOfEarlyData an alert message,
> signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
> followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
> that key, while in parallel the remainder of the handshake and
> subsequent session key act almost as a further resumption (i.e. under a
> different key).
>

As has been pointed out elsewhere, other key changes are signaled with a
handshake message (KeyUpdate), so using a handshake message seems more
natural from a protocol point of view.


> Making EndOfEarlyData an alert message also allows for clear key
> boundaries: if EndOfEarlyData is a handshake message, then we are mixing
> messages protected by the the client_early_traffic_secret and
> handshake_traffic_secret in the Finished message.
>

The Finished MAC already mixes data from two different traffic keys
(client/server) and data aren't encrypted at all (ClientHello /
ServerHello).  If you want to argue that the client and server handshake
keys are related by both being derived from the handshake_traffic_secret,
you could just as well argue that all three keys are related by all being
derived from EarlySecret.

--Richard



>
> ---
> Britta
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--f403045f4ec4e0a2f9054fa7b55b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, May 15, 2017 at 11:16 AM, Britta Hale <britta.hale@item=
.ntnu.no> wrote:
On the S=
unday 30/05 TLS:DIV workshop there was mention of the

EndOfEarlyData message and its status as a handshake message or alert

message.



The main argument mentioned for making EndOfEarlyData a handshake

message is that alert messages usually signal "abortive closure of the=


connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could =
be

misleading (i.e. possibly implying that a session is ending instead of

beginning).



However, this intuition is incorrect. Alerts signal the end-of-use of

keys, not the prohibition of further communication under other keys.

Keys should be deleted and no further data should be sent on the

connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that

session resumption is possible after a close_notify send/receipt.



It seems natural then to make EndOfEarlyData an alert message,

signifying end of 0-RTT data. Specifically, the 0-RTT handshake is

followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and

subsequent session key act almost as a further resumption (i.e. under a

different key).

As has been pointed out=
 elsewhere, other key changes are signaled with a handshake message (KeyUpd=
ate), so using a handshake message seems more natural from a protocol point=
 of view.
=C2=A0

Making EndOfEarlyData an alert message also allows for clear key

boundaries: if EndOfEarlyData is a handshake message, then we are mixing
messages protected by the the client_early_traffic_secret and

handshake_traffic_secret in the Finished message.

=

The Finished MAC already mixes data from two different traffic k=
eys (client/server) and data aren't encrypted at all (ClientHello / Ser=
verHello).=C2=A0 If you want to argue that the client and server handshake =
keys are related by both being derived from the handshake_traffic_secret, y=
ou could just as well argue that all three keys are related by all being de=
rived from EarlySecret.

--Richard

=C2=A0



---

Britta




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f403045f4ec4e0a2f9054fa7b55b--


From nobody Tue May 16 10:50:12 2017
Return-Path: 
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 3C01412946A for ; Tue, 16 May 2017 10:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 6Lv3aIRqGig0 for ; Tue, 16 May 2017 10:50:07 -0700 (PDT)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23160129489 for ; Tue, 16 May 2017 10:45:21 -0700 (PDT)
Received: by mail-yb0-x236.google.com with SMTP id p143so37183809yba.2 for ; Tue, 16 May 2017 10:45:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NO2YHmgDavdX8LogEdBbFjVeZfWets18VjC8+abdC/s=; b=EXLN8WuRjR9dvfCqkmlDrda2u2/nVSNIUcOwOIbkDipE7q7ze0bAP7lZw5WvyHBDTY ozsc5K7+WIHgMB1VdI8zAm5X5esG+F0X2z2rS6EcQ3vvrlxjfhXDFjefC0Ca6FKvdXy7 5gQe/g+DkQXZpWdWy0wxH+O/sFJsBx8iFKHUxEDdrNVmBuirrU3lNvWL5PoCb6HODfih Empf1Id/kb/GRpvIUGP83JGqHsxJ2VchmV4dFbogVMEkjJaVG+mqbWRmeIpgZ0478R45 Wpl09aoNVGGl4Pd99Yd+AWoSD4cWgpmz4Tu5UtkWS5ZxORZpp/hYSeJCppRccjlcxpee MbNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NO2YHmgDavdX8LogEdBbFjVeZfWets18VjC8+abdC/s=; b=PTkPkOH4qveSi+ZdDE8egnLNPlma4AZGfXwZyJf58/K0ufW+KIHyq2QdG3Z37c1RSX pRmo2NCZzVYfzIgdxNhjoMUVYqDxGmLW+qF9c60W+Jylz8OAMUxvcmAnIP/9P3mRH6eq MYQkGc38asHtFH/FbWpVWZHYy940iWLjKeN+b9GEu/USHgcR6H5noQJ6kurBXNYUHdlp /KPLzu6CqltlLjRTAdCbHo9pMxWi3+/VKf29i4xpMxrDV+faTlMFABbRDntsBCBtZqh0 F03L/EE8Kw1iKpgoejgayX50OEJvKiz+WoNLt7yLTSoRAs1UUwsA5UyuXqX0iv9+Pwd5 Qt/g==
X-Gm-Message-State: AODbwcAI9hWXQIeTSdy/nzmFicrLVWMdwrSaji9SJR9kihTZCLhwbCmi 6SxNix9aO32z+KH3zGOk8xGHiBc7mA==
X-Received: by 10.37.174.24 with SMTP id a24mr10744496ybj.50.1494956720258; Tue, 16 May 2017 10:45:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 10:44:39 -0700 (PDT)
In-Reply-To: 
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>  <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com> 
From: Eric Rescorla 
Date: Tue, 16 May 2017 10:44:39 -0700
Message-ID: 
To: Kathleen Moriarty 
Cc: Russ Housley , IETF TLS 
Content-Type: multipart/alternative; boundary="f403045da3584499a4054fa7bccb"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 17:50:10 -0000

--f403045da3584499a4054fa7bccb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 16, 2017 at 8:36 AM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> On Tue, May 16, 2017 at 11:31 AM, Russ Housley 
> wrote:
> >
> > On May 16, 2017, at 11:23 AM, Eric Rescorla  wrote:
> >
> >
> >
> > On Tue, May 16, 2017 at 8:17 AM, Russ Housley 
> wrote:
> >>
> >>
> >> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
> >>
> >>
> >>
> >> On Mon, May 15, 2017 at 12:38 PM, Russ Housley 
> >> wrote:
> >>>
> >>> Just commenting on Section 4.2 =E2=80=A6
> >>>
> >>> >
> >>> > > 3. Section 4.2.
> >>> > >
> >>> > >    "In general, detailed certificate validation procedures are ou=
t
> of
> >>> > >    scope for TLS (see [RFC5280]).  This section provides
> TLS-specific
> >>> > >    requirements."
> >>> > >
> >>> > > I don't see an explanation of why it is out-of-scope.  The
> reference
> >>> > > is just to RFC5280, which seems odd.  I would expect the referenc=
e
> to
> >>> > > be to something that explains why it is out-of-scope.
> >>>
> >>> I think the the separation of certificate path validation from the TL=
S
> >>> protocol is correct, but perhaps this can be explained differently.
> Perhaps
> >>> the approach should be that TLS depends upon certificate path
> validation as
> >>> described in RFC 5280.
> >>>
> >>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
> >>> > job of TLS is to carry the certificates and other authentication
> >>> > material but to leave it up to other parts of the system to
> >>> > interpret them. It's been a long time since that decision was made,
> >>> > but from my perspective, there are a number of major reasons:
> >>> >
> >>> > 1. Most of PKI processing (path construction, etc.) is generic and
> >>> >    not specific to TLS. What is specific to TLS is:
> >>> >
> >>> >    * How to indicate what your PKI capabilities are
> >>> >      (see, e.g, S 4.2.4 and 4.3.2)
> >>> >    * How to stuff the PKI material into the protocol
> >>> >      (principally S 4.4.2)
> >>> >    * How to determine whether a given certificate is suitable for
> >>> >      use in TLS 4.4.4.2 and 4.3.2.1).
> >>> >
> >>> >    So we want to outsource the generic PKI part
> >>> >
> >>> >
> >>> > 2. It matches the software architecture that people often use,
> >>> >    which is to have a TLS stack but separate PKI validation. For
> >>> >    instance, Firefox uses NSS for TLS but moz::pkix for
> >>> >    validation. Similarly, Chrome uses BoringSSL for TLS
> >>> >    but the system PKI libraries for validation.
> >>> >
> >>> >
> >>> > In this case, I think that this text was more intended to
> >>> > say "and go read 5280 to learn how to do this". To that end,
> >>> > I suggest we say"
> >>> >
> >>> >
> >>> >     "In general detailed certificate validation procedures are out =
of
> >>> >     scope for TLS. [RFC5280] provides general procedures for
> >>> >     certificate validation. This section provides TLS-specific
> >>> >     requirements.=E2=80=9D
> >>>
> >>> I agree with the reasoning, however the dependency on RFC 5280 should
> be
> >>> called out in a MUST statement.  I suggest something like:
> >>>
> >>>     "TLS depends on certificate path validation, and a conformant
> >>>     TLS implementation MUST implement certificate paths validation
> >>>     in a manner that achieves the same result as [RFC5280]. This
> >>>     section provides TLS-specific requirements.=E2=80=9D
> >>>
> >>> Note that RFC 5280 is already a normative reference.
> >>
> >>
> >> A MUST here would be a pretty material change to historical TLS
> practice.
> >> As Viktor says, there are TLS-using applications that just don't
> validate
> >> the cert via 5280 at all.
> >>
> >>
> >> I think we want to say that if the certificates are used, then the
> >> certification path MUST be validated in a manner that is compatible wi=
th
> >> Internet X.509 certificate profile [RFC5280]; however, other approache=
s
> to
> >> validation of the public key, such as the DANE TLSA resource record
> >> [RFC6698], are also acceptable.
> >
> >
> > I can see how you would want to say that, but it's not really consisten=
t
> > either
> > with historical practice or with the way that other standards track RFC=
s
> use
> > TLS
> > with certificates (see RFC 5763).
> >
> >
> > Actually, that is a great example.  I accept the need for loose couplin=
g.
>
> OK, does that put us back to the suggested wording:
>
>     "TLS depends on certificate path validation, and a conformant
>      TLS implementation MUST implement certificate paths validation
>      in a manner that achieves the same result as [RFC5280]. This
>      section provides TLS-specific requirements.=E2=80=9D
>

Hmm... I don't think so. Wouldn't the fingerprint-matching prescribed by
5763
contradict this?

-Ekr


> For any developers following, does this help enough with any
> interoperability questions?
>
> Thanks,
> Kathleen
>
> >
> > Russ
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>

--f403045da3584499a4054fa7bccb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Tue, May 16, 2017 at 8:36 AM, Kathleen Moriarty <kathlee=
n.moriarty.ietf@gmail.com> wrote:
On Tue, May 16, 2017 at 11:3=
1 AM, Russ Housley <housley@vigi=
lsec.com> wrote:

>

> On May 16, 2017, at 11:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>

>

>

> On Tue, May 16, 2017 at 8:17 AM, Russ Housley <housley@vigilsec.com> wrote:

>>

>>

>> On May 15, 2017, at 7:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>

>>

>>

>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <housley@vigilsec.com>

>> wrote:

>>>

>>> Just commenting on Section 4.2 =E2=80=A6

>>>

>>> >

>>> > > 3. Section 4.2.

>>> > >

>>> > >=C2=A0 =C2=A0 "In general, detailed certificate =
validation procedures are out of

>>> > >=C2=A0 =C2=A0 scope for TLS (see [RFC5280]).=C2=A0 Th=
is section provides TLS-specific

>>> > >=C2=A0 =C2=A0 requirements."

>>> > >

>>> > > I don't see an explanation of why it is out-of-s=
cope.=C2=A0 The reference

>>> > > is just to RFC5280, which seems odd.=C2=A0 I would e=
xpect the reference to

>>> > > be to something that explains why it is out-of-scope=
.

>>>

>>> I think the the separation of certificate path validation from=
 the TLS

>>> protocol is correct, but perhaps this can be explained differe=
ntly.=C2=A0 Perhaps

>>> the approach should be that TLS depends upon certificate path =
validation as

>>> described in RFC 5280.

>>>

>>> > In general, TLS's policy (dating back to TLS 1.0) has=
 been that the

>>> > job of TLS is to carry the certificates and other authent=
ication

>>> > material but to leave it up to other parts of the system =
to

>>> > interpret them. It's been a long time since that deci=
sion was made,

>>> > but from my perspective, there are a number of major reas=
ons:

>>> >

>>> > 1. Most of PKI processing (path construction, etc.) is ge=
neric and

>>> >=C2=A0 =C2=A0 not specific to TLS. What is specific to TLS=
 is:

>>> >

>>> >=C2=A0 =C2=A0 * How to indicate what your PKI capabilities=
 are

>>> >=C2=A0 =C2=A0 =C2=A0 (see, e.g, S 4.2.4 and 4.3.2)

>>> >=C2=A0 =C2=A0 * How to stuff the PKI material into the pro=
tocol

>>> >=C2=A0 =C2=A0 =C2=A0 (principally S 4.4.2)

>>> >=C2=A0 =C2=A0 * How to determine whether a given certifica=
te is suitable for

>>> >=C2=A0 =C2=A0 =C2=A0 use in TLS 4.4.4.2 and 4.3.2.1).

>>> >

>>> >=C2=A0 =C2=A0 So we want to outsource the generic PKI part=


>>> >

>>> >

>>> > 2. It matches the software architecture that people often=
 use,

>>> >=C2=A0 =C2=A0 which is to have a TLS stack but separate PK=
I validation. For

>>> >=C2=A0 =C2=A0 instance, Firefox uses NSS for TLS but moz::=
pkix for

>>> >=C2=A0 =C2=A0 validation. Similarly, Chrome uses BoringSSL=
 for TLS

>>> >=C2=A0 =C2=A0 but the system PKI libraries for validation.=


>>> >

>>> >

>>> > In this case, I think that this text was more intended to=


>>> > say "and go read 5280 to learn how to do this".=
 To that end,

>>> > I suggest we say"

>>> >

>>> >

>>> >=C2=A0 =C2=A0 =C2=A0"In general detailed certificate =
validation procedures are out of

>>> >=C2=A0 =C2=A0 =C2=A0scope for TLS. [RFC5280] provides gene=
ral procedures for

>>> >=C2=A0 =C2=A0 =C2=A0certificate validation. This section p=
rovides TLS-specific

>>> >=C2=A0 =C2=A0 =C2=A0requirements.=E2=80=9D

>>>

>>> I agree with the reasoning, however the dependency on RFC 5280=
 should be

>>> called out in a MUST statement.=C2=A0 I suggest something like=
:

>>>

>>>=C2=A0 =C2=A0 =C2=A0"TLS depends on certificate path valid=
ation, and a conformant

>>>=C2=A0 =C2=A0 =C2=A0TLS implementation MUST implement certifica=
te paths validation

>>>=C2=A0 =C2=A0 =C2=A0in a manner that achieves the same result a=
s [RFC5280]. This

>>>=C2=A0 =C2=A0 =C2=A0section provides TLS-specific requirements.=
=E2=80=9D

>>>

>>> Note that RFC 5280 is already a normative reference.

>>

>>

>> A MUST here would be a pretty material change to historical TLS pr=
actice.

>> As Viktor says, there are TLS-using applications that just don'=
;t validate

>> the cert via 5280 at all.

>>

>>

>> I think we want to say that if the certificates are used, then the=


>> certification path MUST be validated in a manner that is compatibl=
e with

>> Internet X.509 certificate profile [RFC5280]; however, other appro=
aches to

>> validation of the public key, such as the DANE TLSA resource recor=
d

>> [RFC6698], are also acceptable.

>

>

> I can see how you would want to say that, but it's not really cons=
istent

> either

> with historical practice or with the way that other standards track RF=
Cs use

> TLS

> with certificates (see RFC 5763).

>

>

> Actually, that is a great example.=C2=A0 I accept the need for loose c=
oupling.




OK, does that put us back to the suggested wording:



=C2=A0 =C2=A0 "TLS depends on certificate path validation, and a confo=
rmant

=C2=A0 =C2=A0 =C2=A0TLS implementation MUST implement certificate paths val=
idation

=C2=A0 =C2=A0 =C2=A0in a manner that achieves the same result as [RFC5280].=
 This

=C2=A0 =C2=A0 =C2=A0section provides TLS-specific requirements.=E2=80=9D

Hmm... I don't think so. Would=
n't the fingerprint-matching prescribed by 5763
contradict th=
is?

-Ekr




For any developers following, does this help enough with any

interoperability questions?



Thanks,


Kathleen



>

> Russ

>







--



Best regards,

Kathleen





--f403045da3584499a4054fa7bccb--


From nobody Tue May 16 11:22:07 2017
Return-Path: 
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 4C9FB12EC40 for ; Tue, 16 May 2017 11:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 t1Z0s2lNp2iw for ; Tue, 16 May 2017 11:22:04 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A0012EC47 for ; Tue, 16 May 2017 11:17:12 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id u187so80134704pgb.0 for ; Tue, 16 May 2017 11:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1q04h+FllPT61iLECWHREFsBvzo8Jle8fCJz5o1UpiA=; b=RD0iGiBcAvLE6vkJk3I8htAqpUCYcL17nrXvHcy19FK7Ex+Met9zISEKcRbfCwu+jL LfBfILsv+4iQwJhONeUPKpGlcBv697TIWkKfQyhxFVjj3AWxgn/qzpEkuWiTV0i2vsxb 51CcYF6Yugm+hm5XclGivnauX9D3rkXfkV8R4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1q04h+FllPT61iLECWHREFsBvzo8Jle8fCJz5o1UpiA=; b=fm6yhnd7b7CNvJmkZOLbUKj08Ls9IUUH8PXyiSPUKed7MxI5FQ58CiuNWs1BuCQLAa iF+WrXYg03Hl8YPG0Iv+L8foAajR+waiJUjOk0J1J4tCSt0zNrfh9FTNilVE/Z7LGTkV MZ9jMAjhG6suY/IGYaik5EpVQOPsSQ2Yd7BI0Z/eUkXNfNRWuBGzoN733MsiQ3OO96uG YiSF+6pqf8//XfNAadS8r/D5IPvAgIBKz/24/WVyVvVrAK2DwENkn03Zf7HMirWz7DUw WBRfro7ofmuFMTN3BQzefZRR6RpS95zQEmxNMI+Vf7lHtisa07UhNrjaY+TFFfoOu+m+ K2WA==
X-Gm-Message-State: AODbwcD2PLxAKpEJTUr0ZxBloxBVQg5fIw4EzegY/9N/usDYttV8GXn9 qqC1uWbv0T/vWeM8ujIEqL2G52f4+lyT
X-Received: by 10.99.115.87 with SMTP id d23mr6115868pgn.155.1494958632236; Tue, 16 May 2017 11:17:12 -0700 (PDT)
MIME-Version: 1.0
References: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com> <7ccc5e9962dc4a4aa8fa3983eb6b122b@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <7ccc5e9962dc4a4aa8fa3983eb6b122b@usma1ex-dag1mb1.msg.corp.akamai.com>
From: David Benjamin 
Date: Tue, 16 May 2017 18:17:00 +0000
Message-ID: 
To: "Salz, Rich" , Sean Turner , "" 
Content-Type: multipart/alternative; boundary="f403045c76aa3ade7f054fa82edd"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 18:22:06 -0000

--f403045c76aa3ade7f054fa82edd
Content-Type: text/plain; charset="UTF-8"

I too am in favor and willing to review it.

On Tue, May 16, 2017 at 9:25 AM Salz, Rich  wrote:

> In favor, will review.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045c76aa3ade7f054fa82edd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I too am in favor and willing to review it.

On Tue, May 16, 2017 at 9:25 AM Salz, =
Rich <rsalz@akamai.com> wrote=
:
In favor, will review.



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--f403045c76aa3ade7f054fa82edd--


From nobody Tue May 16 11:35:04 2017
Return-Path: 
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 EE9B012EC07 for ; Tue, 16 May 2017 11:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 oiW-20pQzcT2 for ; Tue, 16 May 2017 11:35:01 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCBD12EC9C for ; Tue, 16 May 2017 11:30:32 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 3791220051C22; Tue, 16 May 2017 11:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3csPntfzTi/feW /VTT44zoVBY8s=; b=alIagqhH3a4AnkGY2M8vO09iULENWs20aqpTEtqRPY7ZJ6 qJqt2PEeIlIrzrkWFe3XnCl/hiiAy6rdb4wWv3N5IiVVE07JpXNrAdUtRTxEMezD vFEZLYZEx2fikHsnx93WoHEWF2xqP3YTn0x00yWuglTKAFKUApDBabQ437tpk=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id CF59320051C2E; Tue, 16 May 2017 11:30:31 -0700 (PDT)
Date: Tue, 16 May 2017 13:30:30 -0500
From: Nico Williams 
To: Richard Barnes 
Cc: Britta Hale , "" 
Message-ID: <20170516183029.GH10188@localhost>
References: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 18:35:03 -0000

On Tue, May 16, 2017 at 01:43:32PM -0400, Richard Barnes wrote:
> As has been pointed out elsewhere, other key changes are signaled with a
> handshake message (KeyUpdate), so using a handshake message seems more
> natural from a protocol point of view.

And as long as the record type goes in the clear, sending these sorts of
messages all with the same record type (handshake) seems best from a
traffic analysis p.o.v.

Nico
-- 


From nobody Tue May 16 11:37:59 2017
Return-Path: 
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 1818712EC92 for ; Tue, 16 May 2017 11:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R8MGSpRU3wzs for ; Tue, 16 May 2017 11:37:57 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5737F129B00 for ; Tue, 16 May 2017 11:33:31 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id e55so105613942uaa.2 for ; Tue, 16 May 2017 11:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IxfHYSNCbsg1GtJe8383lkMtrbrtPGkmzrquOsqrFeE=; b=DtEx98Jrp6HVoapalCdajXfjr9R3Ox0ZbizPuMSSGl8fdNjYXJMJKBo0GEGdBjguzW A4wJkaEcSuZRp5VmxpusMdqzO7vFr912ONZOVPjpJPPwIUDj7xZR0FxansXsQJN/EXWx 5/jFgXFTBkminnsYQ/AHW2iC5mogXraTiuerk/H51sSykKm0Zun9JWuPEDcYkjJznyqT 1C2jAVLua7cRiviBOdrXcn0AGIqAUj0w7AIfx0e63+xxoBhGJfeBPNkTYw4X8EADDEYr n6ztEBg2f92GedfOwn9sNI4440paJQ0TI5lE4KwJqVodcehPTR/skwGPZdUhOrlgnHDI Q79Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IxfHYSNCbsg1GtJe8383lkMtrbrtPGkmzrquOsqrFeE=; b=sk4f1iyzDuxz8nX87PfekblChoCMQ99Osb/ThHVXWY+9xfKZ5NA5snzuAs9/r19sfh YYaUQPqnydpOx5PJL6Xy1X7NhhdmKTlNIKTYluLs73JLxGIo+0/DIztiK0HwXxgeckhD 6hTxezuUgz514TIeD6g6z9cSBKiP2/GG2gANMOHEyvky+ZJ9dczSLORZjxXxjFS6h6EY AlJ5Cksj8OMHrcSZYoGgUltfuV5N0sq8gla7GmZO1B7FoI3H/uasQ2jAJO5FSb2jW8BJ y9EJqHXyRvNXVQzFMyMUDuOVef3EEVKpW1H/WOZ0JQRZx1xgEUkaT+WIZ7kNdgA31X4g kJaw==
X-Gm-Message-State: AODbwcBnZ0H17HHTPKngTdqPZMd6FSHcmDPmMNP8knZX8aKj6SbJnrAg 10D0McZsg0xvc9LTaE3hR/M/XMc8Ug==
X-Received: by 10.176.23.41 with SMTP id j41mr6893381uaf.32.1494959610371; Tue, 16 May 2017 11:33:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.48.19 with HTTP; Tue, 16 May 2017 11:33:30 -0700 (PDT)
In-Reply-To: 
References: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com> <7ccc5e9962dc4a4aa8fa3983eb6b122b@usma1ex-dag1mb1.msg.corp.akamai.com> 
From: Christopher Wood 
Date: Tue, 16 May 2017 11:33:30 -0700
Message-ID: 
To: David Benjamin 
Cc: "Salz, Rich" , Sean Turner , "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 18:37:58 -0000

I am in favor and willing to review it.

Best,
Chris

On Tue, May 16, 2017 at 11:17 AM, David Benjamin  wrote:
> I too am in favor and willing to review it.
>
>
> On Tue, May 16, 2017 at 9:25 AM Salz, Rich  wrote:
>>
>> In favor, will review.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Tue May 16 12:05:25 2017
Return-Path: 
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 AD3DD129526 for ; Tue, 16 May 2017 12:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 U0AHGgJCICwX for ; Tue, 16 May 2017 12:05:21 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319E712EC82 for ; Tue, 16 May 2017 12:00:39 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id j17so37757576ybj.0 for ; Tue, 16 May 2017 12:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EOQzo3oxnQ3ArRc45bddyWvFIID2XgcYwIRKM5+uR2k=; b=IB+ZxtjAZtLoPQ/2JB5I9+H4Ojcl6L8mDm6mRA9HzW3e4RzsRZDogGoTiGE9MTGJWa rYL0tzZz2AJoDY/FThK9Tok5nAeq/PDjvLIWsbrO4wKZIU65y5bAKLiB9ePAY1J9TqRD FgCkwQZ6EiTldrWZCe6xnxWJFGor0kERiz4QYXLcW6YHIIcP+hNOMlLg2+r7iZMbm6++ Vwte4E76pf9uCZxUP3VnL8id1bG23ieA+mwyDpd8JrYW9jz5bDGQMyO1iademAPkB5b3 rWVBAxy0srq51oTO4L/2C1WA7MhehM7ljrSoXMhAzt47EJUdsL55bXgyA5nVZIfvp1ZO JaDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EOQzo3oxnQ3ArRc45bddyWvFIID2XgcYwIRKM5+uR2k=; b=HvpPF+mWL62IyN1N2FdAmf7zKZxA6/879/kJVqhcla1sv7dM77oVCh3IBKYoC3SUq6 6cJ5nYy8LrgEiot3r5DBUgJ6qaxoNS7lH8QiamAlEanzVfa9TxPR3nQG31GwybSHjHxP a8h/d6gDy1F2wngCe4lnQS6M8sdw8HKKdq29VEuP8Oo/pQwY5Z8iwODXLENuRDWY0Cbz Z+CN6rhWfgvQfFkKmquOyzSVJ2MDRx6i3xfROKh4dRqFO6ag+jhZHUl46fpPZgMua2ef +imjkmXmhMZdVcL2EV4djmziOGnreRCJtwlat8zI/J1e0LddyhKQjL7CtErY/ZJpnISy 7Xsw==
X-Gm-Message-State: AODbwcDhM3ujeWk98i4IFekHRIeya2stx393pCWmQ49O3XccRmFtqpum MjiwuGc0VfUi1YLmUDIjMIJOrFtYfQ8o
X-Received: by 10.37.41.130 with SMTP id p124mr11367915ybp.24.1494961238385; Tue, 16 May 2017 12:00:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 11:59:57 -0700 (PDT)
In-Reply-To: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
From: Eric Rescorla 
Date: Tue, 16 May 2017 11:59:57 -0700
Message-ID: 
To: Britta Hale 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c14d834914546054fa8c9d7"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 19:05:23 -0000

--94eb2c14d834914546054fa8c9d7
Content-Type: text/plain; charset="UTF-8"

First, let me say I'm largely indifferent to this handshake versus alert
point, so if the WG wants to flip it back, I'm generally OK with that.
With that said, we recently implemented -20 and having it be
a handshake message is somewhat cleaner.


On Tue, May 16, 2017 at 8:30 AM, Britta Hale  wrote:

> On the Sunday 30/05 TLS:DIV workshop there was mention of the
> EndOfEarlyData message and its status as a handshake message or alert
> message.
>
> The main argument mentioned for making EndOfEarlyData a handshake
> message is that alert messages usually signal "abortive closure of the
> connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
> misleading (i.e. possibly implying that a session is ending instead of
> beginning).
>
> However, this intuition is incorrect. Alerts signal the end-of-use of
> keys, not the prohibition of further communication under other keys.
> Keys should be deleted and no further data should be sent on the
> connection.


This last sentence seems to reinforce the motivating intuition here,
namely that the alert signals the end of the *connection*, and so it's
odd to have EOED indicate a key change within a connection.



> For TLS 1.2 (7.2.1) it is even made explicitly clear that
> session resumption is possible after a close_notify send/receipt.
>

Indeed, but that's a session, not a connection


It seems natural then to make EndOfEarlyData an alert message,
> signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
> followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
> that key, while in parallel the remainder of the handshake and
> subsequent session key act almost as a further resumption (i.e. under a
> different key).
>

I can see how you could look at it this way, but I'm not sure that that's
the natural way to look at it. If you're not doing DH, then these are
very much derived from the same PSK and the same client-side
nonce.


Making EndOfEarlyData an alert message also allows for clear key
> boundaries: if EndOfEarlyData is a handshake message, then we are mixing
> messages protected by the the client_early_traffic_secret and
> handshake_traffic_secret in the Finished message.


Well, we also mix unencrypted traffic into the Finished, right? Does this
present a practical problem for analysis?

-Ekr

Britta
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c14d834914546054fa8c9d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


First, let me say I'm largely indifferent to this hand=
shake versus alert
point, so if the WG wants to flip it back, I'm g=
enerally OK with that.
With that said, we recently implemented -2=
0 and having it be
a handshake message is somewhat cleaner.
=



On Tue, =
May 16, 2017 at 8:30 AM, Britta Hale <britta.hale@ntnu.no>=
 wrote:
On the Sunday 30/05 TLS:DIV works=
hop there was mention of the

EndOfEarlyData message and its status as a handshake message or alert

message.



The main argument mentioned for making EndOfEarlyData a handshake

message is that alert messages usually signal "abortive closure of the=


connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could =
be

misleading (i.e. possibly implying that a session is ending instead of

beginning).



However, this intuition is incorrect. Alerts signal the end-of-use of

keys, not the prohibition of further communication under other keys.

Keys should be deleted and no further data should be sent on the

connection.

This last sentence seems to rei=
nforce the motivating intuition here,
namely that the alert signa=
ls the end of the *connection*, and so it's
odd to have EOED =
indicate a key change within a connection.

=C2=A0<=
/div>
For TLS 1.2 (7.2.1) it is even made exp=
licitly clear that

session resumption is possible after a close_notify send/receipt.

Indeed, but that's a session, not a connecti=
on



It seems natural then to make EndOfEarlyData an alert message,

signifying end of 0-RTT data. Specifically, the 0-RTT handshake is

followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and

subsequent session key act almost as a further resumption (i.e. under a

different key).

I can see how you could=
 look at it this way, but I'm not sure that that's
the na=
tural way to look at it. If you're not doing DH, then these are
very much derived from the same PSK and the same client-side
n=
once.



Making EndOfEarlyData an alert message also allows for clear key

boundaries: if EndOfEarlyData is a handshake message, then we are mixing
messages protected by the the client_early_traffic_secret and

handshake_traffic_secret in the Finished message.

Well, we also mix unencrypted traffic into the Finished, right? Does=
 this
present a practical problem for analysis?

-Ekr


Britta



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c14d834914546054fa8c9d7--


From nobody Tue May 16 12:07:54 2017
Return-Path: 
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 5AA85128D6F for ; Tue, 16 May 2017 12:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 d4juVTL3gEhu for ; Tue, 16 May 2017 12:07:50 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8880312EC58 for ; Tue, 16 May 2017 12:02:37 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id 203so57504718ywe.0 for ; Tue, 16 May 2017 12:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1qrfOURrIHof44LfSjEK76MFOA/hbqICYQPo7qyZ5Xw=; b=ull6HJdQwFYmRnj+v/uWLQKQbzGBG1aUSklrtRYdppQh14MxeJpN23OssgXqu3+f/J 7MEz61Zb9lakPp4+WPkWrfnsIPh2IUggBGYqeLDYznA4qUcaPrDa3JB9n+vZx4qkCpo8 6WKgpy8rlaMUvQAa3TBneQC0LU9KEbMcgoOBIDraQu1prYID971cdDfKkp46x0Zd+fUs Ffht3XHIq5LTzBRegQvtILwma1MPawM/eZ49jDIlpQntrxEUziUBRBanQkKK33/2UIo2 ZuFQzGvQ1d6L2qZnIJj1vlI6UkrObUNKRvUgAOFUURTE3BjJsDD3HUUQFrRp1/1uw+yp 0voQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1qrfOURrIHof44LfSjEK76MFOA/hbqICYQPo7qyZ5Xw=; b=RD4UZ4O4l4TTKNCDOc3CEUI+L9TAKPCTbaPFAxVmGoaD5H2BmEk0UReAUYKX/iCLvn bWXzN3m514rHCHCP5bGUUVs3TvEsZ7Iaf6ecR7IbKq39Geg3WtDxEkrhLHiCq/S8IxBp zViJ52PnUBoc1Pv5jM7/A2U7e0p/QkT/Qjk6blZeFQfnrXnk7ZYybSNY5ChUTW7meBH2 yVDpntJ8A+qUpcmlmBmmM52h5ptdOpimYIoMYDeWL8PakA05PXAy5bcQeJRf6XrDIQsf +TRO/SxYZAVsGb3q1c6eJMLYzyGvkv80BK9EBOObYF4neHTpDvJvWIFIfEBX/C+J5WLE RdPg==
X-Gm-Message-State: AODbwcDg7PuG+HcUD9NEtnjMDUEy9q2qumzRdWG6MJWN7ylRqEwfpqRv pROG/+arCqgrk0xy7/HJCXwkTICTOjzZ
X-Received: by 10.129.146.210 with SMTP id j201mr11402152ywg.3.1494961356802;  Tue, 16 May 2017 12:02:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 12:01:56 -0700 (PDT)
In-Reply-To: 
References:   <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>  <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com>  <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com>  <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org> 
From: Eric Rescorla 
Date: Tue, 16 May 2017 12:01:56 -0700
Message-ID: 
To: Kathleen Moriarty 
Cc: TLS WG 
Content-Type: multipart/alternative; boundary="94eb2c092a40a03c08054fa8d07f"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 19:07:52 -0000

--94eb2c092a40a03c08054fa8d07f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 16, 2017 at 9:49 AM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni
>  wrote:
> >
> >> On May 16, 2017, at 11:36 AM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
> >>
> >> OK, does that put us back to the suggested wording:
> >>
> >>    "TLS depends on certificate path validation, and a conformant
> >>     TLS implementation MUST implement certificate paths validation
> >>     in a manner that achieves the same result as [RFC5280]. This
> >>     section provides TLS-specific requirements.=E2=80=9D
> >>
> >> For any developers following, does this help enough with any
> >> interoperability questions?
> >
> > TLS does not depend on certificate path validation.  Many TLS
> > *applications* rely PKIX certificate path validation (along with
> > RFC 6125 server identity verification), but TLS itself supports
> > various alternative authentication (and non-authentication) modes.
> >
> >    * PSK or SRP without certificates
> >    * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <=
=3D
> 1.2)
> >    * TOFU public key pinning
> >    * Static leaf key or leaf cert matching
> >    * RFC7250 raw public keys
> >    * DANE-EE(3) leaf certificate/key verification, without expiration
> >      or server name checks
> >    * DANE-EE(3) ... with name checks (where UKS attack are relevant)
> >    * DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
> >      is part of the chain, and identified via DNS TLSA records.
> >    * PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
> >    * PKIX-TA(0) which is RFC5280 + DANE CA "constraint"
> >
> > Keeping in mind that many implementations of RFC5280 violate that
> specification
> > by interpreting EKUs in CA certificates to constrain the kinds of
> certificates
> > that the CA may issue.  That de-facto usage is I think much more widely
> implemented
> > than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).
>
> Sorry, I grabbed the wrong text as I was ineffective at multi-tasking.
> I think we are back to the following text and would like to confirm
> that and make sure it is agreeable to the WG and implementers:
>
>     "In general detailed certificate validation procedures are out of
>     scope for TLS. [RFC5280] provides general procedures for
>     certificate validation. This section provides TLS-specific
>     requirements."
>
>
Yeah, I think so.



> There's also a thread that was discussing some interoperability
> problems related to validation and I'd like to see the resolution for
> that as well.
>

Matt has provided a PR for that that I'll be looking at this week.

Thanks,
-Ekr


> Thanks,
> Kathleen
>
> >
> > --
> >         Viktor.
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c092a40a03c08054fa8d07f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 16, 2017 at 9:49 AM, Kathleen Moriarty &l=
t;kat=
hleen.moriarty.ietf@gmail.com> wrote:
On Tue, May 16, 2017 at =
12:37 PM, Viktor Dukhovni

<ietf-dane@dukhovni.org>=
; wrote:

>

>> On May 16, 2017, at 11:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com=
> wrote:

>>

>> OK, does that put us back to the suggested wording:

>>

>>=C2=A0 =C2=A0 "TLS depends on certificate path validation, and=
 a conformant

>>=C2=A0 =C2=A0 =C2=A0TLS implementation MUST implement certificate p=
aths validation

>>=C2=A0 =C2=A0 =C2=A0in a manner that achieves the same result as [R=
FC5280]. This

>>=C2=A0 =C2=A0 =C2=A0section provides TLS-specific requirements.=E2=
=80=9D

>>

>> For any developers following, does this help enough with any

>> interoperability questions?

>

> TLS does not depend on certificate path validation.=C2=A0 Many TLS

> *applications* rely PKIX certificate path validation (along with

> RFC 6125 server identity verification), but TLS itself supports

> various alternative authentication (and non-authentication) modes.

>

>=C2=A0 =C2=A0 * PSK or SRP without certificates

>=C2=A0 =C2=A0 * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH =
with TLS <=3D 1.2)

>=C2=A0 =C2=A0 * TOFU public key pinning

>=C2=A0 =C2=A0 * Static leaf key or leaf cert matching

>=C2=A0 =C2=A0 * RFC7250 raw public keys

>=C2=A0 =C2=A0 * DANE-EE(3) leaf certificate/key verification, without e=
xpiration

>=C2=A0 =C2=A0 =C2=A0 or server name checks

>=C2=A0 =C2=A0 * DANE-EE(3) ... with name checks (where UKS attack are r=
elevant)

>=C2=A0 =C2=A0 * DANE-TA(2) with RFC5280 chain verification, but the tru=
st-anchor

>=C2=A0 =C2=A0 =C2=A0 is part of the chain, and identified via DNS TLSA =
records.

>=C2=A0 =C2=A0 * PKIX-EE(1) which is RFC5280 + DANE leaf cert "cons=
traint"

>=C2=A0 =C2=A0 * PKIX-TA(0) which is RFC5280 + DANE CA "constraint&=
quot;

>

> Keeping in mind that many implementations of RFC5280 violate that spec=
ification

> by interpreting EKUs in CA certificates to constrain the kinds of cert=
ificates

> that the CA may issue.=C2=A0 That de-facto usage is I think much more =
widely implemented

> than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).<=
br>



Sorry, I grabbed the wrong text as I was ineffective at multi-t=
asking.

I think we are back to the following text and would like to confirm

that and make sure it is agreeable to the WG and implementers:



=C2=A0 =C2=A0 "In general detailed certificate validation procedures a=
re out of

=C2=A0 =C2=A0 scope for TLS. [RFC5280] provides general procedures for

=C2=A0 =C2=A0 certificate validation. This section provides TLS-spec=
ific

=C2=A0 =C2=A0 requirements."



Yeah, I think so.

=

=C2=A0

There's also a thread that was discussing some interoperability

problems related to validation and I'd like to see the resolution for
that as well.

Matt has provided a PR fo=
r that that I'll be looking at this week.

Than=
ks,
-Ekr




Thanks,

Kathleen



>

> --

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Viktor.

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls







--



Best regards,

Kathleen




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c092a40a03c08054fa8d07f--


From nobody Tue May 16 12:10:57 2017
Return-Path: 
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 27B3312F17A for ; Tue, 16 May 2017 12:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 L8LITR4PRnor for ; Tue, 16 May 2017 12:10:53 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD33012F257 for ; Tue, 16 May 2017 12:05:38 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id 203so57545848ywe.0 for ; Tue, 16 May 2017 12:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UsFpzhjoonl1H42Upjd5skS1kJrXwwr3fDhmmZeKtq0=; b=ESIrYgCV+8+mI/SZxFtfcB7wZdgmh+HvV3Hxnddsot6/OhDh4w25PwkXc5pjvbKDK/ F12k8EiLIw5qdckgn0iZ3nq1giapEBJRQWDyC6Szm5YdhZ64D+3Ii+vWdldgupVi1ard YUrtteGT81WceaCyZqQopW5OS6Qet7AtBHj0azYVY//rE+lRzPZEFCufD9d5mpiX5Vwj kUBWIkVrCEw6b8XUUfRIMOc7hJ3LzdRTorn3LC/V/nlRFkqhz/fLsfpg1Np/UsDJ/n0N nzmgyTaNeye+Fi+Bgm4w0rRByafO2K/git5yh1Q+bgvGb65/Filz3H+HUVa5VyQKOLSm geDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UsFpzhjoonl1H42Upjd5skS1kJrXwwr3fDhmmZeKtq0=; b=T0hfi2fJ0+d2J6oQth59nUPZSL4Np16hSNmznfwrsZhygNOsXsnj/o1budTBYBEP52 8jbtCtrQoBb6TnuNyuBFSEXpr0uh/pwGkpIDrqsI8Av2QwZfBmncBBcIKoFObPuF9+KN qT0aQh81jt74lHlFzV1ETuIwwD9fJTvIAWCaKLE8/h0hHLkECIniY7N5vcMpmgxDb4KY HxTUp+wsR6RYZVx2xeoJrLCyBl4TAgAGAaQlUigOVGRF3TLgdOUa99Yucsyw5E4AWKO2 a6fa7N4JVS6GYvndLyHeiRmlX4cKr03nU+O0G5A8qY7cLhL0AzF0y/yTJhF/dIL0eRPN mifQ==
X-Gm-Message-State: AODbwcCYiReNAyDN463CPq9xCMWNe2V/tMlo10aDCUNlgIlzhtyvEXBg fYgRQ5ui73tg4EdwhGH1RuOB9tAYxw==
X-Received: by 10.129.5.14 with SMTP id 14mr10938154ywf.85.1494961538020; Tue, 16 May 2017 12:05:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 12:04:57 -0700 (PDT)
In-Reply-To: <20170516183029.GH10188@localhost>
References: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>  <20170516183029.GH10188@localhost>
From: Eric Rescorla 
Date: Tue, 16 May 2017 12:04:57 -0700
Message-ID: 
To: Nico Williams 
Cc: Richard Barnes , "" , Britta Hale 
Content-Type: multipart/alternative; boundary="001a114174686d7bd8054fa8db7c"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 19:10:56 -0000

--001a114174686d7bd8054fa8db7c
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 11:30 AM, Nico Williams 
wrote:

> On Tue, May 16, 2017 at 01:43:32PM -0400, Richard Barnes wrote:
> > As has been pointed out elsewhere, other key changes are signaled with a
> > handshake message (KeyUpdate), so using a handshake message seems more
> > natural from a protocol point of view.
>
> And as long as the record type goes in the clear, sending these sorts of
> messages all with the same record type (handshake) seems best from a
> traffic analysis p.o.v.
>

Actually at this point in the handshake the record type is encrypted.

-Ekr


> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a114174686d7bd8054fa8db7c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 16, 2017 at 11:30 AM, Nico Williams <<=
a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector=
.com> wrote:
On Tue, May 16, 2017 at 01:43:32PM -0400, Richard Barnes wrote:

> As has been pointed out elsewhere, other key changes are signaled with=
 a

> handshake message (KeyUpdate), so using a handshake message seems more=


> natural from a protocol point of view.



And as long as the record type goes in the clear, sending these sort=
s of

messages all with the same record type (handshake) seems best from a

traffic analysis p.o.v.

Actually at thi=
s point in the handshake the record type is encrypted.

=

-Ekr




Nico

--




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114174686d7bd8054fa8db7c--


From nobody Tue May 16 12:26:22 2017
Return-Path: 
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 DB08112EBBC for ; Tue, 16 May 2017 12:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level: 
X-Spam-Status: No, score=-4.799 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 NU6Xb8DGcKmI for ; Tue, 16 May 2017 12:26:19 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C8F12EAB5 for ; Tue, 16 May 2017 12:21:33 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 6E33520051C26; Tue, 16 May 2017 12:21:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zBQrs0LgcBE9zJ TPsoGzUTriJkY=; b=xTh1sM0IALKDds+rFhmBFNzyXMk1TgqUi03JzHznanfDEc fogHgbaTv3gbd3TawA/VoTD9htZcO9ubW6t1Ji3KbEq5R4qEAZuCSf3k+flBEg3A jlWviWOg8FhMn2CN8YQgc9GJnzfVmYORlWh/8BWoCeMmcM7H/JdU8t6Vg/czg=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 084E820051C25; Tue, 16 May 2017 12:21:32 -0700 (PDT)
Date: Tue, 16 May 2017 14:21:31 -0500
From: Nico Williams 
To: Eric Rescorla 
Cc: Richard Barnes , "" , Britta Hale 
Message-ID: <20170516192130.GI10188@localhost>
References: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>  <20170516183029.GH10188@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 19:26:21 -0000

On Tue, May 16, 2017 at 12:04:57PM -0700, Eric Rescorla wrote:
> On Tue, May 16, 2017 at 11:30 AM, Nico Williams 
> wrote:
> > On Tue, May 16, 2017 at 01:43:32PM -0400, Richard Barnes wrote:
> > > As has been pointed out elsewhere, other key changes are signaled with a
> > > handshake message (KeyUpdate), so using a handshake message seems more
> > > natural from a protocol point of view.
> >
> > And as long as the record type goes in the clear, sending these sorts of
> > messages all with the same record type (handshake) seems best from a
> > traffic analysis p.o.v.
> 
> Actually at this point in the handshake the record type is encrypted.

Oh good.


From nobody Tue May 16 14:14:59 2017
Return-Path: 
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 AD4CC129B07 for ; Tue, 16 May 2017 14:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level: 
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 W-rG7DZIieAp for ; Tue, 16 May 2017 14:14:54 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129FB1294B8 for ; Tue, 16 May 2017 14:10:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id E4BEF480089; Tue, 16 May 2017 23:10:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzRL32u-H_-A; Tue, 16 May 2017 23:10:09 +0200 (CEST)
Received: from [192.168.1.168] (84-52-238.131.3p.ntebredband.no [84.52.238.131]) by samson.item.ntnu.no (Postfix) with ESMTPSA id 49876480087; Tue, 16 May 2017 23:10:09 +0200 (CEST)
To: Eric Rescorla 
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no> 
Cc: "tls@ietf.org" 
From: Britta Hale 
Message-ID: <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no>
Date: Tue, 16 May 2017 23:10:08 +0200
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: 
Content-Type: multipart/alternative; boundary="------------AD000A178C7664D319EE0289"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:14:57 -0000

This is a multi-part message in MIME format.
--------------AD000A178C7664D319EE0289
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


On 16. mai 2017 20:59, Eric Rescorla wrote:
>> However, this intuition is incorrect. Alerts signal the end-of-use of
>> keys, not the prohibition of further communication under other keys.
>> Keys should be deleted and no further data should be sent on the
>> connection.
>
> This last sentence seems to reinforce the motivating intuition here,
> namely that the alert signals the end of the *connection*, and so it's
> odd to have EOED indicate a key change within a connection.
>
Avoiding getting caught on the word "connection", EOED signals the end of key 
use like other alerts, which is the central issue. Notably, EOED does 
not signal key change, unlike a KeyUpdate message or Finished message - even 
the name indicates that it is for "end of data". Its behavior is fundamentally 
like an alert's, indicating only end-of-key use for application data. 

>> Specifically, the 0-RTT handshake is
>> followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
>> that key, while in parallel the remainder of the handshake and
>> subsequent session key act almost as a further resumption (i.e. under a
>> different key).
>>
> I can see how you could look at it this way, but I'm not sure that that's
> the natural way to look at it. If you're not doing DH, then these are
> very much derived from the same PSK and the same client-side
> nonce.
>
In that case, they are both then related to the master key of the previous 
session, which may well have ended with a close_notify, i.e. a properly 
finished key use signaled by an alert. 



--------------AD000A178C7664D319EE0289
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    


    

    
    
On 16. mai 2017 20:59,
        Eric Rescorla wrote:

    

    

      

        
However, this intuition is incorrect. Alerts signal the end-of-use of
keys, not the prohibition of further communication under other keys.
Keys should be deleted and no further data should be sent on the
connection.


      

      

This last sentence seems to reinforce the motivating intuition here,
namely that the alert signals the end of the *connection*, and so it's
odd to have EOED indicate a key change within a connection.



    

    
Avoiding getting caught on the word "connection", EOED signals the end of key 
use like other alerts, which is the central issue. Notably, EOED does 
not signal key change, unlike a KeyUpdate message or Finished message - even 
the name indicates that it is for "end of data". Its behavior is fundamentally 
like an alert's, indicating only end-of-key use for application data. 


    

      

        
Specifically, the 0-RTT handshake is
followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and
subsequent session key act almost as a further resumption (i.e. under a
different key).



      

      
I can see how you could look at it this way, but I'm not sure that that's
the natural way to look at it. If you're not doing DH, then these are
very much derived from the same PSK and the same client-side
nonce.



    

    
In that case, they are both then related to the master key of the previous 
session, which may well have ended with a close_notify, i.e. a properly 
finished key use signaled by an alert. 


    

  


--------------AD000A178C7664D319EE0289--


From nobody Tue May 16 14:29:30 2017
Return-Path: 
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 68AA012943F for ; Tue, 16 May 2017 14:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 S7a5mNPRmfrO for ; Tue, 16 May 2017 14:29:25 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FB8126BF3 for ; Tue, 16 May 2017 14:24:30 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id v15so105522939wmv.1 for ; Tue, 16 May 2017 14:24:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WsYuFscKpbWkWjgIbfBiWc8n4G7e6bPaw96Sf5fqOsQ=; b=uyO/BGB0ucCnoFY/Td6r9TU1XEX21hI6rgM59aN26FQw6Ghu/k/vEs24mg8xhFGxcG QAb3nDN3YQAarfB/IGd1KDPpo2BBupdhklENHuPBzLmi3vA4Y7dexa2kXJu1eamhx1S4 dNTyFu6eK/juF42NqRECkFbcLTENzwp6Xr2IDkj64ndIxVH8cQhrKRF35NkmOVFv+8zn idQ6IxObhl27V17l0lqSZ1OMaGE9sSVkfX1S8RlyS9j0u9g8JXOgZKuf5PjaKQHG6gaF N2k3pzsi+0bxL4g4/YX1gVr0pvJLlZ+JH4Ng076kuMbKxOHfPJhnto21hWQWQw9eLf5M JGwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WsYuFscKpbWkWjgIbfBiWc8n4G7e6bPaw96Sf5fqOsQ=; b=RD9YAilrCZFzgWkGtyTYtMxDRnw2FcgPBCF/4OLO0+D3lqQT1+VLvQckUFyxDMgS8l bc9IFJGV4ner3qCq2UvMr/LuI5yy2cQR6TJP9jSBV5mYZ08Cp+tQDt6RIfHl9dBR2UcS of7UE62pGMjXWl4+6BGHaO6jzamNupP6R+Q9v/Cz6ztq62q+aTLN17HBRHoEn4dccBXr zMHyFVTsDfiNyDAXmMPoSPJs7hY3wD+8nqe668Cpg74CzX7w/ylB7Ihm5dRe4xu5gjAv n49QoejMknLrOlFfyhZMAxvCxW0B8Gl7bO+eTWEZLgIgZ+FvkTSBl2II42xL5J7O/X0g wzyQ==
X-Gm-Message-State: AODbwcDeHwZh8H7gs38bcDetUvYPk2bEPjEE+VjdwfJG2pCrEAKi/k25 ZFtbCR7nysX4F523OTaoKJ2SqdyyhbML
X-Received: by 10.28.156.197 with SMTP id f188mr391019wme.76.1494969868873; Tue, 16 May 2017 14:24:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.179.68 with HTTP; Tue, 16 May 2017 14:24:28 -0700 (PDT)
In-Reply-To: 
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no> 
From: Richard Barnes 
Date: Tue, 16 May 2017 17:24:28 -0400
Message-ID: 
To: Eric Rescorla 
Cc: Britta Hale , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b3168fc0d31054faacb6c"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:29:28 -0000

--001a114b3168fc0d31054faacb6c
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 2:59 PM, Eric Rescorla  wrote:

> First, let me say I'm largely indifferent to this handshake versus alert
> point, so if the WG wants to flip it back, I'm generally OK with that.
> With that said, we recently implemented -20 and having it be
> a handshake message is somewhat cleaner.
>

I'm inclined to keep EOED as a handshake message.  I also found it cleaner
to handle in my implementation than the alert-based alternative, especially
using the state machines added recently.

--Richard



>
>
> On Tue, May 16, 2017 at 8:30 AM, Britta Hale  wrote:
>
>> On the Sunday 30/05 TLS:DIV workshop there was mention of the
>> EndOfEarlyData message and its status as a handshake message or alert
>> message.
>>
>> The main argument mentioned for making EndOfEarlyData a handshake
>> message is that alert messages usually signal "abortive closure of the
>> connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
>> misleading (i.e. possibly implying that a session is ending instead of
>> beginning).
>>
>> However, this intuition is incorrect. Alerts signal the end-of-use of
>> keys, not the prohibition of further communication under other keys.
>> Keys should be deleted and no further data should be sent on the
>> connection.
>
>
> This last sentence seems to reinforce the motivating intuition here,
> namely that the alert signals the end of the *connection*, and so it's
> odd to have EOED indicate a key change within a connection.
>
>
>
>> For TLS 1.2 (7.2.1) it is even made explicitly clear that
>> session resumption is possible after a close_notify send/receipt.
>>
>
> Indeed, but that's a session, not a connection
>
>
> It seems natural then to make EndOfEarlyData an alert message,
>> signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
>> followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
>> that key, while in parallel the remainder of the handshake and
>> subsequent session key act almost as a further resumption (i.e. under a
>> different key).
>>
>
> I can see how you could look at it this way, but I'm not sure that that's
> the natural way to look at it. If you're not doing DH, then these are
> very much derived from the same PSK and the same client-side
> nonce.
>
>
> Making EndOfEarlyData an alert message also allows for clear key
>> boundaries: if EndOfEarlyData is a handshake message, then we are mixing
>> messages protected by the the client_early_traffic_secret and
>> handshake_traffic_secret in the Finished message.
>
>
> Well, we also mix unencrypted traffic into the Finished, right? Does this
> present a practical problem for analysis?
>
> -Ekr
>
> Britta
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114b3168fc0d31054faacb6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 16, 2017 at 2:59 PM, Eric Rescorla <ekr@rtfm.com>=
 wrote:
First, let me sa=
y I'm largely indifferent to this handshake versus alert
point, so =
if the WG wants to flip it back, I'm generally OK with that.
=
With that said, we recently implemented -20 and having it be
a ha=
ndshake message is somewhat cleaner.

I'm inclined to keep EOED as a handshake message.=C2=A0 I also fo=
und it cleaner to handle in my implementation than the alert-based alternat=
ive, especially using the state machines added recently.

=

--Richard

=C2=A0


=

On Tue, May 16, 2017 at 8:30 AM=
, Britta Hale <britta.hale@ntnu.no> wrote:
On the Sunday 30/05 TLS:DIV workshop there was mention o=
f the

EndOfEarlyData message and its status as a handshake message or alert

message.



The main argument mentioned for making EndOfEarlyData a handshake

message is that alert messages usually signal "abortive closure of the=


connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could =
be

misleading (i.e. possibly implying that a session is ending instead of

beginning).



However, this intuition is incorrect. Alerts signal the end-of-use of

keys, not the prohibition of further communication under other keys.

Keys should be deleted and no further data should be sent on the

connection.

This last sentence seems=
 to reinforce the motivating intuition here,
namely that the aler=
t signals the end of the *connection*, and so it's
odd to hav=
e EOED indicate a key change within a connection.

=C2=A0
For TLS 1.2 (7.=
2.1) it is even made explicitly clear that

session resumption is possible after a close_notify send/receipt.

Indeed, but that's a session, not a c=
onnection



It seems natural then to make EndOfEarlyData an alert message,

signifying end of 0-RTT data. Specifically, the 0-RTT handshake is

followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and

subsequent session key act almost as a further resumption (i.e. under a

different key).

I can see how yo=
u could look at it this way, but I'm not sure that that's
the natural way to look at it. If you're not doing DH, then these are<=
/div>
very much derived from the same PSK and the same client-side
nonce.



Making EndOfEarlyData an alert message also allows for clear key

boundaries: if EndOfEarlyData is a handshake message, then we are mixing
messages protected by the the client_early_traffic_secret and

handshake_traffic_secret in the Finished message.

Well, we also mix unencrypted traffic into the Finished, righ=
t? Does this
present a practical problem for analysis?
=

-Ekr


Britta



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114b3168fc0d31054faacb6c--


From nobody Tue May 16 14:33:57 2017
Return-Path: 
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 1F22912EA58 for ; Tue, 16 May 2017 14:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 9XXniEgtn7L7 for ; Tue, 16 May 2017 14:33:54 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D37D124D6C for ; Tue, 16 May 2017 14:28:56 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id l14so59526471ywk.1 for ; Tue, 16 May 2017 14:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+bH4105EZ+kYadsxUTzOId+NnvjABJXvuzFwXQpO5Qk=; b=A6BBCfy6znLmeKYP3xDMy0tF2AZ5X10qI8orjb043G9dMiH4ct/L/etbCNXG15kDTd HmSig1VqL6OcOLiiNvL9RSQJzj8YQ0PL9AH1Gm45MIHfGteIb+m8tHzTtNnvmzxAU/jj WiEJBgz1NFWwusHmKvzjR8tVNvFmJruAuNJb4ZvKHps3eU5uVFw0u20bKdA5zGkEfGF6 Ss8mHpAKJJKgsS0tNaNpmh5qlzJbS1xJ9fmIrzfbJMqe6tZSQas//waStlzQOG6dzW7Q k40Agl5aDIVMc2qJInaG1cG89ONwO4vEjpBU/00s3ObD1XuWvKg7LCGV+xhjUrvBrYPV O/YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+bH4105EZ+kYadsxUTzOId+NnvjABJXvuzFwXQpO5Qk=; b=Ocs6G38U5xOAEwuZ4Sa+Xwr4lQEUe9ITvMUlEmuITAQyYffS2jolXgf4L2WrGxVgVR uNgQrdrM8NBLxv3b+5TvaEZOQc+3Z7adT4XpC6S3CXw3Xs1+JNHSE+etegHLAZMUnpcd RriXUzce02Xp5FLS9fqf9GAzKq37y+FybiPQ/U0DXyOIj2RqaBeM13efAAAXuVuNT+Ls YNkiiXsm8W7u0ZWlp+tKzHD9lnR9cRu16r1dPkoyw76k6/jGv6OBcZZVjYDsHJngMURm L17pTyKSCnY5FW0p03qKJLscfAthl35w4VayZ/BWKCyDmW/7MQUQ26+8xDUN37Vo8MHB wTvg==
X-Gm-Message-State: AODbwcDZuE7fudlkib/5pa+jgcU10+0mJKkBhx6sxqTmT8B9XvCQ0dhn zf/FoETuL/o/Nwj8gE4Cca9AUfAmp1s8Eos=
X-Received: by 10.13.212.1 with SMTP id w1mr59731ywd.24.1494970135841; Tue, 16 May 2017 14:28:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 14:28:15 -0700 (PDT)
In-Reply-To: <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no>
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>  <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no>
From: Eric Rescorla 
Date: Tue, 16 May 2017 14:28:15 -0700
Message-ID: 
To: Britta Hale 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114fb0f6e5a448054faadb35"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:33:56 -0000

--001a114fb0f6e5a448054faadb35
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 2:10 PM, Britta Hale  wrote:

>
> On 16. mai 2017 20:59, Eric Rescorla wrote:
>
> However, this intuition is incorrect. Alerts signal the end-of-use of
> keys, not the prohibition of further communication under other keys.
> Keys should be deleted and no further data should be sent on the
> connection.
>
> This last sentence seems to reinforce the motivating intuition here,
> namely that the alert signals the end of the *connection*, and so it's
> odd to have EOED indicate a key change within a connection.
>
>
> Avoiding getting caught on the word "connection", EOED signals the end of key
> use like other alerts, which is the central issue. Notably, EOED does
> not signal key change, unlike a KeyUpdate message or Finished message - even
> the name indicates that it is for "end of data". Its behavior is fundamentally
> like an alert's, indicating only end-of-key use for application data.
>
>
I'm not sure why you say it doesn't signal a key change: EOED signals the
transition
between data encrypted with the early traffic keys and that encrypted with
the handshake
key.


> Specifically, the 0-RTT handshake is
> followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
> that key, while in parallel the remainder of the handshake and
> subsequent session key act almost as a further resumption (i.e. under a
> different key).
>
>
> I can see how you could look at it this way, but I'm not sure that that's
> the natural way to look at it. If you're not doing DH, then these are
> very much derived from the same PSK and the same client-side
> nonce.
>
>
> In that case, they are both then related to the master key of the previous
> session, which may well have ended with a close_notify, i.e. a properly
> finished key use signaled by an alert.
>
> Yes, that's true, but I'm not sure I see the relevance of this point.

-Ekr

--001a114fb0f6e5a448054faadb35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 16, 2017 at 2:10 PM, Britta Hale <britta.hale@ntnu.no> wrote:

 =20
   =20
 =20
  

    


    

    
    
=
On 16. mai 2017 20:59,
        Eric Rescorla wrote:

    

    

      

        
However, this intuition is incorrect. Alerts signal the end-of=
-use of
keys, not the prohibition of further communication under other keys.
Keys should be deleted and no further data should be sent on the
connection.


      

      
This last sentence seems to reinforce the motivating intuition h=
ere,
namely that the alert signals the end of the *connection*, and so it's
odd to have EOED indicate a key change within a connection.



    

    
Avoiding getting caught on the word "connection",=
 EOED signals the end of key=20
use like other alerts, which is the central issue. Notably, EOED does=20
not signal key change, unlike a KeyUpdate message or Finished message - eve=
n=20
the name indicates that it is for "end of data". Its behavior is =
fundamentally=20
like an alert's, indicating only end-of-key use for application data. <=
/pre>

I'm not sure why you say it=
 doesn't signal a key change: EOED signals the transition
bet=
ween data encrypted with the early traffic keys and that encrypted with the=
 handshake
key.=C2=A0
=C2=A0

    

      

        
Specifically, the 0-RTT handshake is
followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and
subsequent session key act almost as a further resumption (i.e. under a
different key).



      

      
I can see how you could look at it this way, but I'm not sur=
e that that's
the natural way to look at it. If you're not doing DH, then these are
very much derived from the same PSK and the same client-side
nonce.



    

    
In that case, they are both then related to the master key =
of the previous=20
session, which may well have ended with a close_notify, i.e. a properly=20
finished key use signaled by an alert. 
Yes, t=
hat's true, but I'm not sure I see the relevance of this point.

-Ekr


<=
/div>

--001a114fb0f6e5a448054faadb35--


From nobody Tue May 16 14:46:29 2017
Return-Path: 
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 2919E129B4C for ; Tue, 16 May 2017 14:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level: 
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 LDtRGikK9z7c for ; Tue, 16 May 2017 14:46:18 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2DB129BFC for ; Tue, 16 May 2017 14:41:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id 2EECD480089; Tue, 16 May 2017 23:41:08 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhHliYFggc_S; Tue, 16 May 2017 23:41:07 +0200 (CEST)
Received: from [192.168.1.168] (84-52-238.131.3p.ntebredband.no [84.52.238.131]) by samson.item.ntnu.no (Postfix) with ESMTPSA id A44E5480087; Tue, 16 May 2017 23:41:07 +0200 (CEST)
To: Eric Rescorla 
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>  <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no> 
Cc: "tls@ietf.org" 
From: Britta Hale 
Message-ID: <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no>
Date: Tue, 16 May 2017 23:41:06 +0200
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: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:46:22 -0000

On 16. mai 2017 23:28, Eric Rescorla wrote:

>
>> Avoiding getting caught on the word "connection", EOED signals the end of key
>> use like other alerts, which is the central issue. Notably, EOED does
>> not signal key change, unlike a KeyUpdate message or Finished message - even
>> the name indicates that it is for "end of data". Its behavior is fundamentally
>> like an alert's, indicating only end-of-key use for application data.
> I'm not sure why you say it doesn't signal a key change: EOED signals the
> transition
> between data encrypted with the early traffic keys and that encrypted with
> the handshake
> key.

EOED signals the end of data encrypted with early traffic keys, yes, and the next 
message is the Finished message encrypted with the handshake traffic key. However, 
the Finished message is not *data*, and use of the application traffic key is signaled
by the Finished message, not EOED. The Finished message, like a KeyUpdate message, are 
handshake messages, and both signal the start of a new key use for application data. 
In comparison, EOED signals the end of key use for application data - which correlates 
to alert behavior. 


From nobody Tue May 16 15:30:08 2017
Return-Path: 
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 EEA2312EC77 for ; Tue, 16 May 2017 15:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 LUycX_BZvTvO for ; Tue, 16 May 2017 15:29:59 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130BE129AC9 for ; Tue, 16 May 2017 15:25:49 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id l74so45487195ywe.2 for ; Tue, 16 May 2017 15:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mKJXsUvy1nS/46perIC7jEPZux2qwvfAId/r5+QJgNg=; b=TOft6K/QUhzTdjxpXrY0bdj9S9KVYKFraNBMMNJK9SVu4oR+IQFZVNSZfkgjAP4dNG zAKkDRSYPyyyVE+se1MEufmgj0GFrOkEGXZvO1vadgGIhNn1QAiKFXQtJarrbv4mGH0f 1ha4xRZWTZxq3aTYwH7WD/HPmogv/h7XK/TYFZdJMZCb8/6JRO40uDZ9PcI2S+wkk4S7 LP5AR3/IvcY1/KZX9aCHed8l/To3F2iaozd1nAGGEr5rFBe08JwSBbDf0aWI0w7PZaFT BalNZN7Q6Ay1AR+oTtKf6OCJwoC7lmSpKDdomJohhO1jxV71gWl3Guabkjm7Uq3TLWj8 brYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mKJXsUvy1nS/46perIC7jEPZux2qwvfAId/r5+QJgNg=; b=stsCn90rYEzl46y0eBW9NF3oEcujhsjdJs0vPnxrm0qt/LV/uI07BLyrSc8MkVPWFE 4bFAW5kSWrRau0h5ZjF1uWnYKKLB/j4sHpNgSBMoJIpemqiaaQnx99a8fpjIPxrRJz/E u6Aa5uZrpZ48bY181xMsXAgJ6iFHsKejAeGDcsDulyXKfi+XksKvCadMyOkAS5KhrwWN svpl8s4rdspOagN7mHRFvPmws7a/EuNz8HL2IsmOAMssnOqV4p7QezbYXaRO7bkNAQ3K Fuo5GO/id7sknAkufEbUqwsZqPl5FSfcWstTDxwnZk47tUATo3slRhXu9+vmWktU+4O0 0Lcw==
X-Gm-Message-State: AODbwcAasAssbqR7aw3fG32NI2NLbpSoZm32gQhFE7guhjkwEyVr9nZd jTGrcgZBiEWDFSTy1JY5Of9d7JqNp+YC
X-Received: by 10.129.146.210 with SMTP id j201mr248328ywg.3.1494973548348; Tue, 16 May 2017 15:25:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 15:25:07 -0700 (PDT)
In-Reply-To: <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no>
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>  <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no>  <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no>
From: Eric Rescorla 
Date: Tue, 16 May 2017 15:25:07 -0700
Message-ID: 
To: Britta Hale 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c092a404c7ade054faba72e"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 22:30:03 -0000

--94eb2c092a404c7ade054faba72e
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 2:41 PM, Britta Hale  wrote:

> On 16. mai 2017 23:28, Eric Rescorla wrote:
>
> >
> >> Avoiding getting caught on the word "connection", EOED signals the end
> of key
> >> use like other alerts, which is the central issue. Notably, EOED does
> >> not signal key change, unlike a KeyUpdate message or Finished message -
> even
> >> the name indicates that it is for "end of data". Its behavior is
> fundamentally
> >> like an alert's, indicating only end-of-key use for application data.
> > I'm not sure why you say it doesn't signal a key change: EOED signals the
> > transition
> > between data encrypted with the early traffic keys and that encrypted
> with
> > the handshake
> > key.
>
> EOED signals the end of data encrypted with early traffic keys, yes, and
> the next
> message is the Finished message encrypted with the handshake traffic key.
> However,
> the Finished message is not *data*, and use of the application traffic key
> is signaled
> by the Finished message, not EOED. The Finished message, like a KeyUpdate
> message, are
> handshake messages, and both signal the start of a new key use for
> application data.
>
In comparison, EOED signals the end of key use for application data - which
> correlates
> to alert behavior.
>

This seems like a point where reasonable people can differ, especially as
ultimately
the motivation for this change was some sense of architectural consistency.

To go back to my earlier question: does this change actually present some
analytic
difficulty, or do you just find it unaesthetic?

-Ekr

--94eb2c092a404c7ade054faba72e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 16, 2017 at 2:41 PM, Britta Hale <britta.hale@ntnu.no> wrote:
On 1=
6. mai 2017 23:28, Eric Rescorla wrote:



>

>> Avoiding getting caught on the word "connection", EOED s=
ignals the end of key

>> use like other alerts, which is the central issue. Notably, EOED d=
oes

>> not signal key change, unlike a KeyUpdate message or Finished mess=
age - even

>> the name indicates that it is for "end of data". Its beh=
avior is fundamentally

>> like an alert's, indicating only end-of-key use for applicatio=
n data.

> I'm not sure why you say it doesn't signal a key change: EOED =
signals the

> transition

> between data encrypted with the early traffic keys and that encrypted =
with

> the handshake

> key.



EOED signals the end of data encrypted with early traffic keys, yes,=
 and the next

message is the Finished message encrypted with the handshake traffic key. H=
owever,

the Finished message is not *data*, and use of the application traffic key =
is signaled

by the Finished message, not EOED. The Finished message, like a KeyUpdate m=
essage, are

handshake messages, and both signal the start of a new key use for applicat=
ion data.
In comparison, EOE=
D signals the end of key use for application data - which correlates

to alert behavior.

This seems like a po=
int where reasonable people can differ, especially as ultimately
=
the motivation for this change was some sense of architectural consistency.=


To go back to my earlier question: does this chan=
ge actually present some analytic
difficulty, or do you just find=
 it unaesthetic?

-Ekr



--94eb2c092a404c7ade054faba72e--


From nobody Tue May 16 16:02:19 2017
Return-Path: 
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 46A2712EA6A for ; Tue, 16 May 2017 16:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level: 
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 IL_EKaOUG6qZ for ; Tue, 16 May 2017 16:02:15 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEB212EAAB for ; Tue, 16 May 2017 15:57:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id 39FC5480089; Wed, 17 May 2017 00:57:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjicFpKlMBHs; Wed, 17 May 2017 00:57:56 +0200 (CEST)
Received: from [192.168.1.168] (84-52-238.131.3p.ntebredband.no [84.52.238.131]) by samson.item.ntnu.no (Postfix) with ESMTPSA id 9E937480087; Wed, 17 May 2017 00:57:56 +0200 (CEST)
To: Eric Rescorla 
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>  <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no>  <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no> 
Cc: "tls@ietf.org" 
From: Britta Hale 
Message-ID: 
Date: Wed, 17 May 2017 00:57:55 +0200
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: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 23:02:18 -0000

On 17. mai 2017 00:25, Eric Rescorla wrote:

>> EOED signals the end of data encrypted with early traffic keys, yes, and
>> the next
>> message is the Finished message encrypted with the handshake traffic key.
>> However,
>> the Finished message is not *data*, and use of the application traffic key
>> is signaled
>> by the Finished message, not EOED. The Finished message, like a KeyUpdate
>> message, are
>> handshake messages, and both signal the start of a new key use for
>> application data.
>>
> In comparison, EOED signals the end of key use for application data - which
>> correlates
>> to alert behavior.
>>
> This seems like a point where reasonable people can differ, especially as
> ultimately
> the motivation for this change was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some
> analytic
> difficulty, or do you just find it unaesthetic?
>
It is a matter of consistency not aesthetics, and that has actual 
implications on analysis. 

Classifying message types is meaningful in terms of truncation attacks.
Under a application traffic secret, a receiver is only guaranteed protection 
from a truncation if it receives an alert (close_notify). According to the 
current draft, a server is only guaranteed protection from such an attack 
for 0-RTT data if it receives a handshake message. Such a difference is sloppy
in terms of analysis.

Furthermore, there is the inconsistency of placement of the EOED message in 
the Finished hash. The lack of synchronization of EOED, i.e. not being fixed 
with respect to the other handshake messages, could complicate analysis in 
terms of matching server/client transcripts.

-- Britta


From nobody Tue May 16 17:44:39 2017
Return-Path: 
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 BF35712EAC1 for ; Tue, 16 May 2017 17:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 sCjhy5V0jXPs for ; Tue, 16 May 2017 17:44:35 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE22A12949D for ; Tue, 16 May 2017 17:40:36 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id l74so46473426ywe.2 for ; Tue, 16 May 2017 17:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ElRuGOR58JLyCbb6gCKMt8jDIWR0y0p4tyN8LkvtYvs=; b=WEK1yiTI6B8GsZZciWERby62l9vu1l0wt4BpViN2ZGs1KUR+PlNjFgZQz3lzTabj5R 5m4nSJSl0zxW4jI/rCV/FzjKmd+yoFT1QjhU8GSWW91TgprCNcA7Xd2JVFDJO7jaonrZ 0Hd5At68GcqOf0KLqbYAikx9pJ3nMfuMZ1bHpqxJfPm+8FuCnLo+8Xvn2JYA2E1EAslD uMAS/snzPn51bUp++54z78pNVp+Nj8RR01TlqIV4kG+w27FwyVloigrtAL1RnjladyUe 3ceqpmz5z5UxitH2VA9Nnjtt8WSpcKg5/rdAZNsBYYuwyK2V9JAT1NjWYJ+kxN8eQz3x UoUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ElRuGOR58JLyCbb6gCKMt8jDIWR0y0p4tyN8LkvtYvs=; b=ZIqkSZ89ZKh4/MKxO72XIaCFe74jnuz5J7y3dFeHUKBm3MklrBKwMaMVCddkHPygbC zsQ4osc2dAvZMfliYzPDSgQcZlboxe7R2FlFjhPZaiztzP8I9mVUx3N6W9Kp402IaKXz 2luXi5eyHn72KxULHPal6by457eQnjO+cjIx9Y0lePFVvKSwrw1em0shZMe/gi+Wg4FT /TCK7N/Ls9TihtPfNZvIE5AhpEqlqurW0X5kzh+2iRDIc5gKclcScxE2Xk2IHoZzOk5W d9R6oJ/jms6cwDZNc62v0QP6oo2cH7VLgAUl3FApW45c/rpi+Lz3be/dPIYRgBbrAMQZ qK3A==
X-Gm-Message-State: AODbwcDfpIiZP01IJLtzF9lg9+bIga+anAL7gQAnzpknDVQagiaQJ8xK +VC8wrP4jIJRr71fABtJ+MJWxo/YmID29Ig=
X-Received: by 10.129.85.83 with SMTP id j80mr577750ywb.283.1494981636125; Tue, 16 May 2017 17:40:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 17:39:55 -0700 (PDT)
In-Reply-To: 
References:     
From: Eric Rescorla 
Date: Tue, 16 May 2017 17:39:55 -0700
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f3cbe5e0cce054fad89ef"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 00:44:38 -0000

--001a113f3cbe5e0cce054fad89ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla  wrote:

> As promised:
> https://github.com/tlswg/tls13-spec/pull/1005
>
> Note: I may have to do a little post-landing cleanup, but I wanted to get
> people's senses of the text ASAP.
>

Thanks for everyone's comments. I've updated the text to address many of
them and
made comments in Github where I decided not to do so. Can those who have
read
the previous version please take a look?

I'd also like to merge PR#998. I haven't heard any real complaints about it
and it's
an improvement in any case. I'll await the chairs on that, though.

-Ekr



Comments welcome.
> -Ekr
>
>
> On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, May 3, 2017 at 8:20 PM, Colm MacC=C3=A1rthaigh 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla  wrote:
>>>
>>>> I made some proposals yesterday
>>>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>>>>
>>>> Specifically:
>>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explainin=
g
>>>> both session-cache and strike register styles and the merits of each.
>>>>
>>>> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>>>>
>>>> 3. Adopt PR#448 (or some variant) so that session-id style
>>>> implementations
>>>> provide PFS.
>>>>
>>>> 4. I would add to this that we recommend that proxy/CDN implementation=
s
>>>> signal which data is 0-RTT and which is 1-RTT to the back-end (this wa=
s
>>>> in
>>>> Colm's original message).
>>>>
>>>
>>> This all sounds great to me. I'm not sure that we need (4.) if we have
>>> (1.).  I think with (1.) - recombobulating to a single stream might eve=
n be
>>> best overall, to reduce application complexity, and it seems to be what
>>> most implementors are actually doing.
>>>
>>> I know that leaves the DKG attack, but from a client and servers
>>> perspective that attack is basically identical to a server timeout, and
>>> it's something that systems likely have some fault tolerance around. It=
's
>>> not /new/ broken-ness.
>>>
>>
>> Heh. Always happy to do less writing.
>>
>> Thanks,
>> -Ekr
>>
>>
>>>
>>>
>>>> Based on Colm's response, I think these largely hits the points he mad=
e
>>>> in his original message.
>>>>
>>>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>>>> What would be most helpful to me as Editor would be if people could
>>>> review
>>>> these PRs and/or suggest other specific changes that we should make
>>>> to the document.
>>>>
>>>
>>> Will do! Many thanks.
>>>
>>> --
>>> Colm
>>>
>>
>>
>

--001a113f3cbe5e0cce054fad89ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla <ekr@rtfm.com> wrot=
e:
As promised:

Note: I may have to do a little post-landing cleanup, but I wanted to=
 get
people's senses of the text ASAP.

Thanks for everyone's comments. I've updated =
the text to address many of them and
made comments in Github wher=
e I decided not to do so. Can those who have read
the previous ve=
rsion please take a look?

I'd also like to mer=
ge PR#998. I haven't heard any real complaints about it and it's
an improvement in any case. I'll await the chairs on that, thou=
gh.

-Ekr


<=
br>
Comments welc=
ome.
-Ekr


On Wed, May 3, 2017 at 8:21 PM, Eric Resco=
rla <ekr@rtfm.com> wrote:


<=
span>On Wed, May 3, 2017 at 8:20 PM, Colm MacC=C3=A1rthaigh <colm@allcosts=
.net> wrote:


On W=
ed, May 3, 2017 at 8:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I made some proposals yesterday=C2=A0

Specifically:
1. A SHOULD-level requirement for server-side 0-RTT =
defense, explaining
both session-cache and strike register styles=
 and the merits of each.

2. Document 0-RTT =
greasing in draft-ietf-tls-grease

3. Adopt PR#=
448 (or some variant) so that session-id style implementations
pr=
ovide PFS.

4. I would add to this that we recommen=
d that proxy/CDN implementations
signal which data is 0-RTT and w=
hich is 1-RTT to the back-end (this was in
Colm's original me=
ssage).

This all sounds =
great to me. I'm not sure that we need (4.) if we have (1.).=C2=A0 I th=
ink with (1.) - recombobulating to a single stream might even be best overa=
ll, to reduce application complexity, and it seems to be what most implemen=
tors are actually doing. =C2=A0

I know that leaves=
 the DKG attack, but from a client and servers perspective that attack is b=
asically identical to a server timeout, and it's something that systems=
 likely have some fault tolerance around. It's not /new/ broken-ness.=
=C2=A0

Heh. =
Always happy to do less writing.

Thanks,
-Ekr
=C2=A0
=
=C2=A0
Based on Colm's resp=
onse, I think these largely hits the points he made
in his origin=
al message.

There's already a PR for #3 and I&=
#39;ll have PRs for #1 and #4 tomorrow.
What would be most he=
lpful to me as Editor would be if people could review
these PRs a=
nd/or suggest other specific changes that we should make
to the d=
ocument.

Will do! Many t=
hanks.=C2=A0

-- 
Colm













--001a113f3cbe5e0cce054fad89ef--


From nobody Tue May 16 18:54:40 2017
Return-Path: 
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 C9328126CE8 for ; Tue, 16 May 2017 18:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6e78ADi3j59l for ; Tue, 16 May 2017 18:54:38 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E6D12ECAE for ; Tue, 16 May 2017 18:50:45 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id t26so135502112qtg.0 for ; Tue, 16 May 2017 18:50:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=CtgU3kmWLe+TFNfKrSdZrGEnD3il6GjeE1qZlRHIQMY=; b=MgF+ykllx+Kky2xRcRPzT1fB905LAshNrCGcs8jskUOSC4f8UyhBxE8RSSAm8Gpahy CyFgrXMOU9PWVtWERuuZ0+Su8XNKQgxVmTqZOCM4Jk5QxQUIMn1ZM9nyjP9SLAn0p5ZY RFmMJqKGlj24jFt2xWkXAiEkRx3reT032/a9/TtXo+O/Y8tFw4MZHliqoYxoqBtc2FMC Qw+FsYNd+0drDMWsoNtK3cKR98JyOqY4SVSQDYfvPUtUyAzcfIiDft24rJdJUhP+x3j8 1IzAxGJGaK9lnMuMHcgIfOcqFS0NKK4rICXR0bz6Xi1VcHYcKg0Z7euncaCRlqdPeDOG 1dpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=CtgU3kmWLe+TFNfKrSdZrGEnD3il6GjeE1qZlRHIQMY=; b=OU8EMVW4ZZhzwZC2/l9vFgyuc66Nbi+ifd0blDK5Wth/YCLO8cI8kBB/++ap9sEpBO M94IGo9moJGBNByV9ciC9GwUA6ZN7oRjQqwQ4plhRkB9I83xuePACG4qZdvzqZ/tN616 TPRPWM4gaEUVIcpAfDGPwPxmNL1MJ+RyzV4FMkKGoR6yhWja2CC6QmxeqldZWvA3425z /UxsIDeZAqOoqQTEd/zDciDmleEL2JFRXotMPCS+ffL7rLrmZTPpP4HJVbcPCI3iq7JW wc7Zg9aymNKchSdAnDtWm8xXhQEb1a5Ppe8rfuLYisFprsjautC49Fwh1tWmB07ER3cQ JIDA==
X-Gm-Message-State: AODbwcCe1JXdnlrxE3X3ZcxauifioTAVenbgSCaOu6ZZZkyRcmmfX+9s NcC644c/MSNiyA==
X-Received: by 10.237.36.42 with SMTP id r39mr818156qtc.159.1494985844782; Tue, 16 May 2017 18:50:44 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id g129sm430708qke.9.2017.05.16.18.50.43 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 16 May 2017 18:50:44 -0700 (PDT)
From: Dave Garrett 
To: Hubert Kario 
Date: Tue, 16 May 2017 21:50:41 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
Cc: Christian Huitema , tls@ietf.org, Daniel Kahn Gillmor , Ilari Liusvaara 
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <201705151610.01070.davemgarrett@gmail.com> <2347596.YMnKhrj8b1@pintsize.usersys.redhat.com>
In-Reply-To: <2347596.YMnKhrj8b1@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201705162150.42470.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 01:54:40 -0000

On Tuesday, May 16, 2017 07:35:16 am Hubert Kario wrote:
> On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote:
> > On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote:
> > > I respectfully disagree. That system requires tight coupling between the
> > > TLS implementation and DNS. This is not something that facilitates TLS
> > > deployment. We want more TLS/HTTPS deployment, not less.
> > 
> > I completely understand why you'd disagree on these grounds. My argument is
> > that whilst this does require a significant amount of coordination, it's a
> > more productive route than just focusing on SNI encryption, which still has
> > its own share of problems. (hence us not agreeing on a way to do it yet)
> 
> Is there anything else sensitive in the Client Hello?

Yes. (lower priority info, but nonzero) I'm of the philosophy that implementations
should be open to arbitrary audit, but their messages should not give any
info away that it doesn't have to. Frankly, figuring out how it can be misused
is secondary; I assume it can.

A hypothetical scenario: Lets say I've got a client using a device, and moving
between multiple networks (e.g. joins various WiFi over time). Lets say the
attacker is passive and cannot reliably know what the IP of our client is at
all times. The user will most likely consistently use the same client software.
Various different implementations will make various different choices with
the many switches and options in TLS; fingerprinting implementations based
on their ClientHellos is not that hard. If the user has changed anything
from default that affects TLS via hellos, fingerprinting becomes much easier.
This means that an attacker can one, guess what software the target user
is using and make it easier to attack (and possibly decide to use active
attacks at some point), and two, attempt to track a user with a changing IP
across connections. Lets say our user goes through various WiFi networks
and our attacker can listen in on all of them (not necessarily a tall ask), or
we only care about a specific (set of) server(s) and can listen to their traffic.
If the attacker can link the user to one IP, and see its ClientHello, then
it can guess a window where the client switches from one IP to another,
look for ClientHellos, and then narrow down the possibilities of who the
target is in that list based on the prior fingerprint. If unique enough, or
combined with other information to narrow it down further, the client can
be identified across networks. There's of course other reasons clients can
switch between IPs; Tor users can come out of different exit nodes over time.
The point here is that not being able to fingerprint the ClientHello would
make it much harder to track targets across IP changes.

Additionally, whether or not a client is resuming a session is revealed in
the ClientHello. This information can also be used to identify clients, and is
itself potentially private information that the user may not wish to be
disclosed.

I'm sure we could come up with some other bits of information that get
leaked that could be used in some creative way in the future. I also assume
that some implementation will at some point put something incredibly stupid
in its ClientHello that needs extra protection. I'd prefer we just attempt to
always encrypt it all and call it a day. ;)

> Either way, to properly 
> encrypt SNI with forward secrecy requires the same system that would be 
> necessary to encrypt the whole Client Hello.

I get the impression that some people consider "proper" encryption of SNI
to be something less important than getting it encrypted in any way. (e.g.
a trial hashing idea was brought up) I'm not opposed to attempting to get
a minimum viable SNI encryption scheme out there, but I think those efforts
are better aimed higher. (and doing just SNI makes us less likely to consider
full hello encryption in the future)

> > The most practical short-term route would likely be to continue to hold our
> > noses and expect cleartext SNI, but maybe provide a very simple way for
> > servers to put a flag in a DNS record to opt-out entirely when they can do
> > without.
> 
> The point of encrypting SNI is so that you can hide a website on a shared 
> hosting host. If you have just one website on a host, there's nothing to 
> hide... Opting out by servers also makes the interesting targets more visible 
> (see also: email encryption).

Point taken, but you can change your IP more often than your domain. Not using
SNI at least increases the amount of effort required to figure out the destination.


Dave


From nobody Tue May 16 19:09:15 2017
Return-Path: 
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 6980212EBD2 for ; Tue, 16 May 2017 19:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 no60ZQ5uTrXi for ; Tue, 16 May 2017 19:09:12 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82C11293D9 for ; Tue, 16 May 2017 19:05:23 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id u75so145053802qka.3 for ; Tue, 16 May 2017 19:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=TkwKmcVnRlPvTcmIr7/8+01hCHPmzrQ1jtVPgECqnD4=; b=bW4/B5K1awbn+6/UzFmClTs2NVJU1Xin8E6kgSBlzhcL6TDGpCVUVnqCnU+OuIE5n1 aQRG8hpz5UH6Ij1p3EiG71+FsEHeezzjn/DHzA7EDNuKYtqG8C9I61ZN06RURpk+k4U8 mOHXbZMbNCgy17J2nL9yBlcJTJsEM4cPxRYjiSZLsx/gzAPt0/MGp9qvgieYOEYOHPNn OO0azuSgJxuutE2L3w7UT+WWQxhULEE/Lsa1YDSHP/rU05s2x5sCu8zcT7JcpJNOF/l8 OYl0ht9L0km2nl8meo3n1rLfl/qzKLsl7mf5hXx2lmbbFonWbKbx05zKJq/rkJGi7EGp 2Xvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=TkwKmcVnRlPvTcmIr7/8+01hCHPmzrQ1jtVPgECqnD4=; b=rpsimh0glFCaeD8ewsAEWw9PT0bZOa9Ix23IWT+85qdRYiPjMmOifB2QFZ8RUKJEaO Q0H0+fFbVb3kWTX/hMUA+qOhlDAMmvX/CEwAEo49kV43HBymjQ5HwLmvOdDTXl3e0wmh pSfEw+ptXkWUXnZ0/wJe3hxuaD+giUAa591N2mbU0flx4WXyQPCu1/Khw1BE/73b06WC iIDUd0vLil16kylhcIfi0G07L6fcUVRR9ye6LT4lhZoAS9iArIqF+5wC534u/M85uefx aWMXiueEeUTvoscE78/3B5aU8Sv868wKU6T3yjVA+TqF+XLVk5cIG23IwA/WWsD/9Ykw OUVw==
X-Gm-Message-State: AODbwcBcpgRebc3ZbzT4xqSc+tG3E6xdi3yB43S4w2TownI2B8w+49en HotwOG8oojYnMy3u
X-Received: by 10.55.221.8 with SMTP id n8mr808093qki.103.1494986722848; Tue, 16 May 2017 19:05:22 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id x31sm470975qtx.12.2017.05.16.19.05.21 for  (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 16 May 2017 19:05:22 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Tue, 16 May 2017 22:05:20 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:   <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org>
In-Reply-To: <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201705162205.20905.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 02:09:14 -0000

On Tuesday, May 16, 2017 12:37:42 pm Viktor Dukhovni wrote:
>    * RFC7250 raw public keys

Just as a footnote to anyone reading this discussion that may not know:
The current version of the TLS 1.3 spec explicitly recommends RFC7250
raw public keys as a viable option and provides the needed information
on how to handle this in TLS 1.3. Anonymous cipher suite support has
been dropped from TLS 1.3, and trust on first use raw public keys are
the first of the two recommended alternatives.

>    * TOFU public key pinning

Trust on first use public keys in unvalidated certificate chains is the
second recommended alternative.

https://tlswg.github.io/tls13-spec/#unauthenticated-operation
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#appendix-C.6


Dave


From nobody Tue May 16 21:32:39 2017
Return-Path: 
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 449C11294E1 for ; Tue, 16 May 2017 21:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 e4Qs30XzXvy8 for ; Tue, 16 May 2017 21:32:35 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3611296C9 for ; Tue, 16 May 2017 21:28:36 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4H4RZ2q000745; Wed, 17 May 2017 05:28:34 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : cc : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=wrr32BbKcY81SxiN66YbDDZX+0ZKHJ22I3hmCkVVoQo=; b=ouj53rEubZQq4+oNzshIA+gHuLoT+yWI260UmiRybD8IYa6235QnNtJuWt78OToCOP93 kOZGhv1L9v1daCuSfXoFVBME5FxXBHcX47UGqjT9w9WPhZo11QNu2yhwXKLvBVMwP5tt z0CRGcxnFRp3MJh2kTBrNohAoIBoWcpZGP2eNhojKEA2umC0mBR1VYwiK/nLw5mcEK+d BI7LmFPB802Hhn+Fg+R9RZiIbcZkPqH0pDKDsizKaDjNdNRsfmh2o7wIUCKXqGUGHH7b /StMdtcSFgy3N25fZnstXbViuKIP38Yue2Q+EkO7phYHoekWFD1Lw3czN9zNtTYPgbQ1 tQ== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2ag0985bsm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 May 2017 05:28:33 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4H4L24l008107; Wed, 17 May 2017 00:28:33 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2adwfv39w0-1; Wed, 17 May 2017 00:28:32 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 92FB680059; Tue, 16 May 2017 22:28:32 -0600 (MDT)
To: Britta Hale 
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>  <1f7c62a1-db73-aeae-97d0-77c769606198@ntnu.no>  <238d04ec-eb56-7879-b8c5-754c910bae30@ntnu.no>  
Cc: "tls@ietf.org" 
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Tue, 16 May 2017 23:28:32 -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: 
Content-Type: multipart/alternative; boundary="------------15DEAC457CB3B885630C480F"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705170034
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705170035
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 04:32:37 -0000

This is a multi-part message in MIME format.
--------------15DEAC457CB3B885630C480F
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 05/16/2017 05:57 PM, Britta Hale wrote:
> It is a matter of consistency not aesthetics, and that has actual 
> implications on analysis. 

I think there are some unsupported (and unstated!) assumptions about
what framework in which to analyze things going on here.

> Classifying message types is meaningful in terms of truncation attacks.
> Under a application traffic secret, a receiver is only guaranteed protection 
> from a truncation if it receives an alert (close_notify). According to the 
> current draft, a server is only guaranteed protection from such an attack 
> for 0-RTT data if it receives a handshake message. Such a difference is sloppy
> in terms of analysis.

For truncation attacks, maybe alert makes more sense.  In the area of
advancing the state machine without terminating the connection,
handshake makes more sense.  You are talking as if there is a single
right answer without stating your assumptions; you need to say more
about what you are assume and what analyses hinge on such assumptions if
you want your argument to carry much weight.

> Furthermore, there is the inconsistency of placement of the EOED message in 
> the Finished hash. The lack of synchronization of EOED, i.e. not being fixed 
> with respect to the other handshake messages, could complicate analysis in 
> terms of matching server/client transcripts.

The location in the handshake hash is well-specified in the "The
Transcript Hash" section -- it comes after server Finished.
It looks like we need to update the preceding table covering base key
generation to match, though.

-Ben

--------------15DEAC457CB3B885630C480F
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/16/2017 05:57 PM, Britta Hale wrote:

    

      
It is a matter of consistency not aesthetics, and that has actual 
implications on analysis. 


    

    

    I think there are some unsupported (and unstated!) assumptions about
    what framework in which to analyze things going on here.

    

    

      
Classifying message types is meaningful in terms of truncation attacks.
Under a application traffic secret, a receiver is only guaranteed protection 
from a truncation if it receives an alert (close_notify). According to the 
current draft, a server is only guaranteed protection from such an attack 
for 0-RTT data if it receives a handshake message. Such a difference is sloppy
in terms of analysis.


    

    

    For truncation attacks, maybe alert makes more sense.  In the area
    of advancing the state machine without terminating the connection,
    handshake makes more sense.  You are talking as if there is a single
    right answer without stating your assumptions; you need to say more
    about what you are assume and what analyses hinge on such
    assumptions if you want your argument to carry much weight.

    

    

      
Furthermore, there is the inconsistency of placement of the EOED message in 
the Finished hash. The lack of synchronization of EOED, i.e. not being fixed 
with respect to the other handshake messages, could complicate analysis in 
terms of matching server/client transcripts.


    

    

    The location in the handshake hash is well-specified in the "The
    Transcript Hash" section -- it comes after server Finished.

    It looks like we need to update the preceding table covering base
    key generation to match, though.

    

    -Ben

  


--------------15DEAC457CB3B885630C480F--


From nobody Tue May 16 21:35:31 2017
Return-Path: 
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 D39CD129C52 for ; Tue, 16 May 2017 21:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 KuI_FHfkoqkf for ; Tue, 16 May 2017 21:35:27 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342CB129A9F for ; Tue, 16 May 2017 21:31:17 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4H4S2dw028301 for ; Wed, 17 May 2017 05:31:15 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : references : to : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=ZOSvN9ukilzzohHGuI7rl70ADCQxUAYwvSkzW8nkwKw=; b=XVS1d6YQRQsE5F0I8NU1gkPwgapvOfH8FDkkInkhYy0m0iiVdl4QRmNjAelxzLPWKGmH DFTFsgGQU1oMdhAveyI2eGD+NISQn0amrR+QbaD72Sw5X7x6GCCTCFW9ciehSUPWX/sb Som+O3D0SSy5ZwCdXNIGUOrrMkLvwojWb7Wwo44LXgcYOBpq0LvsMSLRB7TnMKcPbHX7 M0aeCo54bPM6TitMrOjRH15xS3YuUmDa0AOYOICnbhFeVaVseVGwSXXuxgBiTBsQjq9h iT0REg3+MNOHTXEQyEzWwOqZvPo4I6O3w+bPxc50aVWEoGujfVa5WFkP7IuvlUfIvEzF SA== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2ag08rdyfp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 May 2017 05:31:15 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4H4UhFC013999 for ; Wed, 17 May 2017 00:31:14 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2adwfv3a29-1 for ; Wed, 17 May 2017 00:31:14 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 419F420069 for ; Tue, 16 May 2017 22:31:14 -0600 (MDT)
References: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com> <7ccc5e9962dc4a4aa8fa3983eb6b122b@usma1ex-dag1mb1.msg.corp.akamai.com>  
To: "" 
From: Benjamin Kaduk 
Message-ID: <4c0589e3-298f-dee0-ef5f-922e0619e943@akamai.com>
Date: Tue, 16 May 2017 23:31:12 -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: 
Content-Type: multipart/alternative; boundary="------------1380ED4AA165321FC201703A"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705170035
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705170035
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 04:35:29 -0000

This is a multi-part message in MIME format.
--------------1380ED4AA165321FC201703A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

*adds to the chorus*
-Ben

On 05/16/2017 01:33 PM, Christopher Wood wrote:
> I am in favor and willing to review it.
>
> Best,
> Chris
>
> On Tue, May 16, 2017 at 11:17 AM, David Benjamin  wrote:
>> I too am in favor and willing to review it.
>>
>>
>> On Tue, May 16, 2017 at 9:25 AM Salz, Rich  wrote:
>>> In favor, will review.
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------1380ED4AA165321FC201703A
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    *adds to the chorus*

      -Ben

    

    
On 05/16/2017 01:33 PM, Christopher
      Wood wrote:

    

    

      
I am in favor and willing to review it.

Best,
Chris

On Tue, May 16, 2017 at 11:17 AM, David Benjamin <davidben@chromium.org> wrote:


      

        
I too am in favor and willing to review it.


On Tue, May 16, 2017 at 9:25 AM Salz, Rich <rsalz@akamai.com> wrote:


        

          
In favor, will review.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


        

        

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------1380ED4AA165321FC201703A--


From nobody Wed May 17 09:00:24 2017
Return-Path: 
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 B0C8D12EAFA for ; Wed, 17 May 2017 09:00:22 -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] 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 2sVtNopl-DvW for ; Wed, 17 May 2017 09:00:21 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAB1129AEA for ; Wed, 17 May 2017 08:54:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1DFF1300541 for ; Wed, 17 May 2017 11:54:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n-d_BB7UUH1Q for ; Wed, 17 May 2017 11:54:18 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C4A2C300096; Wed, 17 May 2017 11:54:18 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley 
In-Reply-To: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
Date: Wed, 17 May 2017 11:54:20 -0400
Cc: IETF TLS 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <11E2F0BE-9F26-455F-9C99-E2B77245EF62@sn3rd.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-ghedini-tls-certificate-compression
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 16:00:23 -0000

I support adoption, and I am willing to review.

I note that this document defines the Certificate structure as:

       struct {
            uint24 uncompressed_length;
            opaque compressed_certificate_message<1..2^24-1>;
       } Certificate;

However, the current TLS 1.3 already defines a Certificate structure as:

      struct {
          opaque certificate_request_context<0..2^8-1>;
          CertificateEntry certificate_list<0..2^24-1>;
      } Certificate;

I think the one in this document should be renamed.

Russ



> On May 16, 2017, at 8:52 AM, Sean Turner  wrote:
>=20
> All,
>=20
> At the IETF 98 meeting in Chicago, there was support in the room to =
adopt =
https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression=
/. We are looking for feedback on adopting this draft form the list. =
Please respond if you support the draft and are willing to review it. If =
you object to its adoption, please let us know why. Please respond to =
the list by 20170530.
>=20
> Cheers,
>=20
> J&S
>=20
> Apologies - we dropped the ball on this adoption call, the call should =
have gone out with the others.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Wed May 17 21:58:51 2017
Return-Path: 
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 770F112EBC7 for ; Wed, 17 May 2017 21:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.27
X-Spam-Level: 
X-Spam-Status: No, score=0.27 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 h2eKBYOjuYXN for ; Wed, 17 May 2017 21:58:47 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B168129B67 for ; Wed, 17 May 2017 21:53:54 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id n23so17724324pfb.2 for ; Wed, 17 May 2017 21:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RYiy86fG9LbS2j0c64nIixN0QKww3sY8VJB8hMNNruQ=; b=K/8cwJzQySMEfxhyzgod1McXiOGrM3qGCrJCIlPBgUZseNB8WDuJ88iZNetPrnxCMM LuZLJ3U+Tc8UMOFqg3wavdFfYVsg3+LduaMMabvmWz16FFDawqn2+WChPJgRE3yUsp5d AtIAAfPO1ahOrw5Z2+hrxqJ80ZobFGEQu9wc7TjC4J53jKOlc/mNsV34OAk8gTWHMlU/ yuIV5b6tUW+H3lr1ChaKbGZn0kC6pe/ovH7Ssu9je4LcT/Zdv0ITMsvgtHexW/3cVpjD 7DWiAoiCTy3GmcJXRusbMh1KJxpZQxvCVYWwkfrA36GyhjfCeap1XbAmp0k6GgJbNEY2 UtKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RYiy86fG9LbS2j0c64nIixN0QKww3sY8VJB8hMNNruQ=; b=VpKAaO7RrkLvX0JviGneaRwZo8WjlLzialSojWTe+enh8bIWkotwQ085Rld+CUmMmS aT4f1fsF+PwjnPSpBPIWIWVTE6bH4phkX7q5BQEfGq7fboYcYXE812XYTXvlGxShbKNG NUPG2ROa2qmEpfapgl0YGK0ujMa65vxShiiCwFlauwFS+rOVcPHWCatSd4ISpqys/Bod bA2WDQC8CiwLslKaPm65lBylG9j9UVsZyqqJ91pfkqRFpmwBsuvh+0uNEOTPKkhbGk6W ybijoEvQS0NvAi9UrEEuHuuw9cGcm8V+SUnodR4AwefF9YklM6ypJ/uf0WUyriR4Za80 54lA==
X-Gm-Message-State: AODbwcA5g3tZ0/hzjhGhs0C8jbc6g3xw4DxmeTfPt7bxgEU48VcClWEm 0SiS9vW7oB4sa1ULztakLeQlcMIpO0GYkY4=
X-Received: by 10.84.218.7 with SMTP id q7mr2489178pli.80.1495083233642; Wed, 17 May 2017 21:53:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.177.204 with HTTP; Wed, 17 May 2017 21:53:33 -0700 (PDT)
In-Reply-To: 
References: 
From: Joseph Salowey 
Date: Wed, 17 May 2017 21:53:33 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045d17520d1ec3054fc531c7"
Archived-At: 
Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 04:58:49 -0000

--f403045d17520d1ec3054fc531c7
Content-Type: text/plain; charset="UTF-8"

It looks like we have consensus to adopt this draft as a working group
item.  Please submit the current draft as a working group item with the
filename draft-ietf-tls-exported-authenticator-00.txt.   It is OK to apply
pull request #11 before submitting this document.


Thanks,

J&S

On Thu, Apr 13, 2017 at 9:29 PM, Joseph Salowey  wrote:

> Hey Folks,
>
> At the IETF 98 meeting in Chicago there was support in the room to adopt
> draft-sullivan-tls-exported-authenticator [0]. We are looking for
> feedback on adopting this draft form the list. Please respond if you
> support the draft and are willing to review it. If you object to its
> adoption, please let us know why. Please respond to the list by 20170501
>
> Cheers,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls
> -exported-authenticator
>

--f403045d17520d1ec3054fc531c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It looks like we have cons=
ensus to adopt this draft as a working group item.=C2=A0 Please submit the =
current draft as a working group item with the filename=C2=A0draft-ietf-tls=
-exported-authenticator-00.txt. =C2=A0=C2=A0It is OK to apply pull req=
uest #11 before submitting this document. =C2=A0


Thanks,

J&S

On Thu, Apr 13, 2017 at 9:29 PM, Joseph=
 Salowey <joe@salowey.net> wrote:
Hey Folks,
At the IETF 98 meeting in Chicago there was support in th=
e room to adopt=C2=A0draft-sullivan-tls-exported-authenticator<=
/font>=C2=A0[0]. We are look=
ing for feedback on adopting this draft form the list. Please respond if yo=
u support the draft and are willing to review it. If you object to its adop=
tion, please let us know why. Please respond to the list by 20170501=


Cheers,

J&S






--f403045d17520d1ec3054fc531c7--


From nobody Wed May 17 23:16:00 2017
Return-Path: 
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 6D2A712944C for ; Wed, 17 May 2017 23:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 Cs0k-nyefmIi for ; Wed, 17 May 2017 23:15:57 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0190129B94 for ; Wed, 17 May 2017 23:10:27 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id e65so22225767ita.1 for ; Wed, 17 May 2017 23:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L6uWRYRK7/QxZB0BqEwQtcA9ci7BPTfGTecGne1R7GQ=; b=ao7T4Ru6mONys+dE1FEveodmjcO3iapP+eS77grvqslK2WRSDnXuQBMgvbc/PsvMD8 dAZCV28GINodkCNwHXvcuTO4Clt3YNO7F2Z/cXFUBM1pDtzIXi6m3+XhDZmRRdLSKfUW pIXSGfBecqIpyByPHi70cL0lguEp+wQBbh+9XsOU4Ddum9/PyWyWpEf7DHRVdX7Lj5PA qtb++VMqt1vhda7SXbQhm5dazYLdlEYDZ2NiTufw6SOlYjoj32Hn2n8RVdaSdh0+ILt0 wJ+/jpMx9jTQUIQK/RuSGsO+C7OKHNa24H8dgVCDdwvPBroB5Km1OZforgQenItAKwr+ Xd4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L6uWRYRK7/QxZB0BqEwQtcA9ci7BPTfGTecGne1R7GQ=; b=f2zPbcZkWu8RfqxfFGqGro8TPyulsuczpN9Q765TDPrjPl7U0Xpr/+B+9tc/Rw/4uP X3w0fwzt/03R0ows8TzI7zGHLMvFwugfuYmoVDziYxnxfyyEFM/QOg0NI3PMaAwQOqH8 3aS0MT+xUkstdBm5qc5mqB1gLuq1EOub94tx/pfeWoAd0g3D6gS7y0IdcFANgB7QSgCZ IpDT+/f6ywpbPzZq1NzUWb2/Dqm2i2GHx/bXB1SqL1el8kcZZcrktmDi+QoJf+FFCdwF qCVgRGwEe/z2cutn6sDvfWeBeCwBmmjYNrIy4ekYZaU5/7pmRTprGl0mrhGs4Ntr9uG8 jnng==
X-Gm-Message-State: AODbwcA4GpeCJgaOhoxEWfECU76XsEgC95Y+3b/FF5+hpsWgpp7MaaH6 jpViuAq6OQCvQ19QTfZmVc0Ql5e6AeXQ
X-Received: by 10.36.124.85 with SMTP id a82mr20207626itd.90.1495087827125; Wed, 17 May 2017 23:10:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.77.84 with HTTP; Wed, 17 May 2017 23:10:26 -0700 (PDT)
In-Reply-To: 
References: 
From: Brian Smith 
Date: Wed, 17 May 2017 20:10:26 -1000
Message-ID: 
To: Kathleen Moriarty 
Cc: "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 06:15:58 -0000

Kathleen Moriarty  wrote:
> 4. Section 6.2 Error Alerts
>
> In addition to sending the error, I don't see any mention of the error
> being logged on the server side, shouldn't that be specified?  Logging
> errors (at least in debug modes when needed) provides valuable
> troubleshooting information and many applications don't do an adequate
> job of logging, so I think it's important to call that out here as a
> recommendation.

I think I agree with what Kathleen wrote here, but the PR that
attempts to address this
(https://github.com/tlswg/tls13-spec/pull/1021) seems too strong in
recommending that servers send alerts. In particular, IMO logging the
alert shouldn't necessarily be the default and there should be a way
to disable such logging. I guess saying something such as "The
implementation SHOULD provide a way to facilitate the logging of the
error" or similar, instead of "SHOULD log" seems better to me.

In particular, an implementation might not do any logging itself, but
might return an error code that the higher level thing could log (if
it wants to). I would generally recommend implementations do this than
to do logging themselves.

Cheers,
Brian
-- 
https://briansmith.org/


From nobody Thu May 18 06:14:54 2017
Return-Path: 
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 1D8F6129473 for ; Thu, 18 May 2017 06:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 7oTSUBa3Aeom for ; Thu, 18 May 2017 06:14:51 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F17A129471 for ; Thu, 18 May 2017 06:09:10 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id p73so9975963ywp.0 for ; Thu, 18 May 2017 06:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2vpavdi7NY1//ahB7YAvaQsgQxsp+fVj67txrq6NkdM=; b=yTqJU4Uc+XMmfFKd/k1Nbz1sHhInkmcsSODaiXGFtQd1dRQ91i08WVGDC6LaLFRWJ+ uYnCYwV1OmHoEWi0RmL5mCkFyvxdB7w150g8YVdBBzQNd6x1DM/FpTtG5AKRyd95VS3V xVj05RffBW+GEI96tWSxuPl4Y7vsHm/8ZYZMHpKHPSHNzNWLkbkyEGrzjpUbB3wMBw9u MJOQbB38PPirNPTTKAkGiXhdHImQi7ptBQG9jTz+foBlUHwRuGZ2Y7RdiO9gbPlKKL2w MIYIxStZLbjIRhc0O6MsaGG1ltdzjXQsYPgOoOKkK9LS8EbVbBUq+jI6EX0R/UXAnaN5 Ck3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2vpavdi7NY1//ahB7YAvaQsgQxsp+fVj67txrq6NkdM=; b=lreSbQ7KpEIa6RFJE0n50Lj8uRfdJanZCD2MWjDNPggQf1Lz9WL8oB6vCwmLfokOk0 2gSDkmgNdc3rPFlG0CftQfhyFtwJgqamlibeRv/DKsX0f9cmiO/k1qZ/OO6Aq+nUPjay HNLXw9nHXgqWWVnehfvq5Udeyp89VDjpLJWiE0j2p4ZIcmwIAvLXHhmIwLMSSdgBkIVw J4+D+vXF/qacQlLFkzTKp1coQM4pimYwRh/RoBJ6QvfpfGYCVtiqBiMpqenS23bo2LuR jCw3i5uxYwb/N3MZfu6PqelROJ5HM0JgPzDs8i9caXFkW6MRdIglz6gy78HkAuSw1m87 PGjg==
X-Gm-Message-State: AODbwcA9tnGcBTUmMdqAxELyNjIwWjKaLgDmZ2FYFQ85djPXpAJJra6h kzyoeRija1Nl33I0Id99yTA5mNB69qqx
X-Received: by 10.129.147.134 with SMTP id k128mr3433891ywg.270.1495112949738;  Thu, 18 May 2017 06:09:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 18 May 2017 06:08:29 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Thu, 18 May 2017 09:08:29 -0400
Message-ID: 
To: Brian Smith 
Cc: Kathleen Moriarty , "" 
Content-Type: multipart/alternative; boundary="94eb2c08d35644dc2f054fcc1c7f"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 13:14:53 -0000

--94eb2c08d35644dc2f054fcc1c7f
Content-Type: text/plain; charset="UTF-8"

This works for me, does anyone object to my updating the PR in this fashion?

-Ekr


On Thu, May 18, 2017 at 2:10 AM, Brian Smith  wrote:

> Kathleen Moriarty  wrote:
> > 4. Section 6.2 Error Alerts
> >
> > In addition to sending the error, I don't see any mention of the error
> > being logged on the server side, shouldn't that be specified?  Logging
> > errors (at least in debug modes when needed) provides valuable
> > troubleshooting information and many applications don't do an adequate
> > job of logging, so I think it's important to call that out here as a
> > recommendation.
>
> I think I agree with what Kathleen wrote here, but the PR that
> attempts to address this
> (https://github.com/tlswg/tls13-spec/pull/1021) seems too strong in
> recommending that servers send alerts. In particular, IMO logging the
> alert shouldn't necessarily be the default and there should be a way
> to disable such logging. I guess saying something such as "The
> implementation SHOULD provide a way to facilitate the logging of the
> error" or similar, instead of "SHOULD log" seems better to me.
>
> In particular, an implementation might not do any logging itself, but
> might return an error code that the higher level thing could log (if
> it wants to). I would generally recommend implementations do this than
> to do logging themselves.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c08d35644dc2f054fcc1c7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This works for me, does anyone object to my updating the P=
R in this fashion?

-Ekr


On Thu, May 18, 2017 at=
 2:10 AM, Brian Smith <brian@briansmith.org> wrote:
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.<=
wbr>com> wrote:

> 4. Section 6.2 Error Alerts

>

> In addition to sending the error, I don't see any mention of the e=
rror

> being logged on the server side, shouldn't that be specified?=C2=
=A0 Logging

> errors (at least in debug modes when needed) provides valuable

> troubleshooting information and many applications don't do an adeq=
uate

> job of logging, so I think it's important to call that out here as=
 a

> recommendation.



I think I agree with what Kathleen wrote here, but the PR that

attempts to address this

(https://github.com/tlswg/tls13-spec/pull/1021=
) seems too strong in

recommending that servers send alerts. In particular, IMO logging the

alert shouldn't necessarily be the default and there should be a way
to disable such logging. I guess saying something such as "The

implementation SHOULD provide a way to facilitate the logging of the

error" or similar, instead of "SHOULD log" seems better to m=
e.



In particular, an implementation might not do any logging itself, but

might return an error code that the higher level thing could log (if

it wants to). I would generally recommend implementations do this than

to do logging themselves.



Cheers,

Brian

--

ht=
tps://briansmith.org/




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c08d35644dc2f054fcc1c7f--


From nobody Thu May 18 07:08:41 2017
Return-Path: 
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 75BEC129458 for ; Thu, 18 May 2017 07:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pciAcmMB-z5B for ; Thu, 18 May 2017 07:08:38 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16FF12956B for ; Thu, 18 May 2017 07:02:22 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id d127so53581597wmf.0 for ; Thu, 18 May 2017 07:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SCuo8Uw8VFVd6R9v6uY49vwV4/OC9AQ7bUF0rtgrreQ=; b=fz/DQ76hnKgPLX/bCizvVxNpXbBMEyM5T6sZOL0lz5t2R/T8Cjh6u3g1shlORPxWsx RgZFpWJM72rM7Sd+7uEEJ9nLesHpOQLyPv/yFFJDYhBpvd7FB7Q2fKUo9aKTJEdIGT12 fa13XhHbN5Z/VeYJpLO7CY+Z0bVL/o1fwsNx0mgp/QA0qMoib3mC8XUIADta8TViw3S5 1g7NkWV499Q/VT7Zc2PNa7uvJFC/5r15SvfB3sX4+abcXDHjSovoR0qMNz5dFULQZ97l qN3bIYzpiO1xNfe1GFyKsAvwVg5yuyljg2R8It4LB5gQS+FQtD2ycovLNrjuiN7VuWHL NUOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SCuo8Uw8VFVd6R9v6uY49vwV4/OC9AQ7bUF0rtgrreQ=; b=Tvx/wFy+Q6NhKmRta9LCNoNA/VI0HS77Ex9ACeWJwETJ1AEvWl2WWHjQjI0j3wSTz0 ha6IMhAgxRGHA3lDv4TcoV5iijvUgns/kk8eLPKLFGoK0KJkbDRhTsQyy4VVYWSaFz/O 0pxx5PMZZ9wyoWZWodIspxFvHHTTpuLVF8Wjr5OG/xPMhfqqnOyt+Wvwd8fH9nctSTIN dAC+ldtoDFEXIL65ACJoYowYSX6RmNcjcuO+7DV7gvi2wPyzewxFrKkUGi/lHTjWM+6v JEvszhN325a7YPBtdy7Gl1DP10vCjML2KBIvGsNl7Jy57CBO6uQraLhsI0U1qvR8sqbJ 8vlA==
X-Gm-Message-State: AODbwcC0ETMqJ0SvezVTa0hwqA1Fbyca2vgVWsVSNfA361HH2Q+YIVHE huUJl43aNQTCFyaDZbJaRaciAo4rL0NI
X-Received: by 10.25.215.198 with SMTP id q67mr1012705lfi.76.1495116141505; Thu, 18 May 2017 07:02:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.75.9 with HTTP; Thu, 18 May 2017 07:02:20 -0700 (PDT)
In-Reply-To: 
References:   
From: Martin Thomson 
Date: Thu, 18 May 2017 10:02:20 -0400
Message-ID: 
To: Eric Rescorla 
Cc: Brian Smith , "" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 14:08:39 -0000

On 18 May 2017 at 09:08, Eric Rescorla  wrote:
> This works for me, does anyone object to my updating the PR in this fashion?

Go ahead.


From nobody Thu May 18 10:50:15 2017
Return-Path: 
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 6AA82129B53; Thu, 18 May 2017 10:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 32qQ9BFtPnn6; Thu, 18 May 2017 10:49:59 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2AC129C51; Thu, 18 May 2017 10:44:28 -0700 (PDT)
X-AuditID: c6180641-361ff700000037f2-91-591d971b2e2a
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 3D.19.14322.B179D195; Thu, 18 May 2017 14:44:14 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Thu, 18 May 2017 13:44:24 -0400
From: Daniel Migault 
To: Dan Romascanu , "gen-art@ietf.org" 
CC: "draft-ietf-tls-ecdhe-psk-aead.all@ietf.org" , "ietf@ietf.org" , "tls@ietf.org" 
Thread-Topic: Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03
Thread-Index: AQHSzWiJWERoq289gk+axe0Pcf3PPqH6RMuw
Date: Thu, 18 May 2017 17:44:24 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB690@eusaamb107.ericsson.se>
References: <149484519593.2843.448630358757818654@ietfa.amsl.com>
In-Reply-To: <149484519593.2843.448630358757818654@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPiK7cdNlIgyu3rSzeLNvEZNH4WMvi 6qvPLBbPNs5nsfh0vovRgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4cPwKW8EC5YqP 18+wNzCuUepi5OCQEDCRePXSsYuRi0NI4CijxOk9HawQznJGiZ7jD9i6GDk52ASMJNoO9bOD 2CICvhLXT09iByliFljIKNG+aAIzSEJYwENi9/M2qCJPiVMtx5ggbCOJR2+/gtksAqoSK/7/ YgSxeYEGLbu/GiwuJOAoce3MMlYQm1PASWLb/NdgixkFxCS+n1oDVsMsIC5x68l8MFtCQEBi yZ7zzBC2qMTLx/9YIWwliUlLz7GCfMYsoCmxfpc+RKuixJTuh+wQawUlTs58wjKBUXQWkqmz EDpmIemYhaRjASPLKkaO0uKCnNx0I8NNjMA4OSbB5riDcW+v5yFGAQ5GJR7e7i7ZSCHWxLLi ytxDjBIczEoivF/OAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzviu/ECEkkJ5YkpqdmlqQWgST ZeLglGpglGQpfavM+f9vZGwto0Rz0dTKAtkZFnOnLej061senP3GzIJ3o5POw2VzNm5hTZu2 XmTFhBdqG9fmbn99padTsjD2w5SVd846buI+zMO1NK0sci6zQZMEy9MC21Ua5zWXH+rPZOfg PKd2Nzte3Omf2k7V6aznfyhleR7telc2ie03R8Shf/P3K7EUZyQaajEXFScCAAaWn0GPAgAA
Archived-At: 
Subject: Re: [TLS] Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 17:50:01 -0000

SGkgRGFuLCANCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlld3MgYW5kIGNvbW1lbnRzLiBJIGJl
bGlldmUgdGhlIGZvbGxvd2luZyB0ZXh0IHByb3ZpZGVzIG1vcmUgZXhwbGFuYXRpb24gb24gaG93
IHRoZSBwcm92aWRlZCBjaXBoZXIgc3VpdGVzIGFyZSBuZWdvdGlhdGVkIGJ5IFRMUzEuMyBhcyB3
ZWxsIGFzIHdoeSBwb2ludCBjb2RlcyBkZWZpbmVkIGluIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBh
cHBseSB0byBUTFMxLjMuIEZlZWwgZnJlZSB0byBsZXQgbWUga25vdyBpZiB0aGF0IGFkZHJlc3Mg
eW91ciBjb25jZXJuIGFuZCBJIGNhbiBwdWJsaXNoIHZlcnNpb24gMDQgd2l0aCB0aGUgdGV4dCBi
ZWxvdy4NCg0KVW5saWtlIFRMUzEuMiwgVExTMS4zIHNlcGFyYXRlcyBhdXRoZW50aWNhdGlvbiBh
bmQgY2lwaGVyIHN1aXRlIG5lZ290aWF0aW9uIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtdGxzLXRs
czEzIi8+IFNlY3Rpb24gMS4yLiBUTFMxLjMgc3VwcG9ydHMgUFNLIHdpdGggRUNESEUga2V5IGV4
Y2hhbmdlIGFuZCB0aGUgY2lwaGVyIHN1aXRlcyBUTFNfQUVTXzEyOF9HQ01fU0hBMjU2LCBUTFNf
QUVTXzI1Nl9HQ01fU0hBMzg0LCBUTFNfQUVTXzEyOF9DQ01fOF9TSEEyNTYgYW5kICBUTFNfQUVT
XzEyOF9DQ01fU0hBMjU2IGFyZSBwYXJ0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLiBBcyBhIHJlc3Vs
dCwgVExTIDEuMyBhbmQgaGlnaGVyIHZlcnNpb25zLCBuZWdvdGlhdGUgYW5kIHN1cHBvcnQgdGhl
c2UgY2lwaGVyIHN1aXRlcyBpbiBhIGRpZmZlcmVudCB3YXkuDQoNCkkgYW0gbm90IHN1cmUgd2Ug
IGhhdmUgdG8gd2FpdCBmb3IgdGhlIHB1YmxpY2F0aW9uIG9mIFRMUzEuMyBhcyBjaGFuZ2VzIG9u
IFRMUzEuMyBhcmUgdW5saWtlbHkgdG8gaW1wYWN0IHRoZSBjb2RlIHBvaW50IGFzc2lnbmVkLiBI
b3dldmVyLCB3ZSBjdXJyZW50bHkgaGF2ZSBUTFMxLjMgYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNl
LiANCg0KWW91cnMsIA0KRGFuaWVsDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
RGFuIFJvbWFzY2FudSBbbWFpbHRvOmRyb21hc2NhQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXks
IE1heSAxNSwgMjAxNyA2OjQ3IEFNDQpUbzogZ2VuLWFydEBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWll
dGYtdGxzLWVjZGhlLXBzay1hZWFkLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgdGxzQGll
dGYub3JnOyBkcm9tYXNjYUBnbWFpbC5jb20NClN1YmplY3Q6IEdlbmFydCBsYXN0IGNhbGwgcmV2
aWV3IG9mIGRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLTAzDQoNClJldmlld2VyOiBEYW4g
Um9tYXNjYW51DQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KDQpJIGFtIHRoZSBh
c3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVh
IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBw
cm9jZXNzZWQgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiAgUGxlYXNlIHRyZWF0IHRo
ZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpG
b3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQoNCjxodHRwczovL3Ry
YWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lg0KDQpEb2N1bWVudDogZHJhZnQt
aWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQtPz8NClJldmlld2VyOiBEYW4gUm9tYXNjYW51DQpSZXZp
ZXcgRGF0ZTogMjAxNy0wNS0xNQ0KSUVURiBMQyBFbmQgRGF0ZTogMjAxNy0wNS0xOA0KSUVTRyBU
ZWxlY2hhdCBkYXRlOiAyMDE3LTA1LTI1DQoNClN1bW1hcnk6DQoNClRoaXMgaXMgYSBzdHJhaWdo
dC1mb3J3YXJkIGFuZCBjbGVhciBkb2N1bWVudCB0aGF0IGRlZmluZXMgc2V2ZXJhbCBuZXcgY2lw
aGVyIHN1aXRlcyBmb3IgdGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBwcm90b2Nv
bCB2ZXJzaW9uDQoxLjIgYW5kIGhpZ2hlciwgYmFzZWQgb24gdGhlIEVwaGVtZXJhbCBFbGxpcHRp
YyBDdXJ2ZSBEaWZmaWUtSGVsbG1hbiB3aXRoIFByZS1TaGFyZWQgS2V5IChFQ0RIRV9QU0spIGtl
eSBleGNoYW5nZSB0b2dldGhlciB3aXRoIHRoZSBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0
aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpIGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVTLUNDTS4g
VGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQgSSBhcHByZWNpYXRlIHRoZSBlZmZvcnQg
dG8gY2xhcmlmeSBpbiB0aGUgSW50cm9kdWN0aW9uIHRoZSBjb250ZXh0LCB3aGF0IHdhcyBtaXNz
aW5nLCBhbmQgd2h5IHRoZSBkb2N1bWVudCBpcyBuZWNlc3NhcnkuIFRoZSBkb2N1bWVudCBpcyBS
ZWFkeSwgdGhlcmUgaXMgb25lIGlzc3VlIGFib3V0IHN1cHBvcnQgZm9yIFRMUyB2ZXJzaW9uIDEu
MyBhbmQgaGlnaGVyIHRoYXQgbWF5IG5lZWQgc29tZSB0ZXh0IGNsYXJpZmljYXRpb24uIA0KDQpN
YWpvciBpc3N1ZXM6DQoNCk1pbm9yIGlzc3VlczoNCg0KU2VjdGlvbiA0ICgnQXBwbGljYWJsZSBU
TFMgVmVyc2lvbnMnKSBkZXNjcmliZXMgaW4gZGV0YWlscyBob3cgdGhlIGNpcGhlciBzdWl0ZXMg
ZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnQgbWFrZSB1c2Ugb2YgdGhlIGF1dGhlbnRpY2F0ZWQgZW5j
cnlwdGlvbiB3aXRoIGFkZGl0aW9uYWwgZGF0YSAoQUVBRCkgZGVmaW5lZCBpbiBUTFMgMS4yIFtS
RkM1MjQ2XSBhbmQgRFRMUyAxLjIgW1JGQzYzNDddLiBBYm91dCBUTFMgMS4zIGl0IGp1c3Qgc2F5
czogDQoNCicgVExTIDEuMyBhbmQgYWJvdmUgdmVyc2lvbiwgbmVnb3RpYXRlIGFuZCBzdXBwb3J0
IHRoZXNlIGNpcGhlciBzdWl0ZXMgaW4gYSBkaWZmZXJlbnQgd2F5LicNCg0KVGhpcyBtYXkgcmFp
c2Ugc29tZSBjb25jZXJucyBhcyAnaW4gYSBkaWZmZXJlbnQgd2F5JyBpcyBhbWJpZ3VvdXMsIGVz
cGVjaWFsbHkgY29tcGFyZWQgdG8gdGhlIGRldGFpbHMgaW5jbHVkZWQgZm9yIFRMUyAxLjIuIE1v
cmVvdmVyLCBUTFMNCjEuMyBpcyBzdGlsbCB3b3JrLWluLXByb2dyZXNzLCBhbmQgSSBiZWxpZXZl
IHRoYXQgdGhpcyBkb2N1bWVudCB3aGVuIGFwcHJvdmVkIG5lZWRzIHRvIHdhaXQgZm9yIFRMUyAx
LjMgdG8gYmUgYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uLg0KV2lsbCBhbnl0aGluZyBjaGFuZ2Us
IG9yIG5lZWQgdG8gYmUgYWRkZWQ/IFNvbWUgYmV0dGVyIGNsYXJpZmljYXRpb24gdGV4dCB3b3Vs
ZCBoZWxwIElNTy4gDQoNCk5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOiANCg0KDQo=


From nobody Thu May 18 10:52:04 2017
Return-Path: 
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 7737F12EBD1; Thu, 18 May 2017 10:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Juj8Cf_H5uGh; Thu, 18 May 2017 10:51:46 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7189F1292F4; Thu, 18 May 2017 10:45:42 -0700 (PDT)
X-AuditID: c6180641-379ff700000037f2-c5-591d976674fc
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id A8.29.14322.6679D195; Thu, 18 May 2017 14:45:28 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Thu, 18 May 2017 13:45:38 -0400
From: Daniel Migault 
To: Simon Friedberger , "ietf@ietf.org" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
Thread-Index: AQHSxPVA+HUpnSSi3UucXiEEFjZ+saHk/FmAgBVW5mA=
Date: Thu, 18 May 2017 17:45:38 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se>
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org>
In-Reply-To: <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPgm7GdNlIg6f/VC2ebZzPYnFt8nIW i0/nuxgdmD2mrZvL6LFkyU+mAKYoLpuU1JzMstQifbsEroxTG/tYCk6KVpz9foq9gfGsYBcj B4eEgInErkaHLkYuDiGBo4wS35tmsUA4yxklZv/5zNbFyMnBJmAk0Xaonx3EFhHwlTj6dj2Y zSygKPH+0jywBmGBzYwSL5/dZwRxRAS2MEocOnKPEaLDSuLsuodgHSwCqhKXb3ezgti8QJNW NExmhljXwCjRNfMVO8hNnAJ2Es0HA0FqGAXEJL6fWsMEsU1c4taT+WC2hICAxJI955khbFGJ l4//sULYShKTlp5jhajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRl ASPLKkaO0uKCnNx0I8NNjMDYOCbB5riDcW+v5yFGAQ5GJR7e7i7ZSCHWxLLiytxDjBIczEoi vF/OAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzviu/ECEkkJ5YkpqdmlqQWgSTZeLglGpgnCHf sHirhd3OfXzLin7YrG8Kttv96/a+2pDntQ0h3EebphYbT01i3vSu8UH1bbFnBzRUq9J2Jgj5 FzFuPtKYP7llrfMXl9Bu7Y7S7gP8156GMh81v7/30iS1I4G1KWeXXdl12Gj/ndSyw94nVgd9 Wb5+zc+ioq9bJyX85mKZ5nil0fZxzbpSFyWW4oxEQy3mouJEAJvw01mJAgAA
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 17:51:49 -0000

Hi Simon,=20

Thank you for the review. I believe we have addressed your comments in our =
version 04. Please see my comments inline.=20

Yours,=20
Daniel

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Simon Friedberger
Sent: Thursday, May 04, 2017 5:59 PM
To: ietf@ietf.org
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call:  (ECDHE=
_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (T=
LS)) to Proposed Standard

Nits:

	RFC 4279 reference is missing.
MGLT: It seems the reference is mentioned in the current version in the Nor=
mative reference as well  as in the introduction at line 127,  in section 3=
 line 143. In case you meant another reference, please let us know.=20



	"TLS 1.3 and above version, " should probably be "TLS 1.3 and above" or "T=
LS 1.3 and higher versions"
MGLT: Changed to "TLS 1.3 and higher versions"

On 04/05/17 18:41, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>    Security (TLS)'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits=20
> final comments on this action. Please send substantive comments to the=20
> ietf@ietf.org mailing lists by 2017-05-18. Exceptionally, comments may=20
> be sent to iesg@ietf.org instead. In either case, please retain the=20
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines several new cipher suites for the Transport
>    Layer Security (TLS) protocol.  The cipher suites are all based on
>    the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>    (ECDHE_PSK) key exchange together with the Authenticated Encryption
>    with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>    provides light and efficient authentication, ECDHE provides perfect
>    forward secrecy, and AES-GCM and AES-CCM provides encryption and
>    integrity protection.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Thu May 18 13:54:21 2017
Return-Path: 
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 7D876129B55; Thu, 18 May 2017 13:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AuFAi7Ey_ya0; Thu, 18 May 2017 13:54:05 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBB2129BDA; Thu, 18 May 2017 13:48:08 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id c13so44357435qtc.1; Thu, 18 May 2017 13:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iMx3OZGOhgrQiAN7fV+Jcg3bGsPXOS4n792xRPXdOsU=; b=XpoYHqBcc/PN0YYBdSf2VDx0a7/t1YgIJjeMbzdmlZQhgSHLxBGTJFO00MqVgHISGd JM4DGPPuIbbxhl4dtZQf1BP9aNrHFh8sUOb/237opM8skoXjuEwKIE+A1pCrzt3R3V0D etCsTwNwF1XMMhB7sKLZXvzptQ9Yfh1Ad0Dd6yAA+4qaA6QP460dqQfo3rs693keYd2Z kLYdcfPPmybwWoDwCNltag81+P1xQKvGes5B5BuRYT3IbTKI3mIFgfxDiJ+GUnoD2Gia hud7zUOE8YzKOBlyb0lrGSBzfR/t6j567u2uOF/c/YwX0pHE1XqyOGPn0tDnjBIkC/Si Tfkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iMx3OZGOhgrQiAN7fV+Jcg3bGsPXOS4n792xRPXdOsU=; b=p1/AwDtDyfM961KHUs52xmljZ4/KdvNdHb2d0gXAqhGOqwtk6WGATB1683bvMUU4o2 HUCLHWzvyTMpOxd6VA+XZGBym6MurGC9v4ujqY8cHgoTNJs6z72O3dAyDuzqt7CFBc3N cx5yr0DxxbVc9eZUV8o5+KEZ9t7ij9gacMwwwVnAUUaEuQG6d7fWWS/y13f3b/J1lfta IkmJ9aiv9P7d9iO8bOS4I0yc5hiLqRYAl+4g6BN9BSQGIH27OhOcQNVO6WnsdxkEqlSk 10lRTpO7SgDIYA+fq+8j5gBOipsUnq5L1Ar0IP/d0QJ00OQSDr+uUTcNPGiI/E/lV8w+ k7wQ==
X-Gm-Message-State: AODbwcC5lC7eZJzKtNJNUaLxRhJVzecTHTGGpccYTdsrUGOyNiQHgG+2 yyQp4qJ/u3EhQjNGIMHqbGlWar5U6Q==
X-Received: by 10.237.36.3 with SMTP id r3mr6285091qtc.200.1495140487931; Thu, 18 May 2017 13:48:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.31.101 with HTTP; Thu, 18 May 2017 13:48:07 -0700 (PDT)
In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB690@eusaamb107.ericsson.se>
References: <149484519593.2843.448630358757818654@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB690@eusaamb107.ericsson.se>
From: Dan Romascanu 
Date: Thu, 18 May 2017 23:48:07 +0300
Message-ID: 
To: Daniel Migault 
Cc: "gen-art@ietf.org" ,  "draft-ietf-tls-ecdhe-psk-aead.all@ietf.org" ,  "ietf@ietf.org" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114385c8ac2ac6054fd285ed"
Archived-At: 
Subject: Re: [TLS] Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 20:54:08 -0000

--001a114385c8ac2ac6054fd285ed
Content-Type: text/plain; charset="UTF-8"

Hi Daniel,

Thank you for your response, and for addressing my comment. Yes, the edits
address my concern, this is exactly the kind of clarification text that IMO
was missing. I suggest to publish the revised version as soon as you
address all other comments. The document can be approved by the IESG if
they believe it's ready and will wait in the RFC Editor Queue because of
the dependency on TLS 1.3.

Regards,

Dan


On Thu, May 18, 2017 at 8:44 PM, Daniel Migault  wrote:

> Hi Dan,
>
> Thank you for your reviews and comments. I believe the following text
> provides more explanation on how the provided cipher suites are negotiated
> by TLS1.3 as well as why point codes defined in the document does not apply
> to TLS1.3. Feel free to let me know if that address your concern and I can
> publish version 04 with the text below.
>
> Unlike TLS1.2, TLS1.3 separates authentication and cipher suite
> negotiation  Section 1.2. TLS1.3
> supports PSK with ECDHE key exchange and the cipher suites
> TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
> and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result, TLS
> 1.3 and higher versions, negotiate and support these cipher suites in a
> different way.
>
> I am not sure we  have to wait for the publication of TLS1.3 as changes on
> TLS1.3 are unlikely to impact the code point assigned. However, we
> currently have TLS1.3 as a normative reference.
>
> Yours,
> Daniel
> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@gmail.com]
> Sent: Monday, May 15, 2017 6:47 AM
> To: gen-art@ietf.org
> Cc: draft-ietf-tls-ecdhe-psk-aead.all@ietf.org; ietf@ietf.org;
> tls@ietf.org; dromasca@gmail.com
> Subject: Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03
>
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-tls-ecdhe-psk-aead-??
> Reviewer: Dan Romascanu
> Review Date: 2017-05-15
> IETF LC End Date: 2017-05-18
> IESG Telechat date: 2017-05-25
>
> Summary:
>
> This is a straight-forward and clear document that defines several new
> cipher suites for the Transport Layer Security (TLS) protocol version
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman with
> Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated
> Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. The
> document is well written and I appreciate the effort to clarify in the
> Introduction the context, what was missing, and why the document is
> necessary. The document is Ready, there is one issue about support for TLS
> version 1.3 and higher that may need some text clarification.
>
> Major issues:
>
> Minor issues:
>
> Section 4 ('Applicable TLS Versions') describes in details how the cipher
> suites defined in the document make use of the authenticated encryption
> with additional data (AEAD) defined in TLS 1.2 [RFC5246] and DTLS 1.2
> [RFC6347]. About TLS 1.3 it just says:
>
> ' TLS 1.3 and above version, negotiate and support these cipher suites in
> a different way.'
>
> This may raise some concerns as 'in a different way' is ambiguous,
> especially compared to the details included for TLS 1.2. Moreover, TLS
> 1.3 is still work-in-progress, and I believe that this document when
> approved needs to wait for TLS 1.3 to be approved for publication.
> Will anything change, or need to be added? Some better clarification text
> would help IMO.
>
> Nits/editorial comments:
>
>
>

--001a114385c8ac2ac6054fd285ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Daniel, 

Thank you for your=
 response, and for addressing my comment. Yes, the edits address my concern=
, this is exactly the kind of clarification text that IMO was missing. I su=
ggest to publish the revised version as soon as you address all other comme=
nts. The document can be approved by the IESG if they believe it's read=
y and will wait in the RFC Editor Queue because of the dependency on TLS 1.=
3. 

Regards,

Dan


On Thu, May 18, 2017 at 8:44 PM, Dan=
iel Migault <daniel.migault@ericsson.com> wrote:
Hi Dan,



Thank you for your reviews and comments. I believe the following text provi=
des more explanation on how the provided cipher suites are negotiated by TL=
S1.3 as well as why point codes defined in the document does not apply to T=
LS1.3. Feel free to let me know if that address your concern and I can publ=
ish version 04 with the text below.



Unlike TLS1.2, TLS1.3 separates authentication and cipher suite negotiation=
 <xref target=3D"I-D.ietf-tls-tls13"/> Section 1.2. TLS1.3 =
supports PSK with ECDHE key exchange and the cipher suites TLS_AES_128_GCM_=
SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and=C2=A0 TLS_AES_=
128_CCM_SHA256 are part of the specification. As a result, TLS 1.3 and high=
er versions, negotiate and support these cipher suites in a different way.<=
br>


I am not sure we=C2=A0 have to wait for the publication of TLS1.3 as change=
s on TLS1.3 are unlikely to impact the code point assigned. However, we cur=
rently have TLS1.3 as a normative reference.



Yours,

Daniel

-----Original Message-----

From: Dan Romascanu [mailto:dromasca@=
gmail.com]

Sent: Monday, May 15, 2017 6:47 AM

To: gen-art@ietf.org

Cc: draft-iet=
f-tls-ecdhe-psk-aead.all@ietf.org; ietf@ietf.org; tls@ietf.org; dromasca@gmail.com

Subject: Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03


Reviewer: Dan Romascanu

Review result: Ready with Issues



I am the assigned Gen-ART reviewer for this draft. The General Area Review =
Team (Gen-ART) reviews all IETF documents being processed by the IESG for t=
he IETF Chair.=C2=A0 Please treat these comments just like any other last c=
all comments.



For more information, please see the FAQ at



<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<=
/a>>.



Document: draft-ietf-tls-ecdhe-psk-aead-??

Reviewer: Dan Romascanu

Review Date: 2017-05-15

IETF LC End Date: 2017-05-18

IESG Telechat date: 2017-05-25



Summary:



This is a straight-forward and clear document that defines several new ciph=
er suites for the Transport Layer Security (TLS) protocol version

1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman with P=
re-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encr=
yption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. The docu=
ment is well written and I appreciate the effort to clarify in the Introduc=
tion the context, what was missing, and why the document is necessary. The =
document is Ready, there is one issue about support for TLS version 1.3 and=
 higher that may need some text clarification.



Major issues:



Minor issues:



Section 4 ('Applicable TLS Versions') describes in details how the =
cipher suites defined in the document make use of the authenticated encrypt=
ion with additional data (AEAD) defined in TLS 1.2 [RFC5246] and DTLS 1.2 [=
RFC6347]. About TLS 1.3 it just says:



' TLS 1.3 and above version, negotiate and support these cipher suites =
in a different way.'



This may raise some concerns as 'in a different way' is ambiguous, =
especially compared to the details included for TLS 1.2. Moreover, TLS

1.3 is still work-in-progress, and I believe that this document when approv=
ed needs to wait for TLS 1.3 to be approved for publication.

Will anything change, or need to be added? Some better clarification text w=
ould help IMO.



Nits/editorial comments:









--001a114385c8ac2ac6054fd285ed--


From nobody Thu May 18 13:58:34 2017
Return-Path: 
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 6D16B129B9B; Thu, 18 May 2017 13:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.69
X-Spam-Level: 
X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.onmicrosoft.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 bBVw_hFjiOHw; Thu, 18 May 2017 13:58:29 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0073.outbound.protection.outlook.com [104.47.33.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF5B129BCA; Thu, 18 May 2017 13:52:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8oxQAJSu9obK7Y+tPicIqxRgNSfStrFTPR6+VKWvTuc=; b=X8y17f65MsD05GotmcsFrJm+7KaBtTeTgbRbfP5idHNP79ip/jOKOc8wWTL6wZ91Z0BtdPCtmrf++BEBBxERF/o9weCumPhldwjccs5bCHcWHsMwUNcGpm4FB5ZBCUSmQ1SIFsJwO07FCrwO3cI0neLeRYBAqknINOLsXBMCWuM=
Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Thu, 18 May 2017 20:52:05 +0000
Received: from CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) by CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) with mapi id 15.01.1084.030; Thu, 18 May 2017 20:52:05 +0000
From: Timothy Jackson 
To: Daniel Migault , Simon Friedberger , "ietf@ietf.org" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
Thread-Index: AQHSxPbUkILbHt+MPUCNqbVojoqxB6HkuUiAgBW56AD//769gA==
Date: Thu, 18 May 2017 20:52:04 +0000
Message-ID: <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com>
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se>
In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=mobileiron.com;
x-originating-ip: [198.61.62.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR10MB1734; 7:c2SO4mwpDoTHdnVCqPTFWXKgfdCzBLpNMYEjXd7glqpvBSSYUNwbWVROnQOQPJfOiSJ4RgY88ph5CqyGNB2LCPF8rHcOYDQUQ6U07ftZvG8LpSFYWdpUuXpm69iWD8ErvWRx1k8VqfF7/lhYkdubZBqj26pd2CW74dRgRIqRzsQN4VvCHdelxZ6k/Mrd16sbT60th3q0ZLV9fspAX/lli2I9JU/bDivyi0ab59Pm40XDlJvgGo1UrMxuqaaep9YhlNVQzSfSHOMW8FfOa/YgMI/oQ5Kn5u61n6eE3Q/K7/LcBcd0mEjR2J5IJd2bzGj5pLQ1O2MVbxNPdZAVYl2rDg==
x-ms-office365-filtering-correlation-id: 9f855d22-830f-467c-3b89-08d49e2fbdc4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR10MB1734; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(192374486261705); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY4PR10MB1734; BCL:0; PCL:0; RULEID:; SRVR:CY4PR10MB1734; 
x-forefront-prvs: 0311124FA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39840400002)(39450400003)(377454003)(13464003)(24454002)(6246003)(122556002)(8936002)(229853002)(54356999)(25786009)(76176999)(53546009)(50986999)(99286003)(38730400002)(53936002)(2501003)(6512007)(8676002)(5660300001)(81166006)(3280700002)(345774005)(6306002)(305945005)(230783001)(33656002)(2906002)(15650500001)(7736002)(3660700001)(6486002)(6506006)(6436002)(2950100002)(4326008)(36756003)(77096006)(6116002)(3846002)(102836003)(66066001)(966005)(478600001)(86362001)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1734; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <40E8A7DF23105A4DA7A1C7603B0FC366@namprd10.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mobileiron.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 20:52:04.7625 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1734
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 20:58:32 -0000

T25lIHNtYWxsIG5pdC4NCg0KPiBFQ0RIRSBwcm92aWRlcyBwZXJmZWN0IGZvcndhcmQgc2VjcmVj
eQ0KSSB0aG91Z2h0IHdlIGhhZCBkZWNpZGVkIHRvIGNoYW5nZSDigJxwZXJmZWN0IGZvcndhcmQg
c2VjcmVjeeKAnSB0byBqdXN0IOKAnGZvcndhcmQgc2VjcmVjeeKAnSBzaW5jZSDigJxwZXJmZWN0
4oCdIGlzIHN1Y2ggYSBkaWZmaWN1bHQgc3RhbmRhcmQgdG8gcmVhY2g/DQoNClRpbQ0K4oCUDQpU
aW0gSmFja3NvbiB8IFByb2R1Y3QgU2VjdXJpdHkgQXJjaGl0ZWN0IHwgTW9iaWxlSXJvbiwgSW5j
Lg0KDQpPbiA1LzE4LzE3LCAxMDo0NSBBTSwgIlRMUyBvbiBiZWhhbGYgb2YgRGFuaWVsIE1pZ2F1
bHQiIDx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZGFuaWVsLm1pZ2F1bHRAZXJp
Y3Nzb24uY29tPiB3cm90ZToNCg0KICAgIEhpIFNpbW9uLCANCiAgICANCiAgICBUaGFuayB5b3Ug
Zm9yIHRoZSByZXZpZXcuIEkgYmVsaWV2ZSB3ZSBoYXZlIGFkZHJlc3NlZCB5b3VyIGNvbW1lbnRz
IGluIG91ciB2ZXJzaW9uIDA0LiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4gDQogICAg
DQogICAgWW91cnMsIA0KICAgIERhbmllbA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQogICAgRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBTaW1vbiBGcmllZGJlcmdlcg0KICAgIFNlbnQ6IFRodXJzZGF5LCBNYXkgMDQsIDIw
MTcgNTo1OSBQTQ0KICAgIFRvOiBpZXRmQGlldGYub3JnDQogICAgQ2M6IHRsc0BpZXRmLm9yZw0K
ICAgIFN1YmplY3Q6IFJlOiBbVExTXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXRscy1lY2RoZS1w
c2stYWVhZC0wMy50eHQ+IChFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhl
ciBTdWl0ZXMgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSkgdG8gUHJvcG9zZWQg
U3RhbmRhcmQNCiAgICANCiAgICBOaXRzOg0KICAgIA0KICAgIAlSRkMgNDI3OSByZWZlcmVuY2Ug
aXMgbWlzc2luZy4NCiAgICBNR0xUOiBJdCBzZWVtcyB0aGUgcmVmZXJlbmNlIGlzIG1lbnRpb25l
ZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIGluIHRoZSBOb3JtYXRpdmUgcmVmZXJlbmNlIGFzIHdl
bGwgIGFzIGluIHRoZSBpbnRyb2R1Y3Rpb24gYXQgbGluZSAxMjcsICBpbiBzZWN0aW9uIDMgbGlu
ZSAxNDMuIEluIGNhc2UgeW91IG1lYW50IGFub3RoZXIgcmVmZXJlbmNlLCBwbGVhc2UgbGV0IHVz
IGtub3cuIA0KICAgIA0KICAgIA0KICAgIA0KICAgIAkiVExTIDEuMyBhbmQgYWJvdmUgdmVyc2lv
biwgIiBzaG91bGQgcHJvYmFibHkgYmUgIlRMUyAxLjMgYW5kIGFib3ZlIiBvciAiVExTIDEuMyBh
bmQgaGlnaGVyIHZlcnNpb25zIg0KICAgIE1HTFQ6IENoYW5nZWQgdG8gIlRMUyAxLjMgYW5kIGhp
Z2hlciB2ZXJzaW9ucyINCiAgICANCiAgICBPbiAwNC8wNS8xNyAxODo0MSwgVGhlIElFU0cgd3Jv
dGU6DQogICAgPiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFRyYW5z
cG9ydCBMYXllciBTZWN1cml0eSBXRw0KICAgID4gKHRscykgdG8gY29uc2lkZXIgdGhlIGZvbGxv
d2luZyBkb2N1bWVudDoNCiAgICA+IC0gJ0VDREhFX1BTSyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1D
Q00gQ2lwaGVyIFN1aXRlcyBmb3IgVHJhbnNwb3J0IExheWVyDQogICAgPiAgICBTZWN1cml0eSAo
VExTKScNCiAgICA+ICAgPGRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLTAzLnR4dD4gYXMg
UHJvcG9zZWQgU3RhbmRhcmQNCiAgICA+DQogICAgPiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEg
ZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgDQogICAgPiBmaW5h
bCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVu
dHMgdG8gdGhlIA0KICAgID4gaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTctMDUt
MTguIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSANCiAgICA+IGJlIHNlbnQgdG8gaWVzZ0Bp
ZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUgDQogICAg
PiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGlu
Zy4NCiAgICA+DQogICAgPiBBYnN0cmFjdA0KICAgID4NCiAgICA+DQogICAgPiAgICBUaGlzIGRv
Y3VtZW50IGRlZmluZXMgc2V2ZXJhbCBuZXcgY2lwaGVyIHN1aXRlcyBmb3IgdGhlIFRyYW5zcG9y
dA0KICAgID4gICAgTGF5ZXIgU2VjdXJpdHkgKFRMUykgcHJvdG9jb2wuICBUaGUgY2lwaGVyIHN1
aXRlcyBhcmUgYWxsIGJhc2VkIG9uDQogICAgPiAgICB0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1
cnZlIERpZmZpZS1IZWxsbWFuIHdpdGggUHJlLVNoYXJlZCBLZXkNCiAgICA+ICAgIChFQ0RIRV9Q
U0spIGtleSBleGNoYW5nZSB0b2dldGhlciB3aXRoIHRoZSBBdXRoZW50aWNhdGVkIEVuY3J5cHRp
b24NCiAgICA+ICAgIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0aG1zIEFFUy1H
Q00gYW5kIEFFUy1DQ00uICBQU0sNCiAgICA+ICAgIHByb3ZpZGVzIGxpZ2h0IGFuZCBlZmZpY2ll
bnQgYXV0aGVudGljYXRpb24sIEVDREhFIHByb3ZpZGVzIHBlcmZlY3QNCiAgICA+ICAgIGZvcndh
cmQgc2VjcmVjeSwgYW5kIEFFUy1HQ00gYW5kIEFFUy1DQ00gcHJvdmlkZXMgZW5jcnlwdGlvbiBh
bmQNCiAgICA+ICAgIGludGVncml0eSBwcm90ZWN0aW9uLg0KICAgID4NCiAgICA+DQogICAgPg0K
ICAgID4NCiAgICA+IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCiAgICA+IGh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLw0K
ICAgID4NCiAgICA+IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCiAgICA+IGh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1h
ZWFkL2JhbGxvdC8NCiAgICA+DQogICAgPg0KICAgID4gTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZl
IGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KICAgID4NCiAgICA+DQogICAg
Pg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQogICAgPiBUTFMgbWFpbGluZyBsaXN0DQogICAgPiBUTFNAaWV0Zi5vcmcNCiAgICA+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAgDQogICAgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBUTFMgbWFp
bGluZyBsaXN0DQogICAgVExTQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby90bHMNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5v
cmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgIA0K
DQo=


From nobody Thu May 18 14:04:40 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9876912EB18; Thu, 18 May 2017 14:04:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149514147857.6720.16783609697509356369@ietfa.amsl.com>
Date: Thu, 18 May 2017 14:04:38 -0700
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 18 May 2017 21:04:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : Exported Authenticators in TLS
        Author          : Nick Sullivan
	Filename        : draft-ietf-tls-exported-authenticator-00.txt
	Pages           : 6
	Date            : 2017-05-18

Abstract:
   This document describes a mechanism in Transport Layer Security (TLS)
   to provide an exportable proof of ownership of a certificate that can
   be transmitted out of band and verified by the other party.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-00
https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu May 18 14:07:53 2017
Return-Path: 
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 75037126C23; Thu, 18 May 2017 14:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 y1-lzxazPlwF; Thu, 18 May 2017 14:07:43 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC112EB52; Thu, 18 May 2017 14:01:22 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v4IL13jk046733; Thu, 18 May 2017 17:01:03 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Timothy Jackson 
CC: Daniel Migault , Simon Friedberger , "ietf@ietf.org" , "tls@ietf.org" 
Thread-Topic: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
Thread-Index: AQHSxPVWpHIsuShcKEe7pKr8MzTDmKHk/FmAgBW56QCAADQWAIAAAn8A
Date: Thu, 18 May 2017 21:01:02 +0000
Message-ID: <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu>
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se> <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com>
In-Reply-To: <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-2D23B870-777E-4452-9D5E-0D29511845E5"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-18_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705180142
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 21:07:46 -0000

--Apple-Mail-2D23B870-777E-4452-9D5E-0D29511845E5
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: base64

SXQgaXMgYSBtYXRoZW1hdGljYWwgY3J5cHRvZ3JhcGhpYyB0ZXJtLCBhbmQgYXMgc3VjaCBpcyBp
bmNvbnRyb3ZlcnRpYmxlLiANCg0KSSBzYXkgbGVhdmUgaXQgaW4uDQoNClJlZ2FyZHMsDQpVcmkN
Cg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIE1heSAxOCwgMjAxNywgYXQgMTY6NTgsIFRp
bW90aHkgSmFja3NvbiA8dGphY2tzb25AbW9iaWxlaXJvbi5jb20+IHdyb3RlOg0KPiANCj4gT25l
IHNtYWxsIG5pdC4NCj4gDQo+PiBFQ0RIRSBwcm92aWRlcyBwZXJmZWN0IGZvcndhcmQgc2VjcmVj
eQ0KPiBJIHRob3VnaHQgd2UgaGFkIGRlY2lkZWQgdG8gY2hhbmdlIJNwZXJmZWN0IGZvcndhcmQg
c2VjcmVjeZQgdG8ganVzdCCTZm9yd2FyZCBzZWNyZWN5lCBzaW5jZSCTcGVyZmVjdJQgaXMgc3Vj
aCBhIGRpZmZpY3VsdCBzdGFuZGFyZCB0byByZWFjaD8NCj4gDQo+IFRpbQ0KPiCXDQo+IFRpbSBK
YWNrc29uIHwgUHJvZHVjdCBTZWN1cml0eSBBcmNoaXRlY3QgfCBNb2JpbGVJcm9uLCBJbmMuDQo+
IA0KPiBPbiA1LzE4LzE3LCAxMDo0NSBBTSwgIlRMUyBvbiBiZWhhbGYgb2YgRGFuaWVsIE1pZ2F1
bHQiIDx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZGFuaWVsLm1pZ2F1bHRAZXJp
Y3Nzb24uY29tPiB3cm90ZToNCj4gDQo+ICAgIEhpIFNpbW9uLCANCj4gDQo+ICAgIFRoYW5rIHlv
dSBmb3IgdGhlIHJldmlldy4gSSBiZWxpZXZlIHdlIGhhdmUgYWRkcmVzc2VkIHlvdXIgY29tbWVu
dHMgaW4gb3VyIHZlcnNpb24gMDQuIFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLiANCj4g
DQo+ICAgIFlvdXJzLCANCj4gICAgRGFuaWVsDQo+IA0KPiAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiAgICBGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIFNpbW9uIEZyaWVkYmVyZ2VyDQo+ICAgIFNlbnQ6IFRodXJzZGF5LCBNYXkgMDQs
IDIwMTcgNTo1OSBQTQ0KPiAgICBUbzogaWV0ZkBpZXRmLm9yZw0KPiAgICBDYzogdGxzQGlldGYu
b3JnDQo+ICAgIFN1YmplY3Q6IFJlOiBbVExTXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXRscy1l
Y2RoZS1wc2stYWVhZC0wMy50eHQ+IChFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NN
IENpcGhlciBTdWl0ZXMgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSkgdG8gUHJv
cG9zZWQgU3RhbmRhcmQNCj4gDQo+ICAgIE5pdHM6DQo+IA0KPiAgICAgICAgUkZDIDQyNzkgcmVm
ZXJlbmNlIGlzIG1pc3NpbmcuDQo+ICAgIE1HTFQ6IEl0IHNlZW1zIHRoZSByZWZlcmVuY2UgaXMg
bWVudGlvbmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24gaW4gdGhlIE5vcm1hdGl2ZSByZWZlcmVu
Y2UgYXMgd2VsbCAgYXMgaW4gdGhlIGludHJvZHVjdGlvbiBhdCBsaW5lIDEyNywgIGluIHNlY3Rp
b24gMyBsaW5lIDE0My4gSW4gY2FzZSB5b3UgbWVhbnQgYW5vdGhlciByZWZlcmVuY2UsIHBsZWFz
ZSBsZXQgdXMga25vdy4gDQo+IA0KPiANCj4gDQo+ICAgICAgICAiVExTIDEuMyBhbmQgYWJvdmUg
dmVyc2lvbiwgIiBzaG91bGQgcHJvYmFibHkgYmUgIlRMUyAxLjMgYW5kIGFib3ZlIiBvciAiVExT
IDEuMyBhbmQgaGlnaGVyIHZlcnNpb25zIg0KPiAgICBNR0xUOiBDaGFuZ2VkIHRvICJUTFMgMS4z
IGFuZCBoaWdoZXIgdmVyc2lvbnMiDQo+IA0KPj4gICAgT24gMDQvMDUvMTcgMTg6NDEsIFRoZSBJ
RVNHIHdyb3RlOg0KPj4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBU
cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgV0cNCj4+ICh0bHMpIHRvIGNvbnNpZGVyIHRoZSBmb2xs
b3dpbmcgZG9jdW1lbnQ6DQo+PiAtICdFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NN
IENpcGhlciBTdWl0ZXMgZm9yIFRyYW5zcG9ydCBMYXllcg0KPj4gICBTZWN1cml0eSAoVExTKScN
Cj4+ICA8ZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQtMDMudHh0PiBhcyBQcm9wb3NlZCBT
dGFuZGFyZA0KPj4gDQo+PiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhl
IG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgDQo+PiBmaW5hbCBjb21tZW50cyBvbiB0aGlz
IGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlIA0KPj4gaWV0
ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTctMDUtMTguIEV4Y2VwdGlvbmFsbHksIGNv
bW1lbnRzIG1heSANCj4+IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRo
ZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUgDQo+PiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3Qg
bGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4+IA0KPj4gQWJzdHJhY3QNCj4+IA0K
Pj4gDQo+PiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVz
IGZvciB0aGUgVHJhbnNwb3J0DQo+PiAgIExheWVyIFNlY3VyaXR5IChUTFMpIHByb3RvY29sLiAg
VGhlIGNpcGhlciBzdWl0ZXMgYXJlIGFsbCBiYXNlZCBvbg0KPj4gICB0aGUgRXBoZW1lcmFsIEVs
bGlwdGljIEN1cnZlIERpZmZpZS1IZWxsbWFuIHdpdGggUHJlLVNoYXJlZCBLZXkNCj4+ICAgKEVD
REhFX1BTSykga2V5IGV4Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQgRW5j
cnlwdGlvbg0KPj4gICB3aXRoIEFzc29jaWF0ZWQgRGF0YSAoQUVBRCkgYWxnb3JpdGhtcyBBRVMt
R0NNIGFuZCBBRVMtQ0NNLiAgUFNLDQo+PiAgIHByb3ZpZGVzIGxpZ2h0IGFuZCBlZmZpY2llbnQg
YXV0aGVudGljYXRpb24sIEVDREhFIHByb3ZpZGVzIHBlcmZlY3QNCj4+ICAgZm9yd2FyZCBzZWNy
ZWN5LCBhbmQgQUVTLUdDTSBhbmQgQUVTLUNDTSBwcm92aWRlcyBlbmNyeXB0aW9uIGFuZA0KPj4g
ICBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gVGhlIGZpbGUg
Y2FuIGJlIG9idGFpbmVkIHZpYQ0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQvDQo+PiANCj4+IElFU0cgZGlzY3Vzc2lvbiBj
YW4gYmUgdHJhY2tlZCB2aWENCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkL2JhbGxvdC8NCj4+IA0KPj4gDQo+PiBObyBJUFIg
ZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+
PiANCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0Zi5vcmcNCj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+IA0KPiAgICBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICBUTFMgbWFpbGlu
ZyBsaXN0DQo+ICAgIFRMU0BpZXRmLm9yZw0KPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3Rscw0KPiANCj4gICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gICAgVExTIG1haWxpbmcgbGlzdA0KPiAgICBUTFNAaWV0Zi5v
cmcNCj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4gDQo+
IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBU
TFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3Rscw0K
--Apple-Mail-2D23B870-777E-4452-9D5E-0D29511845E5
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNTE4MjEwMTAwWjAjBgkqhkiG9w0BCQQxFgQUYtsKgimEy8Jl
HkcCr0IFKw7uMA0wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAB2kwrXMmUKJY57OiyUj4tb6JWa1DyWTGT+qSCjG
zmNOFt72HWlFqjTmPYZOkdKVrpkKlindyzfSrK6RHP5C8NE1FneiU89fsLr81fGGfnn/ki1KyOMw
5TeWKsGeQnNeWxmaKzIjKWtrnCUYSWhBsATivdBvIVY9ahIIYf0RpF7+JSwLr+wEi5yZKbleg063
RgTTGffWsKSrBFp7YIjucZ7o/+XAG+KtTPywFCUgz3tMa1OjOtQXxI3koIiVcYNv9N7K1EMjIP7P
vqCbTlq5RlLIc0Si6+Cmp5vfCTPW7wjNbqWirdbmtber2T33WnpXjNjCzuPEOuOjH7qqlq0y/YQA
AAAAAAA=

--Apple-Mail-2D23B870-777E-4452-9D5E-0D29511845E5--


From nobody Thu May 18 14:23:42 2017
Return-Path: 
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 7482D12E3AE; Thu, 18 May 2017 14:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 y8fhe8RAN8gH; Thu, 18 May 2017 14:23:38 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6931F129AAA; Thu, 18 May 2017 14:17:21 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id l9so4114961wre.1; Thu, 18 May 2017 14:17:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7OqtbsefojpFyTwgSkQ90lIBPG28RGomIDhvjYLmEoU=; b=aummM0CiR+Bzp/xGLnKfXNGP7BeCD05D8nFVVpTcG5DrpXlsC2VmEdwYKJzZXJpdds 22F3RdSSM8GheSj1ZE0tY6D1iok8Jnu7jRa9YpEQMTdOEL3IuUs0550X2TkHnk8V0Uif q1GHYAXGPYycFEoWZEH7lqzQ3cusffL/vOoN9G8+txFZXQ2sCWpi5+mQ6aH44gFYD5RR 3s7Lubk4Bx9GCsjwzl1IeGifpSw6u3GjndyGk5WTfhJ4tt2za2Jky8JTJjKLMJQ8ERGf mwB/RT6CL6DDMuL3b+0rqBnGQTX2TDU+9frUMhwCiTFKBkjIVItBiiW9QVKNCoCPKWzO WcKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7OqtbsefojpFyTwgSkQ90lIBPG28RGomIDhvjYLmEoU=; b=bUm0O9C7kvBhF3UQc67aBYvBXwby+sJ3c/mVI+jUWmg0SV/fPMQ/3Iwdj95FssFA84 QcZWcx1/UnafAk7Ys6rBVssJKYo5YFSr6tqgk9osh5ED/PoCnrxl4cRqkXcEPHIf7vpt BU+0JliYc61R0kMNaa5Gf1zFHTLYEVT0WwWDHr7WH3owKyADe8Iqu6wxjKIb4IltindW mEak8Hl/DyLWHjhelNZX2RIL4b8864WnC2UDwveiHASSeOfEZ7AiKPb/k/AyIKMEWJfm kThfaWJQrpRjHHYgnqBCDyYwntc+beKLG6UG9ju4mLj2AmE5lbKdPZz6KJ9QYb8ou6h7 5W/g==
X-Gm-Message-State: AODbwcAcJ5zzbVG5Lia0Wa+RTvFq4sYWCHto3nrhPlkE3Sg2dp66M1Ox MFEyjpZ0PVpjlyR+7Y31acBAcchwaA==
X-Received: by 10.46.78.9 with SMTP id c9mr1511334ljb.38.1495142239809; Thu, 18 May 2017 14:17:19 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Thu, 18 May 2017 14:17:19 -0700 (PDT)
In-Reply-To: <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu>
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se> <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com> <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu>
From: Daniel Migault 
Date: Thu, 18 May 2017 17:17:19 -0400
X-Google-Sender-Auth: QZPTbJFjfqJzChplbvLjW3HKuxA
Message-ID: 
To: "Blumenthal, Uri - 0553 - MITLL" 
Cc: Timothy Jackson , "ietf@ietf.org" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045ec30617b6e9054fd2ee7a"
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 21:23:41 -0000

--f403045ec30617b6e9054fd2ee7a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks Tim and Uri for the comment. At least wikipedia considers them as
equivalent. I am fine either way, but leave it  as pfs unless there is a
consensus to change it to forward secrecy. If having fs seems important to
you please let us know asap!

Yours,
Daniel

On Thu, May 18, 2017 at 5:01 PM, Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> It is a mathematical cryptographic term, and as such is incontrovertible.
>
> I say leave it in.
>
> Regards,
> Uri
>
> Sent from my iPhone
>
> > On May 18, 2017, at 16:58, Timothy Jackson 
> wrote:
> >
> > One small nit.
> >
> >> ECDHE provides perfect forward secrecy
> > I thought we had decided to change =E2=80=9Cperfect forward secrecy=E2=
=80=9D to just
> =E2=80=9Cforward secrecy=E2=80=9D since =E2=80=9Cperfect=E2=80=9D is such=
 a difficult standard to reach?
> >
> > Tim
> > =E2=80=94
> > Tim Jackson | Product Security Architect | MobileIron, Inc.
> >
> > On 5/18/17, 10:45 AM, "TLS on behalf of Daniel Migault" <
> tls-bounces@ietf.org on behalf of daniel.migault@ericsson.com> wrote:
> >
> >    Hi Simon,
> >
> >    Thank you for the review. I believe we have addressed your comments
> in our version 04. Please see my comments inline.
> >
> >    Yours,
> >    Daniel
> >
> >    -----Original Message-----
> >    From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Simon
> Friedberger
> >    Sent: Thursday, May 04, 2017 5:59 PM
> >    To: ietf@ietf.org
> >    Cc: tls@ietf.org
> >    Subject: Re: [TLS] Last Call: 
> (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
> Security (TLS)) to Proposed Standard
> >
> >    Nits:
> >
> >        RFC 4279 reference is missing.
> >    MGLT: It seems the reference is mentioned in the current version in
> the Normative reference as well  as in the introduction at line 127,  in
> section 3 line 143. In case you meant another reference, please let us kn=
ow.
> >
> >
> >
> >        "TLS 1.3 and above version, " should probably be "TLS 1.3 and
> above" or "TLS 1.3 and higher versions"
> >    MGLT: Changed to "TLS 1.3 and higher versions"
> >
> >>    On 04/05/17 18:41, The IESG wrote:
> >> The IESG has received a request from the Transport Layer Security WG
> >> (tls) to consider the following document:
> >> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Laye=
r
> >>   Security (TLS)'
> >>   as Proposed Standard
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action. Please send substantive comments to the
> >> ietf@ietf.org mailing lists by 2017-05-18. Exceptionally, comments may
> >> be sent to iesg@ietf.org instead. In either case, please retain the
> >> beginning of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>
> >>
> >>   This document defines several new cipher suites for the Transport
> >>   Layer Security (TLS) protocol.  The cipher suites are all based on
> >>   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
> >>   (ECDHE_PSK) key exchange together with the Authenticated Encryption
> >>   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
> >>   provides light and efficient authentication, ECDHE provides perfect
> >>   forward secrecy, and AES-GCM and AES-CCM provides encryption and
> >>   integrity protection.
> >>
> >>
> >>
> >>
> >> The file can be obtained via
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> >>
> >> IESG discussion can be tracked via
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/
> >>
> >>
> >> No IPR declarations have been submitted directly on this I-D.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >    _______________________________________________
> >    TLS mailing list
> >    TLS@ietf.org
> >    https://www.ietf.org/mailman/listinfo/tls
> >
> >    _______________________________________________
> >    TLS mailing list
> >    TLS@ietf.org
> >    https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--f403045ec30617b6e9054fd2ee7a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, 

Thanks Tim and Uri for the comment. =
At least wikipedia considers them as equivalent. I am fine either way, but =
leave it=C2=A0 as pfs unless there is a consensus to change it to forward s=
ecrecy. If having fs seems important to you please let us know asap!
Yours, 
Daniel 

On Thu, May 18, 2017 at 5:01 PM, Blumenthal, Uri - =
0553 - MITLL <uri@ll.mit.edu> wrote:
It is a mathematical cryptographic term, and as such is incontrover=
tible.



I say leave it in.



Regards,

Uri



Sent from my iPhone




> On May 18, 2017, at 16:58, Timothy Jackson <tjackson@mobileiron.com> wrote:

>

> One small nit.

>

>> ECDHE provides perfect forward secrecy

> I thought we had decided to change =E2=80=9Cperfect forward secrecy=E2=
=80=9D to just =E2=80=9Cforward secrecy=E2=80=9D since =E2=80=9Cperfect=E2=
=80=9D is such a difficult standard to reach?

>

> Tim

> =E2=80=94

> Tim Jackson | Product Security Architect | MobileIron, Inc.

>

> On 5/18/17, 10:45 AM, "TLS on behalf of Daniel Migault" <=
tls-bounces@ietf.org on behalf =
of daniel.migault@ericsson.c=
om> wrote:

>

>=C2=A0 =C2=A0 Hi Simon,

>

>=C2=A0 =C2=A0 Thank you for the review. I believe we have addressed you=
r comments in our version 04. Please see my comments inline.

>

>=C2=A0 =C2=A0 Yours,

>=C2=A0 =C2=A0 Daniel

>

>=C2=A0 =C2=A0 -----Original Message-----

>=C2=A0 =C2=A0 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Simon Friedberger

>=C2=A0 =C2=A0 Sent: Thursday, May 04, 2017 5:59 PM

>=C2=A0 =C2=A0 To: ietf@ietf.org
>=C2=A0 =C2=A0 Cc: tls@ietf.org

>=C2=A0 =C2=A0 Subject: Re: [TLS] Last Call: <draft-ietf-tls-ecdhe-ps=
k-aead-03.txt> (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites fo=
r Transport Layer Security (TLS)) to Proposed Standard

>

>=C2=A0 =C2=A0 Nits:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 4279 reference is missing.

>=C2=A0 =C2=A0 MGLT: It seems the reference is mentioned in the current =
version in the Normative reference as well=C2=A0 as in the introduction at =
line 127,=C2=A0 in section 3 line 143. In case you meant another reference,=
 please let us know.

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "TLS 1.3 and above version, " sho=
uld probably be "TLS 1.3 and above" or "TLS 1.3 and higher v=
ersions"

>=C2=A0 =C2=A0 MGLT: Changed to "TLS 1.3 and higher versions"<=
br>
>

>>=C2=A0 =C2=A0 On 04/05/17 18:41, The IESG wrote:

>> The IESG has received a request from the Transport Layer Security =
WG

>> (tls) to consider the following document:

>> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transp=
ort Layer

>>=C2=A0 =C2=A0Security (TLS)'

>>=C2=A0 <draft-ietf-tls-ecdhe-psk-aead-03.txt> as Propose=
d Standard

>>

>> The IESG plans to make a decision in the next few weeks, and solic=
its

>> final comments on this action. Please send substantive comments to=
 the

>> ietf@ietf.org mailing lists b=
y 2017-05-18. Exceptionally, comments may

>> be sent to iesg@ietf.org inst=
ead. In either case, please retain the

>> beginning of the Subject line to allow automated sorting.

>>

>> Abstract

>>

>>

>>=C2=A0 =C2=A0This document defines several new cipher suites for th=
e Transport

>>=C2=A0 =C2=A0Layer Security (TLS) protocol.=C2=A0 The cipher suites=
 are all based on

>>=C2=A0 =C2=A0the Ephemeral Elliptic Curve Diffie-Hellman with Pre-S=
hared Key

>>=C2=A0 =C2=A0(ECDHE_PSK) key exchange together with the Authenticat=
ed Encryption

>>=C2=A0 =C2=A0with Associated Data (AEAD) algorithms AES-GCM and AES=
-CCM.=C2=A0 PSK

>>=C2=A0 =C2=A0provides light and efficient authentication, ECDHE pro=
vides perfect

>>=C2=A0 =C2=A0forward secrecy, and AES-GCM and AES-CCM provides encr=
yption and

>>=C2=A0 =C2=A0integrity protection.

>>

>>

>>

>>

>> The file can be obtained via

>> https://datatracker.ietf.org=
/doc/draft-ietf-tls-ecdhe-psk-aead/

>>

>> IESG discussion can be tracked via

>> https://datatracker.i=
etf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/

>>

>>

>> No IPR declarations have been submitted directly on this I-D.

>>

>>

>>

>>

>> _______________________________________________

>> TLS mailing list

>> TLS@ietf.org

>> https://www.ietf.org/mailman/listinfo/tls=


>

>=C2=A0 =C2=A0 _______________________________________________

>=C2=A0 =C2=A0 TLS mailing list

>=C2=A0 =C2=A0 TLS@ietf.org

>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/tls

>

>=C2=A0 =C2=A0 _______________________________________________

>=C2=A0 =C2=A0 TLS mailing list

>=C2=A0 =C2=A0 TLS@ietf.org

>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/tls

>

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f403045ec30617b6e9054fd2ee7a--


From nobody Thu May 18 14:29:22 2017
Return-Path: 
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 8CD4512778E; Thu, 18 May 2017 14:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 sbktBnJ1BXcD; Thu, 18 May 2017 14:29:12 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 74219129BE6; Thu, 18 May 2017 14:22:17 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v4ILMFgQ009997; Thu, 18 May 2017 17:22:15 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: Daniel Migault 
CC: Timothy Jackson , "ietf@ietf.org" , "tls@ietf.org" 
Thread-Topic: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
Thread-Index: AQHSxPVWpHIsuShcKEe7pKr8MzTDmKHk/FmAgBW56QCAADQWAIAAAn8AgAAEj4CAAAFeAA==
Date: Thu, 18 May 2017 21:22:14 +0000
Message-ID: 
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se> <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com> <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-9DD953CA-CD22-4DA9-A409-550794E10AC7"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-18_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705180144
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 21:29:14 -0000

--Apple-Mail-9DD953CA-CD22-4DA9-A409-550794E10AC7
Content-Type: multipart/alternative;
	boundary=Apple-Mail-E1A62FE4-18C2-428F-BCCF-38DD24A8094C
Content-Transfer-Encoding: 7bit


--Apple-Mail-E1A62FE4-18C2-428F-BCCF-38DD24A8094C
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: base64

SW5zdGVhZCBvZiBvdXIgaW4gYWRkaXRpb24gdG8gdGhlIFdpa2ksIGNoZWNrIHNjaG9sYXJseSBy
ZWZlcmVuY2VzLiBFLmcuLCBJbnRyb2R1Y3Rpb24gdG8gTW9kZXJuIENyeXB0b2dyYXBoeSwgSGFu
ZGJvb2sgb2YgQXBwbGllZCBDcnlwdG9ncmFwaHksIGV0Yy4NCg0KUmVnYXJkcywNClVyaQ0KDQpT
ZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24gTWF5IDE4LCAyMDE3LCBhdCAxNzoxOCwgRGFuaWVs
IE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwg
DQo+IA0KPiBUaGFua3MgVGltIGFuZCBVcmkgZm9yIHRoZSBjb21tZW50LiBBdCBsZWFzdCB3aWtp
cGVkaWEgY29uc2lkZXJzIHRoZW0gYXMgZXF1aXZhbGVudC4gSSBhbSBmaW5lIGVpdGhlciB3YXks
IGJ1dCBsZWF2ZSBpdCAgYXMgcGZzIHVubGVzcyB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0byBjaGFu
Z2UgaXQgdG8gZm9yd2FyZCBzZWNyZWN5LiBJZiBoYXZpbmcgZnMgc2VlbXMgaW1wb3J0YW50IHRv
IHlvdSBwbGVhc2UgbGV0IHVzIGtub3cgYXNhcCENCj4gDQo+IFlvdXJzLCANCj4gRGFuaWVsIA0K
PiANCj4+IE9uIFRodSwgTWF5IDE4LCAyMDE3IGF0IDU6MDEgUE0sIEJsdW1lbnRoYWwsIFVyaSAt
IDA1NTMgLSBNSVRMTCA8dXJpQGxsLm1pdC5lZHU+IHdyb3RlOg0KPj4gSXQgaXMgYSBtYXRoZW1h
dGljYWwgY3J5cHRvZ3JhcGhpYyB0ZXJtLCBhbmQgYXMgc3VjaCBpcyBpbmNvbnRyb3ZlcnRpYmxl
Lg0KPj4gDQo+PiBJIHNheSBsZWF2ZSBpdCBpbi4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IFVyaQ0K
Pj4gDQo+PiBTZW50IGZyb20gbXkgaVBob25lDQo+PiANCj4+ID4gT24gTWF5IDE4LCAyMDE3LCBh
dCAxNjo1OCwgVGltb3RoeSBKYWNrc29uIDx0amFja3NvbkBtb2JpbGVpcm9uLmNvbT4gd3JvdGU6
DQo+PiA+DQo+PiA+IE9uZSBzbWFsbCBuaXQuDQo+PiA+DQo+PiA+PiBFQ0RIRSBwcm92aWRlcyBw
ZXJmZWN0IGZvcndhcmQgc2VjcmVjeQ0KPj4gPiBJIHRob3VnaHQgd2UgaGFkIGRlY2lkZWQgdG8g
Y2hhbmdlIJNwZXJmZWN0IGZvcndhcmQgc2VjcmVjeZQgdG8ganVzdCCTZm9yd2FyZCBzZWNyZWN5
lCBzaW5jZSCTcGVyZmVjdJQgaXMgc3VjaCBhIGRpZmZpY3VsdCBzdGFuZGFyZCB0byByZWFjaD8N
Cj4+ID4NCj4+ID4gVGltDQo+PiA+IJcNCj4+ID4gVGltIEphY2tzb24gfCBQcm9kdWN0IFNlY3Vy
aXR5IEFyY2hpdGVjdCB8IE1vYmlsZUlyb24sIEluYy4NCj4+ID4NCj4+ID4gT24gNS8xOC8xNywg
MTA6NDUgQU0sICJUTFMgb24gYmVoYWxmIG9mIERhbmllbCBNaWdhdWx0IiA8dGxzLWJvdW5jZXNA
aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4gd3JvdGU6
DQo+PiA+DQo+PiA+ICAgIEhpIFNpbW9uLA0KPj4gPg0KPj4gPiAgICBUaGFuayB5b3UgZm9yIHRo
ZSByZXZpZXcuIEkgYmVsaWV2ZSB3ZSBoYXZlIGFkZHJlc3NlZCB5b3VyIGNvbW1lbnRzIGluIG91
ciB2ZXJzaW9uIDA0LiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCj4+ID4NCj4+ID4g
ICAgWW91cnMsDQo+PiA+ICAgIERhbmllbA0KPj4gPg0KPj4gPiAgICAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPj4gPiAgICBGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIFNpbW9uIEZyaWVkYmVyZ2VyDQo+PiA+ICAgIFNlbnQ6IFRodXJzZGF5
LCBNYXkgMDQsIDIwMTcgNTo1OSBQTQ0KPj4gPiAgICBUbzogaWV0ZkBpZXRmLm9yZw0KPj4gPiAg
ICBDYzogdGxzQGlldGYub3JnDQo+PiA+ICAgIFN1YmplY3Q6IFJlOiBbVExTXSBMYXN0IENhbGw6
IDxkcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wMy50eHQ+IChFQ0RIRV9QU0sgd2l0aCBB
RVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1
cml0eSAoVExTKSkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4+ID4NCj4+ID4gICAgTml0czoNCj4+
ID4NCj4+ID4gICAgICAgIFJGQyA0Mjc5IHJlZmVyZW5jZSBpcyBtaXNzaW5nLg0KPj4gPiAgICBN
R0xUOiBJdCBzZWVtcyB0aGUgcmVmZXJlbmNlIGlzIG1lbnRpb25lZCBpbiB0aGUgY3VycmVudCB2
ZXJzaW9uIGluIHRoZSBOb3JtYXRpdmUgcmVmZXJlbmNlIGFzIHdlbGwgIGFzIGluIHRoZSBpbnRy
b2R1Y3Rpb24gYXQgbGluZSAxMjcsICBpbiBzZWN0aW9uIDMgbGluZSAxNDMuIEluIGNhc2UgeW91
IG1lYW50IGFub3RoZXIgcmVmZXJlbmNlLCBwbGVhc2UgbGV0IHVzIGtub3cuDQo+PiA+DQo+PiA+
DQo+PiA+DQo+PiA+ICAgICAgICAiVExTIDEuMyBhbmQgYWJvdmUgdmVyc2lvbiwgIiBzaG91bGQg
cHJvYmFibHkgYmUgIlRMUyAxLjMgYW5kIGFib3ZlIiBvciAiVExTIDEuMyBhbmQgaGlnaGVyIHZl
cnNpb25zIg0KPj4gPiAgICBNR0xUOiBDaGFuZ2VkIHRvICJUTFMgMS4zIGFuZCBoaWdoZXIgdmVy
c2lvbnMiDQo+PiA+DQo+PiA+PiAgICBPbiAwNC8wNS8xNyAxODo0MSwgVGhlIElFU0cgd3JvdGU6
DQo+PiA+PiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFRyYW5zcG9y
dCBMYXllciBTZWN1cml0eSBXRw0KPj4gPj4gKHRscykgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2lu
ZyBkb2N1bWVudDoNCj4+ID4+IC0gJ0VDREhFX1BTSyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1DQ00g
Q2lwaGVyIFN1aXRlcyBmb3IgVHJhbnNwb3J0IExheWVyDQo+PiA+PiAgIFNlY3VyaXR5IChUTFMp
Jw0KPj4gPj4gIDxkcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wMy50eHQ+IGFzIFByb3Bv
c2VkIFN0YW5kYXJkDQo+PiA+Pg0KPj4gPj4gVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lz
aW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzDQo+PiA+PiBmaW5hbCBjb21t
ZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8g
dGhlDQo+PiA+PiBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxNy0wNS0xOC4gRXhj
ZXB0aW9uYWxseSwgY29tbWVudHMgbWF5DQo+PiA+PiBiZSBzZW50IHRvIGllc2dAaWV0Zi5vcmcg
aW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQo+PiA+PiBiZWdpbm5p
bmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4+ID4+
DQo+PiA+PiBBYnN0cmFjdA0KPj4gPj4NCj4+ID4+DQo+PiA+PiAgIFRoaXMgZG9jdW1lbnQgZGVm
aW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNwb3J0DQo+PiA+PiAg
IExheWVyIFNlY3VyaXR5IChUTFMpIHByb3RvY29sLiAgVGhlIGNpcGhlciBzdWl0ZXMgYXJlIGFs
bCBiYXNlZCBvbg0KPj4gPj4gICB0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlIERpZmZpZS1I
ZWxsbWFuIHdpdGggUHJlLVNoYXJlZCBLZXkNCj4+ID4+ICAgKEVDREhFX1BTSykga2V5IGV4Y2hh
bmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0KPj4gPj4gICB3
aXRoIEFzc29jaWF0ZWQgRGF0YSAoQUVBRCkgYWxnb3JpdGhtcyBBRVMtR0NNIGFuZCBBRVMtQ0NN
LiAgUFNLDQo+PiA+PiAgIHByb3ZpZGVzIGxpZ2h0IGFuZCBlZmZpY2llbnQgYXV0aGVudGljYXRp
b24sIEVDREhFIHByb3ZpZGVzIHBlcmZlY3QNCj4+ID4+ICAgZm9yd2FyZCBzZWNyZWN5LCBhbmQg
QUVTLUdDTSBhbmQgQUVTLUNDTSBwcm92aWRlcyBlbmNyeXB0aW9uIGFuZA0KPj4gPj4gICBpbnRl
Z3JpdHkgcHJvdGVjdGlvbi4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGUg
ZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+PiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC8NCj4+ID4+DQo+PiA+PiBJRVNH
IGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+PiA+PiBodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC9iYWxsb3QvDQo+PiA+
Pg0KPj4gPj4NCj4+ID4+IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBk
aXJlY3RseSBvbiB0aGlzIEktRC4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gVExT
IG1haWxpbmcgbGlzdA0KPj4gPj4gVExTQGlldGYub3JnDQo+PiA+PiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4gPg0KPj4gPiAgICBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiAgICBUTFMgbWFpbGluZyBsaXN0
DQo+PiA+ICAgIFRMU0BpZXRmLm9yZw0KPj4gPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3Rscw0KPj4gPg0KPj4gPiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiAgICBUTFMgbWFpbGluZyBsaXN0DQo+PiA+ICAg
IFRMU0BpZXRmLm9yZw0KPj4gPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3Rscw0KPj4gPg0KPj4gPg0KPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPj4gPiBUTFMgbWFpbGluZyBsaXN0DQo+PiA+IFRMU0BpZXRmLm9y
Zw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4gDQo+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gVExT
IG1haWxpbmcgbGlzdA0KPj4gVExTQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3Rscw0KPj4gDQo+IA0K
--Apple-Mail-E1A62FE4-18C2-428F-BCCF-38DD24A8094C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SW5zdGVh
ZCBvZiBvdXIgaW4gYWRkaXRpb24gdG8gdGhlIFdpa2ksIGNoZWNrIHNjaG9sYXJseSByZWZlcmVu
Y2VzLiBFLmcuLCBJbnRyb2R1Y3Rpb24gdG8gTW9kZXJuIENyeXB0b2dyYXBoeSwgSGFuZGJvb2sg
b2YgQXBwbGllZCBDcnlwdG9ncmFwaHksIGV0Yy48YnI+PGJyPlJlZ2FyZHMsPGRpdj5Vcmk8L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48L2Rpdj48ZGl2
Pjxicj5PbiBNYXkgMTgsIDIwMTcsIGF0IDE3OjE4LCBEYW5pZWwgTWlnYXVsdCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbSI+ZGFuaWVsLm1pZ2F1bHRAZXJp
Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48ZGl2PjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PXV0Zi04Ij48ZGl2IGRpcj0ibHRyIj48ZGl2PjxkaXY+SGksIDxicj48YnI+
VGhhbmtzIFRpbSBhbmQgVXJpIGZvciB0aGUgY29tbWVudC4gQXQgbGVhc3Qgd2lraXBlZGlhIGNv
bnNpZGVycyB0aGVtIGFzIGVxdWl2YWxlbnQuIEkgYW0gZmluZSBlaXRoZXIgd2F5LCBidXQgbGVh
dmUgaXQmbmJzcDsgYXMgcGZzIHVubGVzcyB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0byBjaGFuZ2Ug
aXQgdG8gZm9yd2FyZCBzZWNyZWN5LiBJZiBoYXZpbmcgZnMgc2VlbXMgaW1wb3J0YW50IHRvIHlv
dSBwbGVhc2UgbGV0IHVzIGtub3cgYXNhcCE8YnI+PGJyPllvdXJzLCA8YnI+PC9kaXY+PC9kaXY+
RGFuaWVsIDxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9
ImdtYWlsX3F1b3RlIj5PbiBUaHUsIE1heSAxOCwgMjAxNyBhdCA1OjAxIFBNLCBCbHVtZW50aGFs
LCBVcmkgLSAwNTUzIC0gTUlUTEwgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86
dXJpQGxsLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj51cmlAbGwubWl0LmVkdTwvYT4mZ3Q7PC9z
cGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy
Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl
eCI+SXQgaXMgYSBtYXRoZW1hdGljYWwgY3J5cHRvZ3JhcGhpYyB0ZXJtLCBhbmQgYXMgc3VjaCBp
cyBpbmNvbnRyb3ZlcnRpYmxlLjxicj4NCjxicj4NCkkgc2F5IGxlYXZlIGl0IGluLjxicj4NCjxi
cj4NClJlZ2FyZHMsPGJyPg0KVXJpPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxicj4N
CjxkaXYgY2xhc3M9IkhPRW5aYiI+PGRpdiBjbGFzcz0iaDUiPjxicj4NCiZndDsgT24gTWF5IDE4
LCAyMDE3LCBhdCAxNjo1OCwgVGltb3RoeSBKYWNrc29uICZsdDs8YSBocmVmPSJtYWlsdG86dGph
Y2tzb25AbW9iaWxlaXJvbi5jb20iPnRqYWNrc29uQG1vYmlsZWlyb24uY29tPC9hPiZndDsgd3Jv
dGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT25lIHNtYWxsIG5pdC48YnI+DQomZ3Q7PGJyPg0KJmd0
OyZndDsgRUNESEUgcHJvdmlkZXMgcGVyZmVjdCBmb3J3YXJkIHNlY3JlY3k8YnI+DQomZ3Q7IEkg
dGhvdWdodCB3ZSBoYWQgZGVjaWRlZCB0byBjaGFuZ2Ug4oCccGVyZmVjdCBmb3J3YXJkIHNlY3Jl
Y3nigJ0gdG8ganVzdCDigJxmb3J3YXJkIHNlY3JlY3nigJ0gc2luY2Ug4oCccGVyZmVjdOKAnSBp
cyBzdWNoIGEgZGlmZmljdWx0IHN0YW5kYXJkIHRvIHJlYWNoPzxicj4NCiZndDs8YnI+DQomZ3Q7
IFRpbTxicj4NCiZndDsg4oCUPGJyPg0KJmd0OyBUaW0gSmFja3NvbiB8IFByb2R1Y3QgU2VjdXJp
dHkgQXJjaGl0ZWN0IHwgTW9iaWxlSXJvbiwgSW5jLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDUv
MTgvMTcsIDEwOjQ1IEFNLCAiVExTIG9uIGJlaGFsZiBvZiBEYW5pZWwgTWlnYXVsdCIgJmx0Ozxh
IGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+IG9uIGJlaGFsZiBvZiA8YSBocmVmPSJtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24u
Y29tIj5kYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7
PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgSGkgU2ltb24sPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz
cDsgJm5ic3A7IFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gSSBiZWxpZXZlIHdlIGhhdmUgYWRk
cmVzc2VkIHlvdXIgY29tbWVudHMgaW4gb3VyIHZlcnNpb24gMDQuIFBsZWFzZSBzZWUgbXkgY29t
bWVudHMgaW5saW5lLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBZb3Vycyw8YnI+
DQomZ3Q7Jm5ic3A7ICZuYnNwOyBEYW5pZWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz
cDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBGcm9t
OiBUTFMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciPnRscy1i
b3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFNpbW9uIEZyaWVkYmVyZ2VyPGJyPg0K
Jmd0OyZuYnNwOyAmbmJzcDsgU2VudDogVGh1cnNkYXksIE1heSAwNCwgMjAxNyA1OjU5IFBNPGJy
Pg0KJmd0OyZuYnNwOyAmbmJzcDsgVG86IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5p
ZXRmQGlldGYub3JnPC9hPjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IENjOiA8YSBocmVmPSJtYWls
dG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg
U3ViamVjdDogUmU6IFtUTFNdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtdGxzLWVjZGhlLXBz
ay08d2JyPmFlYWQtMDMudHh0Jmd0OyAoRUNESEVfUFNLIHdpdGggQUVTLUdDTSBhbmQgQUVTLUND
TSBDaXBoZXIgU3VpdGVzIGZvciBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykpIHRvIFBy
b3Bvc2VkIFN0YW5kYXJkPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE5pdHM6PGJy
Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUkZDIDQyNzkgcmVm
ZXJlbmNlIGlzIG1pc3NpbmcuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgTUdMVDogSXQgc2VlbXMg
dGhlIHJlZmVyZW5jZSBpcyBtZW50aW9uZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBpbiB0aGUg
Tm9ybWF0aXZlIHJlZmVyZW5jZSBhcyB3ZWxsJm5ic3A7IGFzIGluIHRoZSBpbnRyb2R1Y3Rpb24g
YXQgbGluZSAxMjcsJm5ic3A7IGluIHNlY3Rpb24gMyBsaW5lIDE0My4gSW4gY2FzZSB5b3UgbWVh
bnQgYW5vdGhlciByZWZlcmVuY2UsIHBsZWFzZSBsZXQgdXMga25vdy48YnI+DQomZ3Q7PGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICJUTFMg
MS4zIGFuZCBhYm92ZSB2ZXJzaW9uLCAiIHNob3VsZCBwcm9iYWJseSBiZSAiVExTIDEuMyBhbmQg
YWJvdmUiIG9yICJUTFMgMS4zIGFuZCBoaWdoZXIgdmVyc2lvbnMiPGJyPg0KJmd0OyZuYnNwOyAm
bmJzcDsgTUdMVDogQ2hhbmdlZCB0byAiVExTIDEuMyBhbmQgaGlnaGVyIHZlcnNpb25zIjxicj4N
CiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgT24gMDQvMDUvMTcgMTg6NDEsIFRoZSBJ
RVNHIHdyb3RlOjxicj4NCiZndDsmZ3Q7IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3Qg
ZnJvbSB0aGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IFdHPGJyPg0KJmd0OyZndDsgKHRscykg
dG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDo8YnI+DQomZ3Q7Jmd0OyAtICdFQ0RI
RV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMgZm9yIFRyYW5zcG9y
dCBMYXllcjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO1NlY3VyaXR5IChUTFMpJzxicj4NCiZn
dDsmZ3Q7Jm5ic3A7ICZsdDtkcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stPHdicj5hZWFkLTAzLnR4
dCZndDsgYXMgUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRo
ZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFu
ZCBzb2xpY2l0czxicj4NCiZndDsmZ3Q7IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQ
bGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGU8YnI+DQomZ3Q7Jmd0OyA8YSBo
cmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4gbWFpbGluZyBsaXN0
cyBieSAyMDE3LTA1LTE4LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXk8YnI+DQomZ3Q7Jmd0
OyBiZSBzZW50IHRvIDxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3Jn
PC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGU8YnI+DQomZ3Q7
Jmd0OyBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29y
dGluZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFic3RyYWN0PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVm
aW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNwb3J0PGJyPg0KJmd0
OyZndDsmbmJzcDsgJm5ic3A7TGF5ZXIgU2VjdXJpdHkgKFRMUykgcHJvdG9jb2wuJm5ic3A7IFRo
ZSBjaXBoZXIgc3VpdGVzIGFyZSBhbGwgYmFzZWQgb248YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz
cDt0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlIERpZmZpZS1IZWxsbWFuIHdpdGggUHJlLVNo
YXJlZCBLZXk8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsoRUNESEVfUFNLKSBrZXkgZXhjaGFu
Z2UgdG9nZXRoZXIgd2l0aCB0aGUgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uPGJyPg0KJmd0OyZn
dDsmbmJzcDsgJm5ic3A7d2l0aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpIGFsZ29yaXRobXMgQUVT
LUdDTSBhbmQgQUVTLUNDTS4mbmJzcDsgUFNLPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7cHJv
dmlkZXMgbGlnaHQgYW5kIGVmZmljaWVudCBhdXRoZW50aWNhdGlvbiwgRUNESEUgcHJvdmlkZXMg
cGVyZmVjdDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2ZvcndhcmQgc2VjcmVjeSwgYW5kIEFF
Uy1HQ00gYW5kIEFFUy1DQ00gcHJvdmlkZXMgZW5jcnlwdGlvbiBhbmQ8YnI+DQomZ3Q7Jmd0OyZu
YnNwOyAmbmJzcDtpbnRlZ3JpdHkgcHJvdGVjdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBmaWxlIGNh
biBiZSBvYnRhaW5lZCB2aWE8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC8iIHJlbD0ibm9y
ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdi
cj5kb2MvZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLTx3YnI+YWVhZC88L2E+PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPGJyPg0K
Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
aWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQvYmFsbG90LyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy88d2JyPmRvYy9kcmFmdC1pZXRm
LXRscy1lY2RoZS1wc2stPHdicj5hZWFkL2JhbGxvdC88L2E+PGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1p
dHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBUTFMgbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExT
QGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vdGxzPC9hPjxicj4NCiZn
dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVExTIG1haWxpbmcg
bGlzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmci
PlRMU0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3Rs
czwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsgJm5ic3A7
IFRMUyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86
VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9y
ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdi
cj5saXN0aW5mby90bHM8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFRM
UyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRM
U0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vdGxzPC9hPjxicj4NCjwvZGl2
PjwvZGl2Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19f
X19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0
Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3RsczwvYT48YnI+DQo8
YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48L2Jv
ZHk+PC9odG1sPg==

--Apple-Mail-E1A62FE4-18C2-428F-BCCF-38DD24A8094C--

--Apple-Mail-9DD953CA-CD22-4DA9-A409-550794E10AC7
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINeDCCA4Mw
ggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM
aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe
Fw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN
SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMb
sHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWwArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasy
oFhtzfTaq3AIYpnF012ECHadQ4I7XQAylSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4
MF1mP6101vuC/4YqSevrCP2baxUZrChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kk
jMn/y5RaV02RXDPUjl9H+8JrGItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5U
AL5qVuqDAgMBAAGjYDBeMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd
8hDDQ+0pMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkq
hkiG9w0BAQUFAAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg
1Pxjth/RE75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4
HhFL/ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d
Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ftgK
+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBLwwggOkoAMCAQIC
ASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh
Ym9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s
biBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8
F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ
KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6YpHF5g
mNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO+VBDlA01
Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFllQ5F/AgMBAAGj
ggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN/c9G3sjHEofK
vzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0Ew
JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZI
hvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYL
KoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8w
DQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSB
bB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kne
qXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+
BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s
6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2M
yw06w98wggUtMIIEFaADAgECAgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT
AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV
BAMTCk1JVExMIENBLTMwHhcNMTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSsw
KQYDVQQDEyJCbHVtZW50aGFsLlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAg+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oL
ToMnJQ6phCIkQGplPsM+9PpzIcw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSN
AB8WG3L+6a3mHcp9yYumPkdtM20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p
6umBCLGxZi0cGhBI/7ZyJmJUUo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857M
F4OcehpG7LuxufD0p+g02uX7Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCC
AeYwHQYDVR0OBBYEFPbiFDP71vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSME
GDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs
Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov
L2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t
aXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2
oR8dhYHgQIbXxk0CAWQCAQkwLAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsG
AQUFBwMCMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5l
ZHWgJgYKKwYBBAGCNxQCA6AYDBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQg
Hh4ATABMAE0AbwBiAGkAbABlAFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1D
kfqhBA4LYklB+i49k6dh7L+nDEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1
RjH8vLNFOEV8ZVcNxbWC5DiA6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AO
Lm42Gn4lLeNrY4Ex8nq2Ah3xjB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G
/HyJg9MUukKq23qm6Ys0VJQcJsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9
Dszxz7LQECXI0KrPpM7x32SulMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD
VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM
IENBLTMCChp0xCAAAAAArQMwCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcwNTE4MjEyMjEyWjAjBgkqhkiG9w0BCQQxFgQU+EidNsFUmp/6
t1GyrIubifx8KjkwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoa
dMQgAAAAAK0DMA0GCSqGSIb3DQEBAQUABIIBAF8kFMnIQCbE4Y66JhCWKsENmbLjQXCFn2qP1lJR
Go7lO7nz36GZGFo8Q5s0ApdLFMOdvi0Oc6yy5kunnLVOxL84B7WH/mdays3/TVnvczGPGUYRWq3+
GBYsIouydJ6G9NAB33r2yBefdTnlCSpYqjF/Rb2gZomi1ZVnLfKsLqhJVdYrcoZ0dODn/0wXvkE0
UTGGf4wx5Kw8pqLvrLRR68pjwSxnx96znzHKDyRFPe36He302oeAClkzU20VFG4AV0Qk3rLlvjrK
e2ZWY0V3e/ozZZ2tZERgmHyMa2pOU2GsUxTgc4JeNsrH5rEpEtpJfLfMO4OOIEQ2xXpytsddIWEA
AAAAAAA=

--Apple-Mail-9DD953CA-CD22-4DA9-A409-550794E10AC7--


From nobody Thu May 18 14:37:27 2017
Return-Path: 
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 250A61200B9 for ; Thu, 18 May 2017 14:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 GyjecUlKMOsf for ; Thu, 18 May 2017 14:37:24 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C671B129B5C for ; Thu, 18 May 2017 14:31:35 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id b68so27131240ywe.3 for ; Thu, 18 May 2017 14:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jdnzvD99ofr/+13li/sSrYYgPxEBdCIZ2vCVeO//4BM=; b=0uW6s/VkJGm6ufIDHW+DwtdUyPTeQxU+n3ccTPLYqz88jIVMRLWFoIaiKQMN+xKi6Q vKapbN5LMUApwrRQjZtLe4e9HHHoinJTCYB27iuzhOUMrPkI2bZ7kRA7iW9L7VAUl3+v CVIcBeFUta8wNw1o+X4RdZ0KkcL9i1LZBfujnCfgJ2qQLwx0BRmdC3wDRbUSUSMCnv1Z 2IuyuU1AbVnJSic/FZSCe8hANbKq6FAVYXkkzk8UvpnTucvAP05mvyhhwqLxwW6ag+pR gEzkwt1V/wMZIlbgQg0P2JfzrzW2NqKlly1jSu2GIa658dDSHml3boeR+SXtv4pVgvey qScw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jdnzvD99ofr/+13li/sSrYYgPxEBdCIZ2vCVeO//4BM=; b=LwqOj+j1iJkxlY1Iu+cQSXglJtcyqRzlhKHaBa0G13l1YpuCmSrIkh/ZBHzKXh4QyM tIwn90ebR0CnDTEGhX0tNkxkq0qJMiQ7gIvKNPLl3ZBsYK1oPYwzrDpTs2ggMEgAb4T4 s0iR0TMefXLP4ozVtPD9Y/s2QEGf2TWm4GJ+ugQNCirXLb2ePOh2iIo6lXjTUQ67Kzus Xi8C0K+Yv40Ecx32kXl8GHTOwQvgyL/oWrMI25Aha5QS4luCIHwC6+rFCfgR1h4aPU/M qQbL6LPvDFfsfZZv+A1vRBWz5yZYc93DEbS/mUX5CyNUTwEIRCYuxmJff8uhZfxNvdHI mbBg==
X-Gm-Message-State: AODbwcAaoSZlYmkTYfXUJkz0pSezxn9j/xkKTT7WHORGIy00ybQO5W7f b6LokZSUdSDnPv/xLpm60JtLWe6F93e8
X-Received: by 10.129.147.134 with SMTP id k128mr5575501ywg.270.1495143095063;  Thu, 18 May 2017 14:31:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 18 May 2017 14:30:54 -0700 (PDT)
In-Reply-To: 
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se> <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com> <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu> 
From: Eric Rescorla 
Date: Thu, 18 May 2017 17:30:54 -0400
Message-ID: 
To: Daniel Migault 
Cc: "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" , "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c08d3561210e2054fd3212d"
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 21:37:26 -0000

--94eb2c08d3561210e2054fd3212d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't much care, but we've moved to "forward secrecy" in TLS 1.3.

-Ekr


On Thu, May 18, 2017 at 5:17 PM, Daniel Migault  wrote:

> Hi,
>
> Thanks Tim and Uri for the comment. At least wikipedia considers them as
> equivalent. I am fine either way, but leave it  as pfs unless there is a
> consensus to change it to forward secrecy. If having fs seems important t=
o
> you please let us know asap!
>
> Yours,
> Daniel
>
> On Thu, May 18, 2017 at 5:01 PM, Blumenthal, Uri - 0553 - MITLL <
> uri@ll.mit.edu> wrote:
>
>> It is a mathematical cryptographic term, and as such is incontrovertible=
.
>>
>> I say leave it in.
>>
>> Regards,
>> Uri
>>
>> Sent from my iPhone
>>
>> > On May 18, 2017, at 16:58, Timothy Jackson 
>> wrote:
>> >
>> > One small nit.
>> >
>> >> ECDHE provides perfect forward secrecy
>> > I thought we had decided to change =E2=80=9Cperfect forward secrecy=E2=
=80=9D to just
>> =E2=80=9Cforward secrecy=E2=80=9D since =E2=80=9Cperfect=E2=80=9D is suc=
h a difficult standard to reach?
>> >
>> > Tim
>> > =E2=80=94
>> > Tim Jackson | Product Security Architect | MobileIron, Inc.
>> >
>> > On 5/18/17, 10:45 AM, "TLS on behalf of Daniel Migault" <
>> tls-bounces@ietf.org on behalf of daniel.migault@ericsson.com> wrote:
>> >
>> >    Hi Simon,
>> >
>> >    Thank you for the review. I believe we have addressed your comments
>> in our version 04. Please see my comments inline.
>> >
>> >    Yours,
>> >    Daniel
>> >
>> >    -----Original Message-----
>> >    From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Simon
>> Friedberger
>> >    Sent: Thursday, May 04, 2017 5:59 PM
>> >    To: ietf@ietf.org
>> >    Cc: tls@ietf.org
>> >    Subject: Re: [TLS] Last Call: 
>> (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>> Security (TLS)) to Proposed Standard
>> >
>> >    Nits:
>> >
>> >        RFC 4279 reference is missing.
>> >    MGLT: It seems the reference is mentioned in the current version in
>> the Normative reference as well  as in the introduction at line 127,  in
>> section 3 line 143. In case you meant another reference, please let us k=
now.
>> >
>> >
>> >
>> >        "TLS 1.3 and above version, " should probably be "TLS 1.3 and
>> above" or "TLS 1.3 and higher versions"
>> >    MGLT: Changed to "TLS 1.3 and higher versions"
>> >
>> >>    On 04/05/17 18:41, The IESG wrote:
>> >> The IESG has received a request from the Transport Layer Security WG
>> >> (tls) to consider the following document:
>> >> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Lay=
er
>> >>   Security (TLS)'
>> >>   as Proposed Standard
>> >>
>> >> The IESG plans to make a decision in the next few weeks, and solicits
>> >> final comments on this action. Please send substantive comments to th=
e
>> >> ietf@ietf.org mailing lists by 2017-05-18. Exceptionally, comments ma=
y
>> >> be sent to iesg@ietf.org instead. In either case, please retain the
>> >> beginning of the Subject line to allow automated sorting.
>> >>
>> >> Abstract
>> >>
>> >>
>> >>   This document defines several new cipher suites for the Transport
>> >>   Layer Security (TLS) protocol.  The cipher suites are all based on
>> >>   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>> >>   (ECDHE_PSK) key exchange together with the Authenticated Encryption
>> >>   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>> >>   provides light and efficient authentication, ECDHE provides perfect
>> >>   forward secrecy, and AES-GCM and AES-CCM provides encryption and
>> >>   integrity protection.
>> >>
>> >>
>> >>
>> >>
>> >> The file can be obtained via
>> >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>> >>
>> >> IESG discussion can be tracked via
>> >> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot=
/
>> >>
>> >>
>> >> No IPR declarations have been submitted directly on this I-D.
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>> >
>> >    _______________________________________________
>> >    TLS mailing list
>> >    TLS@ietf.org
>> >    https://www.ietf.org/mailman/listinfo/tls
>> >
>> >    _______________________________________________
>> >    TLS mailing list
>> >    TLS@ietf.org
>> >    https://www.ietf.org/mailman/listinfo/tls
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c08d3561210e2054fd3212d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't much care, but we've moved to "forwar=
d secrecy" in TLS 1.3.

-Ekr


On Thu, May 18=
, 2017 at 5:17 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi, 

Thanks Tim and Uri for the comment. At least wikipedia c=
onsiders them as equivalent. I am fine either way, but leave it=C2=A0 as pf=
s unless there is a consensus to change it to forward secrecy. If having fs=
 seems important to you please let us know asap!

Yours, 
Daniel 

On Thu, May 18, 2017 at 5:01 PM=
, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
It is a mathematical cryptographic term, and as=
 such is incontrovertible.



I say leave it in.



Regards,

Uri



Sent from my iPhone




> On May 18, 2017, at 16:58, Timothy Jackson <tjackson@mobileiron.com> wrote=
:

>

> One small nit.

>

>> ECDHE provides perfect forward secrecy

> I thought we had decided to change =E2=80=9Cperfect forward secrecy=E2=
=80=9D to just =E2=80=9Cforward secrecy=E2=80=9D since =E2=80=9Cperfect=E2=
=80=9D is such a difficult standard to reach?

>

> Tim

> =E2=80=94

> Tim Jackson | Product Security Architect | MobileIron, Inc.

>

> On 5/18/17, 10:45 AM, "TLS on behalf of Daniel Migault" <=
tls-bounces@ietf.=
org on behalf of daniel.migault@ericsson.com> wrote:

>

>=C2=A0 =C2=A0 Hi Simon,

>

>=C2=A0 =C2=A0 Thank you for the review. I believe we have addressed you=
r comments in our version 04. Please see my comments inline.

>

>=C2=A0 =C2=A0 Yours,

>=C2=A0 =C2=A0 Daniel

>

>=C2=A0 =C2=A0 -----Original Message-----

>=C2=A0 =C2=A0 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Simon Friedberger=


>=C2=A0 =C2=A0 Sent: Thursday, May 04, 2017 5:59 PM

>=C2=A0 =C2=A0 To: ie=
tf@ietf.org

>=C2=A0 =C2=A0 Cc: tls=
@ietf.org

>=C2=A0 =C2=A0 Subject: Re: [TLS] Last Call: <draft-ietf-tls-ecdhe-ps=
k-aead-03.txt> (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites fo=
r Transport Layer Security (TLS)) to Proposed Standard

>

>=C2=A0 =C2=A0 Nits:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 4279 reference is missing.

>=C2=A0 =C2=A0 MGLT: It seems the reference is mentioned in the current =
version in the Normative reference as well=C2=A0 as in the introduction at =
line 127,=C2=A0 in section 3 line 143. In case you meant another reference,=
 please let us know.

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "TLS 1.3 and above version, " sho=
uld probably be "TLS 1.3 and above" or "TLS 1.3 and higher v=
ersions"

>=C2=A0 =C2=A0 MGLT: Changed to "TLS 1.3 and higher versions"<=
br>
>

>>=C2=A0 =C2=A0 On 04/05/17 18:41, The IESG wrote:

>> The IESG has received a request from the Transport Layer Security =
WG

>> (tls) to consider the following document:

>> - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transp=
ort Layer

>>=C2=A0 =C2=A0Security (TLS)'

>>=C2=A0 <draft-ietf-tls-ecdhe-psk-aead-03.txt> as Propose=
d Standard

>>

>> The IESG plans to make a decision in the next few weeks, and solic=
its

>> final comments on this action. Please send substantive comments to=
 the

>> ietf@ietf.org mailing lists by 2017-05-18. Exceptionally, comments may

>> be sent to iesg=
@ietf.org instead. In either case, please retain the

>> beginning of the Subject line to allow automated sorting.

>>

>> Abstract

>>

>>

>>=C2=A0 =C2=A0This document defines several new cipher suites for th=
e Transport

>>=C2=A0 =C2=A0Layer Security (TLS) protocol.=C2=A0 The cipher suites=
 are all based on

>>=C2=A0 =C2=A0the Ephemeral Elliptic Curve Diffie-Hellman with Pre-S=
hared Key

>>=C2=A0 =C2=A0(ECDHE_PSK) key exchange together with the Authenticat=
ed Encryption

>>=C2=A0 =C2=A0with Associated Data (AEAD) algorithms AES-GCM and AES=
-CCM.=C2=A0 PSK

>>=C2=A0 =C2=A0provides light and efficient authentication, ECDHE pro=
vides perfect

>>=C2=A0 =C2=A0forward secrecy, and AES-GCM and AES-CCM provides encr=
yption and

>>=C2=A0 =C2=A0integrity protection.

>>

>>

>>

>>

>> The file can be obtained via

>> https://datatracker.ietf.org=
/doc/draft-ietf-tls-ecdhe-psk-aead/

>>

>> IESG discussion can be tracked via

>> https://datatracker.i=
etf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/

>>

>>

>> No IPR declarations have been submitted directly on this I-D.

>>

>>

>>

>>

>> _______________________________________________

>> TLS mailing list

>> TLS@ietf.org=


>> https://www.ietf.org/mailman/listinfo/tls=


>

>=C2=A0 =C2=A0 _______________________________________________

>=C2=A0 =C2=A0 TLS mailing list

>=C2=A0 =C2=A0 TLS@iet=
f.org

>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/tls

>

>=C2=A0 =C2=A0 _______________________________________________

>=C2=A0 =C2=A0 TLS mailing list

>=C2=A0 =C2=A0 TLS@iet=
f.org

>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/tls

>

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls






_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c08d3561210e2054fd3212d--


From nobody Thu May 18 14:56:57 2017
Return-Path: 
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 45F61129B2E for ; Thu, 18 May 2017 14:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 r_KN8AM-4WND for ; Thu, 18 May 2017 14:56:53 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD0412778E for ; Thu, 18 May 2017 14:51:09 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 8C0E17A32F1 for ; Thu, 18 May 2017 21:51:08 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Thu, 18 May 2017 17:51:07 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: <830025C0-3AE6-48A5-B5A9-892B0EC8612D@dukhovni.org>
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se> <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com> <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu>  
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 21:56:55 -0000

> On May 18, 2017, at 5:30 PM, Eric Rescorla  wrote:
> 
> I don't much care, but we've moved to "forward secrecy" in TLS 1.3.

That's increasingly the more appropriate term.  Yes, historically
the word "perfect" was there too, but these days we understand that
it is only as perfect as the ephemeral key-agreement algorithm,
which is vulnerable to cryptanalytic advances.

-- 
	Viktor.


From nobody Thu May 18 15:58:47 2017
Return-Path: 
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 8ECDA12EB9A for ; Thu, 18 May 2017 15:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Su98n8JBkZVi for ; Thu, 18 May 2017 15:58:44 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6870E1294CE for ; Thu, 18 May 2017 15:53:31 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id k74so48806426qke.1 for ; Thu, 18 May 2017 15:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v49H+JODZiTVVLX6dcv5QyZDC+YwvnC1YyUNUw0FmWQ=; b=J4DWq9BDilzFVochjwG26lxg/M8BwuWw5Q1TZORc0Nf7vjIOGK5kDVQopX3CGjYVKp ELSrNkvE1K+7lfOWft82Tbab5+7coUHTjVPoU9hSkntWQ4tEfW+L5eRMs4IEiLSmyUyH RZYWxQF5eUBjePvZ8mAmeLs2B4KxtapK/ObFk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v49H+JODZiTVVLX6dcv5QyZDC+YwvnC1YyUNUw0FmWQ=; b=NyCu070uqy66GfMFFg+lEv8vhOKjaYc2iUJCEDDpEPqm6PhaIIVa/SAUGIpLP9KIPP CzSqaFo4XD5S27z0ptPhBLoigo7YTPzbpsJRR2+4Eoc/6U/7R0aTGiNPRJvg8YPG6bmE 5dj8kmufZKoPkZkvZviIUgtdCl64ESw98uwM8L+UVRC7ryy333JIOeV3eAh9QV/a1H1q DLYhni9dwB4v0jLfMwplQ/nPQBqMVLUbKlnvN2Z/43ZJTZaPWJR0B3KeKWIisI9ne1Mb X5FpR/ljwh5nqJi+j71J9+V5tEx6DS4c62gpYazaVJB/2Q9wu9k3X+BUKCMTGHujv7nO HaIw==
X-Gm-Message-State: AODbwcCQTAPRn8NKLCgP1r1kL18gnjSwZIRcOQ5DPvQBDwa8a+fMhwyI HDT6ftjh1u9i1TIC
X-Received: by 10.55.129.195 with SMTP id c186mr2487849qkd.255.1495148010651;  Thu, 18 May 2017 15:53:30 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.219.90]) by smtp.gmail.com with ESMTPSA id x44sm4653457qtc.68.2017.05.18.15.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 15:53:29 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Turner 
In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com>
Date: Thu, 18 May 2017 18:53:28 -0400
Cc: lurk@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com>
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com>
To: "" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 22:58:45 -0000

All,

During the WG call for adoption, a couple of questions were raised about =
comparison/analysis of sub-certs versus proxy and/or short-lived =
certificates.  There is some discussion currently in the draft, but the =
chairs feel that these issues need further discussion (and elaboration =
in the draft) prior to WG adoption.  So let=E2=80=99s keep the =
conversation going.

J&S

> On Apr 12, 2017, at 15:31, Sean Turner  wrote:
>=20
> All,
>=20
> At our IETF 98 session, there was support in the room to adopt =
draft-rescorla-tls-subcerts [0].  We need to confirm this support on the =
list so please let the list know whether you support adoption of the =
draft and are willing to review/comment on the draft before 20170429.  =
If you object to its adoption, please let us know why.
>=20
> Clearly, the WG is going to need to work through the trade-offs =
between short-lived certificates and sub-certs because both seem, to =
some, to be addressing the same problem.=20
>=20
> Cheers,
>=20
> J&S
>=20
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts


From nobody Thu May 18 21:43:33 2017
Return-Path: 
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 70A81129C6E; Thu, 18 May 2017 21:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level: 
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 TdrSVNrUSx8o; Thu, 18 May 2017 21:43:21 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBABA129C13; Thu, 18 May 2017 21:38:35 -0700 (PDT)
X-AuditID: 1209190f-db7ff70000005284-13-591e76c97452
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.26.21124.9C67E195; Fri, 19 May 2017 00:38:34 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4J4cWgl014307; Fri, 19 May 2017 00:38:33 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4J4cRQa011042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2017 00:38:31 -0400
Date: Thu, 18 May 2017 23:38:27 -0500
From: Benjamin Kaduk 
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org
Cc: tls@ietf.org, ietf@ietf.org
Message-ID: <20170519043827.GL39245@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRmVeSWpSXmKPExsUixG6nrnuqTC7SYP57GYs3yzYxWcz4M5HZ 4tnG+SwWHxY+ZLH4dL6L0YHVY8mSn0wBjFFcNimpOZllqUX6dglcGT0P9rAWfJapWPr7P2MD 41bxLkYODgkBE4lLb1y7GLk4hAQWM0mc3vWUHcLZyCjx4m4rK4RzlUniZNdJIIeTg0VAVWLV 4WvsIDabgIpEQ/dlZhBbRMBPYt2P90wgNrOAvMSidzfBaoQFrCR+bvwDFucF2vZpRRcbhC0o cXLmExaIei2JG/9eMoFcxCwgLbH8HwdIWFRAWeLv4XssExj5ZiHpmIWkYxZCxwJG5lWMsim5 Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhBgcgpyb+DcU6D9yFGAQ5GJR7eBytkI4VY E8uKK3MPMUpyMCmJ8s4IkIsU4kvKT6nMSCzOiC8qzUktPsQowcGsJMIrLgaU401JrKxKLcqH SUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeJeVAjUKFqWmp1akZeaUIKSZODhBhvMA Dc8HqeEtLkjMLc5Mh8ifYlSUEue1KAFKCIAkMkrz4HpBiUIie3/NK0ZxoFeEeb1B2nmASQau +xXQYCagwc0PpEEGlyQipKQaGB1b8nfVilR23Fh8536vG9fSB1ev3/FOM/Tvi/9bf+exkMXs F+6TV/FeWuVulP3j4d830Ys3hhuu2/tobdPl2PPSLp0KSs8v2+/6KnBPZHvHlaU3wto23q0K WXRz6pLyd7xn3K5ML5dMWLJpQqx1HZPjA3fu3yx2S5b5mQUm/hNaN43xy+nF254qsRRnJBpq MRcVJwIA6NGlB+8CAAA=
Archived-At: 
Subject: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 04:43:23 -0000

Hi all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document is ready with nits.

Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
space, thought of as a cross product of key exchange and
cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
not quite this one.

That said, it seems a little silly to only partially fill the gap
(by omitting the AES_256_CCM* cipher suites), even though there is
not currently demand for them.

This document is just assembling pieces that were already specified
elsewhere, so it need not contain much detail itself, which is fine.
That said, I think section 3 should probably state explicitly which
pieces it uses, instead of a vague reference of being "based on RFC
4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
computed in the same manner as for ECDHE_PSK key exchange in RFC
5489."  (I am not sure why RFC 4279 is cited in the current text; it
does not cover ECDHE_PSK.)

The premaster_secret structure so used basically ends up putting the
ECDH output first followed by the static PSK; with the pre-TLS 1.2
PRF, that would give the ECDH shared secret to md5 and the PSK to
sha1, which is perhaps another reason to not use these with pre-1.2
worth mentioning (in addition to the AEAD availability).

The security considerations largely refer to those of the other
documents providing the pieces that are combined together here;
those referenced security considerations sections are more than
adequate here, as this document itself does not really do anything
particularly novel.  That said, if we are going to reiterate the
entropy requirement for PSKs inline, we probably ought to also
reiterate the nonce-reuse considerations for GCM and CCM.  The
relevant constructions help, but there are still ways to mess up and
reuse a nonce when doing crypto in parallel, if I remember the
GCM/TLS document's security considerations correctly.


Some other editorial nits follow.

I see we're already discussing "perfect forward secrecy" vs.
"forward secrecy"; my preference is for just "forward secrecy" (and
I may have been one of the more active voices in causing TLS 1.3 to
switch), but in the grand scheme of things it doesn't really matter.

In section 2, the RFC 7525 reference that "AEAD algorithms [...] are
strongly recommended" is scoped to just (D)TLS, so the text here
should probably also list that qualification.

In section 4, "... make use of the authenticated encryption with
additional data (AEAD) defined in TLS 1.2" seems to make AEAD into
something of a unique object, as opposed to a class of things with
multiple possible instantiations.  I would consider something like
"... (AEAD) concept".

In section 4, "these cipher suites MUST NOT be negotiated in TLS
versions prior to 1.2" should probably clarify that "these" cipher
suites are the new ones specified by this document.

s/Servers,\nwhich/Servers\nthat/

Does the last paragraph of section 5 want a note "RFC Editor please
remove this paragraph"?

Section 6, third paragraph, s/by using short PSK/by using a short
PSK/.  Also, s/by a human and thus/by a human which thus/, maybe?

Last paragraph page 4, comma after "i.e.".


-Ben


From nobody Fri May 19 00:22:18 2017
Return-Path: 
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 918EA129ADA; Fri, 19 May 2017 00:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L8ieFsHbj3_R; Fri, 19 May 2017 00:21:51 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACF0127A91; Fri, 19 May 2017 00:16:36 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id c13so51911702qtc.1; Fri, 19 May 2017 00:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=1l6wwkBmmZlH9uo3WF1lXR/upb5w3DhmVxp3H96FKuE=; b=CFImJbKua/vDQNK96rHApq84iAOeHIUZnaZcwkHkBj14ZqF8y5wUjljxV4GhebYG4u Y2mD095XN+5VHGPymg1T/Y59+ErQuJKUvdDc9JdtiHkRe2oNxXiW7gBTlP04G6iCVAXw GyxkheQyUBqWkZvqWEX/zy2Vb/kjsxTqy/k94BCJstWCzSAAceKLoZYYhjZ2kKdP4RSb GtbFPGTP8CBi9UxOrgBbgErHc21RqarB/LyVGjAoCUqQEmFqMjkDcN153HNCQ2EpdR5n alkbnvU6z+hSEbkYM7gEy/RWYew37WVDNg3Y1y2Fxja2wrc41Ub+tbXva7pXQ7Bw07wn ry0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=1l6wwkBmmZlH9uo3WF1lXR/upb5w3DhmVxp3H96FKuE=; b=iAyoaT7C+wAskUFNVLQJZJxw9SFTICp4NV4RcMkZE8+w8SObNW1B9YPPHECwfqus9f h5xS67so4uRBozDGHZBaBTM2Wa2lInLfsGnaYRYtXlJIdK8e1H36pONcOuaCuIjYim9W i2vdh+pNz72MeG1+ilekDAKpqO96+c0Wal5eZ7Z1IAWQsh5p37r4NHKGSJoQkYrLROiP oQ4uYqunQItjMGe547yI4kQAsTTzUd2baBXZzURPEVJ8vM51ZHqOZKvQz2fXgSfH2WCT XN8YkPo3Ql2Ea3WwrGSpb5OGp4AbtH7zv/XpoHkJ/bQaN65/XAF1+BoxFKWVN4eogpXv vrqA==
X-Gm-Message-State: AODbwcCzJz/ZSNp/ezDRdOCVUE3hGnarFT8+qvE+GSsA3Ug7fPUroj1W NzQK/92nM/OhOA2oOrk=
X-Received: by 10.200.56.243 with SMTP id g48mr8729225qtc.79.1495178195474; Fri, 19 May 2017 00:16:35 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id o13sm5426365qke.30.2017.05.19.00.16.34 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 May 2017 00:16:34 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 19 May 2017 03:16:32 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
Cc: Benjamin Kaduk , iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, ietf@ietf.org
References: <20170519043827.GL39245@kduck.kaduk.org>
In-Reply-To: <20170519043827.GL39245@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201705190316.33316.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 07:21:53 -0000

On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.

Probably should be: "the cipher suites defined in this document
MUST NOT be negotiated for any version of TLS other than 1.2."

The sentence mentioning TLS 1.3+ could be moved up to right after
and just say: "TLS version 1.3 and later negotiate these features in
a different manner."


Dave


From nobody Fri May 19 02:41:30 2017
Return-Path: 
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 5C7BF12EA52 for ; Fri, 19 May 2017 02:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4GLnJm_y2thm for ; Fri, 19 May 2017 02:41:23 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B99712EB14 for ; Fri, 19 May 2017 02:34:50 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id b204so85450478oii.1 for ; Fri, 19 May 2017 02:34:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=5Wf4Z3FFsRdeQagR15Auf8cN0p5mA8LGOF0Jl13sItQ=; b=d8MeS9Vc2YQ528W0RTD21dQJLZuVMSdjAb+mkvOnE6Hy6kdY0AJcpB7qEnTn3bVE9c PYJeOVpvVogZ0Fn1Xlw37OGdSTpuIqwGsaIPoyisuC3KKcfLg4/vI8neP7QEsW1bhgjI DEKetTv6ytJ5AMCJL/fSrd9whRcC0tHwOBAcFpCnyyQlQ37FrQPoDeCjo8cGfXc9JFSK CfU/tG83zTb70SDUT36P3C02ldVk5g0GC7/fS6QHZtOnm+ff3SUoK1+2Qf8QaDJWRRPS FE+PlcQbsHQ8+Un4I56lBewzzuS9NPBOtulWTwJX9i6LKX+OR5toyRH2q0bblpTUifxh Am5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5Wf4Z3FFsRdeQagR15Auf8cN0p5mA8LGOF0Jl13sItQ=; b=XQprHnq/qnvRWplmDhF+e9ezB/7s4XZV5aLE0cpNIol8tZh1toyN07WEgsaGpPa+QE w7WROsF+jQ+yg1uX47AnA/y1d0DWV4d4wqswnAqfcvg3iallc++e4ZwdEig60BQjPJWd q9p+Yssy6jM32BrzX3PmlWXrvoKV2gDHNKG9JzCbvJcckC2IiR+g4JTDJfpzBWx2lMyE 1yBvYBex2XHr4sGPSpk9UFD3ANrRm6yFuucY7uefgmBCbHcATMIzlSdq7R83OuLh/k07 KZsn48h/BOdonJQJWIM4mUlFHClvtORk7HE5bH4StJRNNuw0JJuBkjXlA1tFFuK+6dOw uDwA==
X-Gm-Message-State: AODbwcDCLzzXfSta4wjYnvZTIfr+/5K4ywFclmrHKmQLMJshAGDeoeKC 2j7hVUWRNVwVLKOcthJ5JJr+70/Cig==
X-Received: by 10.202.198.208 with SMTP id w199mr4054866oif.115.1495186489700;  Fri, 19 May 2017 02:34:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.56.24 with HTTP; Fri, 19 May 2017 02:34:49 -0700 (PDT)
From: Sankalp Bagaria 
Date: Fri, 19 May 2017 15:04:49 +0530
Message-ID: 
To: tls@ietf.org, Eric Rescorla ,  Kathleen Moriarty , Russ Housley 
Cc: sankalp , Balaji Rajendran 
Content-Type: multipart/alternative; boundary="001a1134fbb4979321054fdd3b63"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 09:41:27 -0000

--001a1134fbb4979321054fdd3b63
Content-Type: text/plain; charset="UTF-8"

Hi,

I would like to mention that TLS can be used with non-X.509 certificates
also.
In particular, it can be used with ITS ETSI and IEEE certificates.
https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609

So, in my opinion, TLS should be very loosely or not at all coupled with
RFC 5280.

Thanks and Regards,
Sankalp Bagaria.


> On Tue, May 16, 2017 at 11:31 AM, Russ Housley 
> wrote:
> >
> > On May 16, 2017, at 11:23 AM, Eric Rescorla  wrote:
> >
> >
> >
> > On Tue, May 16, 2017 at 8:17 AM, Russ Housley 
> wrote:
> >>
> >>
> >> On May 15, 2017, at 7:01 PM, Eric Rescorla  wrote:
> >>
> >>
> >>
> >> On Mon, May 15, 2017 at 12:38 PM, Russ Housley 
> >> wrote:
> >>>
> >>> Just commenting on Section 4.2 ?
> >>>
> >>> >
> >>> > > 3. Section 4.2.
> >>> > >
> >>> > >    "In general, detailed certificate validation procedures are out
> of
> >>> > >    scope for TLS (see [RFC5280]).  This section provides
> TLS-specific
> >>> > >    requirements."
> >>> > >
> >>> > > I don't see an explanation of why it is out-of-scope.  The
> reference
> >>> > > is just to RFC5280, which seems odd.  I would expect the reference
> to
> >>> > > be to something that explains why it is out-of-scope.
> >>>
> >>> I think the the separation of certificate path validation from the TLS
> >>> protocol is correct, but perhaps this can be explained differently.
> Perhaps
> >>> the approach should be that TLS depends upon certificate path
> validation as
> >>> described in RFC 5280.
> >>>
> >>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
> >>> > job of TLS is to carry the certificates and other authentication
> >>> > material but to leave it up to other parts of the system to
> >>> > interpret them. It's been a long time since that decision was made,
> >>> > but from my perspective, there are a number of major reasons:
> >>> >
> >>> > 1. Most of PKI processing (path construction, etc.) is generic and
> >>> >    not specific to TLS. What is specific to TLS is:
> >>> >
> >>> >    * How to indicate what your PKI capabilities are
> >>> >      (see, e.g, S 4.2.4 and 4.3.2)
> >>> >    * How to stuff the PKI material into the protocol
> >>> >      (principally S 4.4.2)
> >>> >    * How to determine whether a given certificate is suitable for
> >>> >      use in TLS 4.4.4.2 and 4.3.2.1).
> >>> >
> >>> >    So we want to outsource the generic PKI part
> >>> >
> >>> >
> >>> > 2. It matches the software architecture that people often use,
> >>> >    which is to have a TLS stack but separate PKI validation. For
> >>> >    instance, Firefox uses NSS for TLS but moz::pkix for
> >>> >    validation. Similarly, Chrome uses BoringSSL for TLS
> >>> >    but the system PKI libraries for validation.
> >>> >
> >>> >
> >>> > In this case, I think that this text was more intended to
> >>> > say "and go read 5280 to learn how to do this". To that end,
> >>> > I suggest we say"
> >>> >
> >>> >
> >>> >     "In general detailed certificate validation procedures are out of
> >>> >     scope for TLS. [RFC5280] provides general procedures for
> >>> >     certificate validation. This section provides TLS-specific
> >>> >     requirements.?
> >>>
> >>> I agree with the reasoning, however the dependency on RFC 5280 should
> be
> >>> called out in a MUST statement.  I suggest something like:
> >>>
> >>>     "TLS depends on certificate path validation, and a conformant
> >>>     TLS implementation MUST implement certificate paths validation
> >>>     in a manner that achieves the same result as [RFC5280]. This
> >>>     section provides TLS-specific requirements.?
> >>>
> >>> Note that RFC 5280 is already a normative reference.
> >>
> >>
> >> A MUST here would be a pretty material change to historical TLS
> practice.
> >> As Viktor says, there are TLS-using applications that just don't
> validate
> >> the cert via 5280 at all.
> >>
> >>
> >> I think we want to say that if the certificates are used, then the
> >> certification path MUST be validated in a manner that is compatible with
> >> Internet X.509 certificate profile [RFC5280]; however, other approaches
> to
> >> validation of the public key, such as the DANE TLSA resource record
> >> [RFC6698], are also acceptable.
> >
> >
> > I can see how you would want to say that, but it's not really consistent
> > either
> > with historical practice or with the way that other standards track RFCs
> use
> > TLS
> > with certificates (see RFC 5763).
> >
> >
> > Actually, that is a great example.  I accept the need for loose coupling.
>
> OK, does that put us back to the suggested wording:
>
>     "TLS depends on certificate path validation, and a conformant
>      TLS implementation MUST implement certificate paths validation
>      in a manner that achieves the same result as [RFC5280]. This
>      section provides TLS-specific requirements.?
>
> For any developers following, does this help enough with any
> interoperability questions?
>
> Thanks,
> Kathleen
>
> >
> > Russ
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ------------------------------
>
> End of TLS Digest, Vol 154, Issue 61
> ************************************
>

--001a1134fbb4979321054fdd3b63
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I would like to mention that TLS can be used =
with non-X.509 certificates also.
In particular, it can be used w=
ith ITS ETSI and IEEE certificates.=C2=A0

So, in my opinion, TLS should be very loosely or not at a=
ll coupled with=C2=A0
RFC 5280.

Thanks a=
nd Regards,
Sankalp Bagaria.
=C2=A0

On Tue, May 16, 2017 at 11:31 AM, Russ Housley <housley@vigilsec.com> wrote:

>

> On May 16, 2017, at 11:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>

>

>

> On Tue, May 16, 2017 at 8:17 AM, Russ Housley <housley@vigilsec.com> wrote:

>>

>>

>> On May 15, 2017, at 7:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>

>>

>>

>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <housley@vigilsec.com>

>> wrote:

>>>

>>> Just commenting on Section 4.2 ?

>>>

>>> >

>>> > > 3. Section 4.2.

>>> > >

>>> > >=C2=A0 =C2=A0 "In general, detailed certificate =
validation procedures are out of

>>> > >=C2=A0 =C2=A0 scope for TLS (see [RFC5280]).=C2=A0 Th=
is section provides TLS-specific

>>> > >=C2=A0 =C2=A0 requirements."

>>> > >

>>> > > I don't see an explanation of why it is out-of-s=
cope.=C2=A0 The reference

>>> > > is just to RFC5280, which seems odd.=C2=A0 I would e=
xpect the reference to

>>> > > be to something that explains why it is out-of-scope=
.

>>>

>>> I think the the separation of certificate path validation from=
 the TLS

>>> protocol is correct, but perhaps this can be explained differe=
ntly.=C2=A0 Perhaps

>>> the approach should be that TLS depends upon certificate path =
validation as

>>> described in RFC 5280.

>>>

>>> > In general, TLS's policy (dating back to TLS 1.0) has=
 been that the

>>> > job of TLS is to carry the certificates and other authent=
ication

>>> > material but to leave it up to other parts of the system =
to

>>> > interpret them. It's been a long time since that deci=
sion was made,

>>> > but from my perspective, there are a number of major reas=
ons:

>>> >

>>> > 1. Most of PKI processing (path construction, etc.) is ge=
neric and

>>> >=C2=A0 =C2=A0 not specific to TLS. What is specific to TLS=
 is:

>>> >

>>> >=C2=A0 =C2=A0 * How to indicate what your PKI capabilities=
 are

>>> >=C2=A0 =C2=A0 =C2=A0 (see, e.g, S 4.2.4 and 4.3.2)

>>> >=C2=A0 =C2=A0 * How to stuff the PKI material into the pro=
tocol

>>> >=C2=A0 =C2=A0 =C2=A0 (principally S 4.4.2)

>>> >=C2=A0 =C2=A0 * How to determine whether a given certifica=
te is suitable for

>>> >=C2=A0 =C2=A0 =C2=A0 use in TLS 4.4.4.2 and 4.3.2.1).

>>> >

>>> >=C2=A0 =C2=A0 So we want to outsource the generic PKI part=


>>> >

>>> >

>>> > 2. It matches the software architecture that people often=
 use,

>>> >=C2=A0 =C2=A0 which is to have a TLS stack but separate PK=
I validation. For

>>> >=C2=A0 =C2=A0 instance, Firefox uses NSS for TLS but moz::=
pkix for

>>> >=C2=A0 =C2=A0 validation. Similarly, Chrome uses BoringSSL=
 for TLS

>>> >=C2=A0 =C2=A0 but the system PKI libraries for validation.=


>>> >

>>> >

>>> > In this case, I think that this text was more intended to=


>>> > say "and go read 5280 to learn how to do this".=
 To that end,

>>> > I suggest we say"

>>> >

>>> >

>>> >=C2=A0 =C2=A0 =C2=A0"In general detailed certificate =
validation procedures are out of

>>> >=C2=A0 =C2=A0 =C2=A0scope for TLS. [RFC5280] provides gene=
ral procedures for

>>> >=C2=A0 =C2=A0 =C2=A0certificate validation. This section p=
rovides TLS-specific

>>> >=C2=A0 =C2=A0 =C2=A0requirements.?

>>>

>>> I agree with the reasoning, however the dependency on RFC 5280=
 should be

>>> called out in a MUST statement.=C2=A0 I suggest something like=
:

>>>

>>>=C2=A0 =C2=A0 =C2=A0"TLS depends on certificate path valid=
ation, and a conformant

>>>=C2=A0 =C2=A0 =C2=A0TLS implementation MUST implement certifica=
te paths validation

>>>=C2=A0 =C2=A0 =C2=A0in a manner that achieves the same result a=
s [RFC5280]. This

>>>=C2=A0 =C2=A0 =C2=A0section provides TLS-specific requirements.=
?

>>>

>>> Note that RFC 5280 is already a normative reference.

>>

>>

>> A MUST here would be a pretty material change to historical TLS pr=
actice.

>> As Viktor says, there are TLS-using applications that just don'=
;t validate

>> the cert via 5280 at all.

>>

>>

>> I think we want to say that if the certificates are used, then the=


>> certification path MUST be validated in a manner that is compatibl=
e with

>> Internet X.509 certificate profile [RFC5280]; however, other appro=
aches to

>> validation of the public key, such as the DANE TLSA resource recor=
d

>> [RFC6698], are also acceptable.

>

>

> I can see how you would want to say that, but it's not really cons=
istent

> either

> with historical practice or with the way that other standards track RF=
Cs use

> TLS

> with certificates (see RFC 5763).

>

>

> Actually, that is a great example.=C2=A0 I accept the need for loose c=
oupling.



OK, does that put us back to the suggested wording:



=C2=A0 =C2=A0 "TLS depends on certificate path validation, and a confo=
rmant

=C2=A0 =C2=A0 =C2=A0TLS implementation MUST implement certificate paths val=
idation

=C2=A0 =C2=A0 =C2=A0in a manner that achieves the same result as [RFC5280].=
 This

=C2=A0 =C2=A0 =C2=A0section provides TLS-specific requirements.?



For any developers following, does this help enough with any

interoperability questions?



Thanks,

Kathleen



>

> Russ

>







--



Best regards,

Kathleen







------------------------------



Subject: Digest Footer



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





------------------------------



End of TLS Digest, Vol 154, Issue 61

************************************





--001a1134fbb4979321054fdd3b63--


From nobody Fri May 19 02:59:41 2017
Return-Path: 
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 1F119129B62 for ; Fri, 19 May 2017 02:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 w1qLFB4Eic4Y for ; Fri, 19 May 2017 02:59:36 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1799212EC9D for ; Fri, 19 May 2017 02:53:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 0D71E23A2B; Fri, 19 May 2017 12:53:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id xzPjYqsl5M5t; Fri, 19 May 2017 12:53:18 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7430C27B; Fri, 19 May 2017 12:53:18 +0300 (EEST)
Date: Fri, 19 May 2017 12:53:17 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" 
Message-ID: <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>
References:      
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 09:59:39 -0000

On Tue, May 16, 2017 at 05:39:55PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla  wrote:
> 
> > As promised:
> > https://github.com/tlswg/tls13-spec/pull/1005
> >
> > Note: I may have to do a little post-landing cleanup, but I wanted to get
> > people's senses of the text ASAP.
> >
> 
> Thanks for everyone's comments. I've updated the text to address many of
> them and
> made comments in Github where I decided not to do so. Can those who have
> read
> the previous version please take a look?

To me, that reads as gross understatement about the dangers involved in
0-RTT:

- The side channel attacks with millions or billions of replays are hard
  to protect against. This is if the side channels are in TLS library.
  If not, protecting against that sort of side channels becomes
  virtually impossible.
- Furthermore, with that kind of replay volume, protecting against DoS
  attacks is virtually impossible.
- Even if once-per-server or once-per-cluster replay detection limits
  the number of replays to few hundred to few thoursand at maximum,
  where the low-level crypto side channels are much less of a threat,
  cache attacks can be used to break security (in fact, not sending a
  mad burst of data to any one server is useful for carrying out these).
- 0-RTT Exporters are severly broken unless servers do strict anti-
  replay.

(I left unordered replay out, because I don't see how that is
actually created by 0-RTT, as opposed to just being made easier).

There are no inherent problems in 0-RTT that I know of that would
prevent sending even non-idempotent things like HTTP POSTs over it
(however, failure rates are increased if you do). However, as
currently described, I would not think 0-RTT is safe for anything
except very boring things like protocol banners. I also do not
consider it safe enough to implement in anything that actually
considers security.


Also, on 0-RTT enable/disable: I would imagine that some browsers at
first might have an option to disable 0-RTT. However, I expect that
over time it will get removed (like what happened with the session
ticket support in Firefox), so when serious problem is discovered, there
is no option to disable the vulernable feature at all (like happened
with tickets in TLS 1.0-1.2) or the disable is far too wide (e.g.
disabling whole TLS 1.3 in order to disable 0-RTT).



Also, the kind of thing going on here seems exactly how I would imagine
the past very bad decisions from TLS WG, that were known to be insecure
at the time of specification and where then successfully attacked later,
played out. However, I have not read those discussions from the ML
archives.



-Ilari


From nobody Fri May 19 03:18:29 2017
Return-Path: 
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 68FAB12EC3C for ; Fri, 19 May 2017 03:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 lWOfKQ6d7437 for ; Fri, 19 May 2017 03:18:26 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id AC5A01294B9 for ; Fri, 19 May 2017 03:12:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 1908523324; Fri, 19 May 2017 13:12:41 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id tZ82IByIhS_B; Fri, 19 May 2017 13:12:40 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 126C927B; Fri, 19 May 2017 13:12:40 +0300 (EEST)
Date: Fri, 19 May 2017 13:12:39 +0300
From: Ilari Liusvaara 
To: Sankalp Bagaria 
Cc: tls@ietf.org
Message-ID: <20170519101239.GB30080@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 10:18:28 -0000

On Fri, May 19, 2017 at 03:04:49PM +0530, Sankalp Bagaria wrote:
> Hi,
> 
> I would like to mention that TLS can be used with non-X.509 certificates
> also.
> In particular, it can be used with ITS ETSI and IEEE certificates.
> https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609
> 
> So, in my opinion, TLS should be very loosely or not at all coupled with
> RFC 5280.

Just commenting on that draft, I don't see anything that would specify
how the certificate message itself is formatted in TLS 1.2 if those
types are used (I presume the same as the usual TLS 1.2 X.509
certificate message[1][2]). If the formatting is the same as X.509 one,
mapping that to TLS 1.3 will be straightforward. If it is not the same,
then the mapping to TLS 1.3 has to be explicitly defined.


The reason formatting for TLS 1.2 is significant is that for TLS 1.2, it
looks like each certificate type defines its own format (and none of the
three formats so fare is the same). Also, avoid putting in any non-
certificate fields, as that causes major problems with TLS 1.3 (as seen
with OpenPGP type[3]).



[1] This is list (24-bit length) of non-empty octet strings (24 bit
length).

[2] That the message formatting is the same does not imply that the
octets string contents is in any way the same.

[3] Also, RPK had its own format in TLS 1.2, but TLS 1.3 specification
explicitly gives RPK type a new format.


-Ilari


From nobody Fri May 19 06:04:27 2017
Return-Path: 
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 B62901294EF for ; Fri, 19 May 2017 06:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pl3SbCYWEq1Q for ; Fri, 19 May 2017 06:04:22 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCEA12EB44 for ; Fri, 19 May 2017 05:57:25 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id y126so511517lfc.2 for ; Fri, 19 May 2017 05:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=4fHDiIy4g78IihlhmBkURv68gcTObGKRjfU5MSoevEs=; b=buV6R569DRCVP4/P2s6F1ZI5Pnxl+N5hsjCE1IiWNJCqVSoK8zUS10FoV4mmiOwkIW gvX0T2jnIB37885gDoORaLhzd+UG4tX5zhQx92OXLyX3TydAWpEBjxZh98B8/KMVz8XQ i/r2+cyTgKu6/vJswJxGJhGOL01AecdOP1JKslx+sXuAaXFukIWIxPGWyvz2oBZEHdIf LqaZRJbC1+tXCWdeAaQnWsKQi4pfn0sQ8E3biOMTpC3ciRonOdCd3CftnIfdfEAYWIH9 knkjpuRadHDnDzGKTwOXVY3jiX9PksYZ6DtUVN4krUv93/ZpDDrA0+hyJNLe7LUBxjZE ok3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=4fHDiIy4g78IihlhmBkURv68gcTObGKRjfU5MSoevEs=; b=aetTallpa2lA/NzkPl8WgeKQWB681rNQV2iGnsd4Ibz2RoOKRiuXjSj4WJ1ARbjlT0 LuxrUVBfsNp2Dr9Gg2Fa5npUZKLpdPGuNlZcxdyUedbLbkVeL/Sqx6ohcqf+FJgBVHaE hsFQrvn+T/vEF6vXSxYKW8Ow4Cf0294rwFwYff7OCbZr/1/ZAQ85zWeyYghgwIf4fA8+ YWgLEOnAKpL5+KGmVP+6StfzPkV8jObF95NUwdk5XH9azJA1f6pMfiyUIzFmSQKxk4C0 Apx6/Zw+IdlUAldUpwn2E5O9hOSqT/J83wCXplCzMr3vaivSgX5PIlpS6E5eqUO93+FH YxSg==
X-Gm-Message-State: AODbwcDDCgdvwAwpCut1rFxfcUNnJZqQxVNH+TubaGycyfxSUALjbsW4 yJZEFugxZC9sxkOs6RQdjSnQJkaFQQ==
X-Received: by 10.46.78.9 with SMTP id c9mr2196754ljb.38.1495198643585; Fri, 19 May 2017 05:57:23 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 05:57:22 -0700 (PDT)
In-Reply-To: <830025C0-3AE6-48A5-B5A9-892B0EC8612D@dukhovni.org>
References: <149391606578.6842.3727373203321848879.idtracker@ietfa.amsl.com> <4373f972-bf9b-4dbe-1b59-7f51846831f3@a-oben.org> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB69D@eusaamb107.ericsson.se> <6191522F-FB75-4B74-B7DE-200FEDB3F021@mobileiron.com> <7E11398B-EAEF-4E06-BC6A-6797BA2197AE@ll.mit.edu>   <830025C0-3AE6-48A5-B5A9-892B0EC8612D@dukhovni.org>
From: Daniel Migault 
Date: Fri, 19 May 2017 08:57:22 -0400
X-Google-Sender-Auth: zm6ZPIV-OHFufnB0kI01uYR7Dh8
Message-ID: 
To: TLS WG 
Content-Type: multipart/alternative; boundary="f403045ec306050b9b054fe010f3"
Archived-At: 
Subject: Re: [TLS] Last Call:  (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 13:04:25 -0000

--f403045ec306050b9b054fe010f3
Content-Type: text/plain; charset="UTF-8"

Thanks for the feed backs. I have found two occurrences of perfect forward
secrecy which have been changed to forward secrecy.
Yours,
Daniel


On Thu, May 18, 2017 at 5:51 PM, Viktor Dukhovni 
wrote:

>
> > On May 18, 2017, at 5:30 PM, Eric Rescorla  wrote:
> >
> > I don't much care, but we've moved to "forward secrecy" in TLS 1.3.
>
> That's increasingly the more appropriate term.  Yes, historically
> the word "perfect" was there too, but these days we understand that
> it is only as perfect as the ephemeral key-agreement algorithm,
> which is vulnerable to cryptanalytic advances.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045ec306050b9b054fe010f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the feed backs. I have found two occu=
rrences of perfect forward secrecy which have been changed to forward secre=
cy.
Yours, 
Daniel


On Thu, May 18, 2017=
 at 5:51 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> w=
rote:


> On May 18, 2017, at 5:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>

> I don't much care, but we've moved to "forward secrecy&qu=
ot; in TLS 1.3.



That's increasingly the more appropriate term.=C2=A0 Yes, histor=
ically

the word "perfect" was there too, but these days we understand th=
at

it is only as perfect as the ephemeral key-agreement algorithm,

which is vulnerable to cryptanalytic advances.



--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f403045ec306050b9b054fe010f3--


From nobody Fri May 19 07:17:37 2017
Return-Path: 
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 1E01D127599; Fri, 19 May 2017 07:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.022
X-Spam-Level: 
X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 xcwpNoj3WGy9; Fri, 19 May 2017 07:17:14 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D761274D2; Fri, 19 May 2017 07:17:14 -0700 (PDT)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3wTqr84pCRz1KKD; Fri, 19 May 2017 16:17:12 +0200 (CEST)
X-purgate-ID: 152705::1495203432-0000521C-43C7610E/0/0
X-purgate-size: 2767
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3wTqr842gjz2ycn; Fri, 19 May 2017 16:17:12 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 84D9A1A6A1; Fri, 19 May 2017 16:17:12 +0200 (CEST)
In-Reply-To: <20170519043827.GL39245@kduck.kaduk.org>
To: Benjamin Kaduk 
Date: Fri, 19 May 2017 16:17:12 +0200 (CEST)
CC: iesg@ietf.org, secdir@ietf.org,  draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls@ietf.org, ietf@ietf.org
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170519141712.84D9A1A6A1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 14:17:16 -0000

Benjamin Kaduk wrote:
> 
> Some other editorial nits follow.
> 
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.


This reminds me of the specification goofs in several TLSv1.2-related
documents about AEAD cipher suites which are responsible for the viability
of the POODLE attack and other exploitable fallback hacks.

It would be much preferable to avoid/fix those problems and facilitate
the migration to and use of TLSv1.2 without failing TLS handshakes and
band aids such as TLS_FALLBACK_SCSV


Suggested improvement:

   The cipher suites defined in this document make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, these cipher suites MUST NOT
-  be negotiated in TLS versions prior to 1.2.  Clients MUST NOT offer
-  these cipher suites if they do not offer TLS 1.2 or later.  Servers,
-  which select an earlier version of TLS MUST NOT select one of these
-  cipher suites.  A client MUST treat the selection of these cipher
-  suites in combination with a version of TLS that does not support
-  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
-  'illegal_parameter' TLS alert.
+                                               A client that offers
+  the cipher suites from this document in ClientHello.cipher_suites
+  in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in
+  ClientHello.client_version MUST support TLSv1.2 and MUST accept
+  the server to negotiate TLSv1.2 for the current session.  If the
+  client does not support TLSv1.2 or is not willing to negotiate TLSv1.2,
+  then this client MUST NOT offer any of these cipher suites with a
+  lower protocol version than (3,3) "TLSv1.2" in ClientHello.client_version.
+  A server receiving a ClientHello and a client_version indicating
+  (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the cipher suites from
+  this document in ClientHello.cipher_suites can safely assume that the
+  client supports TLSv1.2 and is willing to use it.  The server MUST
+  NOT negotiate these cipher suites with TLS protocol versions earlier
+  than TLSv1.2.
+
+  Not requiring clients to indicate their support for TLSv1.2 cipher
+  suites exclusively through ClientHello.client_hello improves the
+  interoperability in the installed base and use of TLSv1.2 AEAD
+  cipher suites without upsetting the installed base of version-intolerant
+  TLS servers, results in more TLS handshakes succeeding and obviates
+  fallback mechanisms.


-Martin


From nobody Fri May 19 07:40:30 2017
Return-Path: 
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 1DB3512871F; Fri, 19 May 2017 07:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 fwjujipgLvp8; Fri, 19 May 2017 07:40:03 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151D6128616; Fri, 19 May 2017 07:40:02 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4JEREhR018311; Fri, 19 May 2017 15:40:00 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=nqaJ2c6f6nzUTZqHFNr++LfBDzLt1Zs6zhERmLXmwnM=; b=LSAimkt9tpudwA5d5o37bA9f3mwKATS8gWHvoVQG4FTxlYFVdEQbA4pMXNrUPVzQgS6d uxxFN3xzFw4TYbThRwtJK7uSUQ5qqdenPSutm0wp7PbjRHjiqG5Z47HJiqbp2m8G0Tgv J6kdGVpnCVm+1L7nNFYRz6Qq7KNetKVIz72O8lTs9Km/AckfMtIxEsZVLUdo0s9Fm4km QzpToK1goxFW+BMwGu+og5qjmmT91YvQq1oXuWKM57g+IEhFB8P+aj/hnV6urMCkR2DC oku68gECkN1USIWddNyGrDr+Kr0h2aO/sm7mDpEf+Fmpk+Uo0CbOjFP75TxVAKckHJdx eA== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ahya7h2ju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 May 2017 15:39:59 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4JEPUWZ028856; Fri, 19 May 2017 10:39:59 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2adwfugd74-1; Fri, 19 May 2017 10:39:58 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 37EB01FC72; Fri, 19 May 2017 14:39:58 +0000 (GMT)
To: Dave Garrett , tls@ietf.org
Cc: draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, secdir@ietf.org, ietf@ietf.org, Benjamin Kaduk , iesg@ietf.org
References: <20170519043827.GL39245@kduck.kaduk.org> <201705190316.33316.davemgarrett@gmail.com>
From: Benjamin Kaduk 
Message-ID: <010db57b-37a9-a543-d33c-cc0dd7a75fcf@akamai.com>
Date: Fri, 19 May 2017 09:39:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <201705190316.33316.davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="------------4C99548D51EF38DA6C013C38"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705190092
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705190092
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 14:40:09 -0000

This is a multi-part message in MIME format.
--------------4C99548D51EF38DA6C013C38
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/19/2017 02:16 AM, Dave Garrett wrote:
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
>> In section 4, "these cipher suites MUST NOT be negotiated in TLS
>> versions prior to 1.2" should probably clarify that "these" cipher
>> suites are the new ones specified by this document.
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
>
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
>
>

That's probably best, yes.  The interaction between this document and
TLS 1.3 is a little weird, and it's not entirely clear to me that this
one needs to say much of anything about TLS 1.3, given that TLS 1.3
changes all the relevant messages and key hierarchy and such.

-Ben

--------------4C99548D51EF38DA6C013C38
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/19/2017 02:16 AM, Dave Garrett wrote:

    

      
On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:


      

        
In section 4, "these cipher suites MUST NOT be negotiated in TLS
versions prior to 1.2" should probably clarify that "these" cipher
suites are the new ones specified by this document.


      

      
Probably should be: "the cipher suites defined in this document
MUST NOT be negotiated for any version of TLS other than 1.2."

The sentence mentioning TLS 1.3+ could be moved up to right after
and just say: "TLS version 1.3 and later negotiate these features in
a different manner."




    

    

    That's probably best, yes.  The interaction between this document
    and TLS 1.3 is a little weird, and it's not entirely clear to me
    that this one needs to say much of anything about TLS 1.3, given
    that TLS 1.3 changes all the relevant messages and key hierarchy and
    such.

    

    -Ben

  


--------------4C99548D51EF38DA6C013C38--


From nobody Fri May 19 08:56:14 2017
Return-Path: 
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 97E901294D8; Fri, 19 May 2017 08:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IePb0rm2HD51; Fri, 19 May 2017 08:55:38 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B04129484; Fri, 19 May 2017 08:55:38 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id 99so3338356lfu.1; Fri, 19 May 2017 08:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L+plUwKnFmIyg/bdkHFdC9zg9l6zsBn2dNJEtQP4xVY=; b=OSQ+ZqGcE/2bL57NRRhDieKYYUeBNWBBg2E6S6DFYfz88tYyXZEkHZNLBHMdqQ8Jc7 WbZiL65bMIesBTDfh+32SZxazGx3l6THtgI3uNT0GQGpttynE4cfwgpVC5j18jU3Vtxh Yrhz5Z6Umq4h0kNkWr3Rtooxjt7e8bjqlEMDlNEfCZY0QjzW0jGySVCR4ykay0ugoLbX yTj8GaHSJFPnwkuS3XwIWL8plxj3i8JFJSi+sSO1KhfiddfFJhPzZezqrrDtypW70aOh Gmg1SDciTUvf2ld2LAbollaPRQpsm9qDJ/lYnIh48fnSvOeC9tAqMrohd/K2aP5eZJTZ y7Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=L+plUwKnFmIyg/bdkHFdC9zg9l6zsBn2dNJEtQP4xVY=; b=HQ1nVYAOhArZTa/jmK0GNCKJvCNmOnAseIYcnZAggUSjC4txGl13VOhuqgejQx3i08 PKQ2qZHtKpRfotI+LjeSbvY6YNDicBYm/dapVR8C6uhGWbV/ZkTQUd1rpd0iJRh4xVO6 ftq07ULtpgPPVu4b9Hsmy3Dej6R3br0g/PMlLMHCcVEpYjtDz1WWGKayiq7RKPf1HyG/ vcFM0AHs7vA+qLxE41q30GWUUhgnagMiuQlvdEZ5qdAIi5sDXBGM0Nez/2tDWxCgxtS6 vpUO5CMfZOFIzhHS9ifsEuDj7oevfJZRpjX/cpPwvbQ6vEZNmcD5fAfy2RB6/CxC7KVq be8g==
X-Gm-Message-State: AODbwcCVtqG8TQp6ZCQqObtWF6Meu7zePAcPQd6ysO6TZ4mVRw8uSK+6 7xBGmHTguF4X/SLdnJtv6d7b7JzVW872
X-Received: by 10.25.228.197 with SMTP id x66mr2272178lfi.145.1495209336235; Fri, 19 May 2017 08:55:36 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 08:55:35 -0700 (PDT)
In-Reply-To: <20170519043827.GL39245@kduck.kaduk.org>
References: <20170519043827.GL39245@kduck.kaduk.org>
From: Daniel Migault 
Date: Fri, 19 May 2017 11:55:35 -0400
X-Google-Sender-Auth: mkl0vhJtSKd0EsKUTBHbL0a9Xck
Message-ID: 
To: Benjamin Kaduk 
Cc: The IESG , secdir@ietf.org,  draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls ,  "ietf@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0e7d8859eec0054fe28dcd"
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 15:55:42 -0000

--94eb2c0e7d8859eec0054fe28dcd
Content-Type: text/plain; charset="UTF-8"

Hi Benjamin,

Thank you for the review. Please find my comments inline and let me know if
you agree with the proposed text. I believe the only point not addressed
concerns the addition of CCM-256 which has been remove after discussion
during the WGLC.

Thanks you for the review,

Yours,
Daniel

On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:

> Hi all,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
>
> This document is ready with nits.
>
> Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> space, thought of as a cross product of key exchange and
> cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> not quite this one.
>
> That said, it seems a little silly to only partially fill the gap
> (by omitting the AES_256_CCM* cipher suites), even though there is
> not currently demand for them.
>
> MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and removed
after  the WGLC. [0] The issue was whether or not introducing new ciphers
not supported by TLS1.3. In 01, we though of adding the code point for
TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
the cipher suites proposed.In case of needs these could still be supported
later by TLS1.3. The consensus seems to not introduce ciphers that would
not be handled by TLS1.3. If the WG decides otherwise, these could still be
added.

[0]
https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007




> This document is just assembling pieces that were already specified
> elsewhere, so it need not contain much detail itself, which is fine.
> That said, I think section 3 should probably state explicitly which
> pieces it uses, instead of a vague reference of being "based on RFC
> 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> computed in the same manner as for ECDHE_PSK key exchange in RFC
> 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> does not cover ECDHE_PSK.)
>

MGLT: I agree we coudl be more explicit, here are the changes I propose. I
believe it address your purpose.

OLD:

Messages and pre-master secret construction in this
document are based on [RFC4279 ].

NEW:

Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages and premaster secret is
computed as for  the ECDHE_PSK key exchange.


> The premaster_secret structure so used basically ends up putting the
> ECDH output first followed by the static PSK; with the pre-TLS 1.2
> PRF, that would give the ECDH shared secret to md5 and the PSK to
> sha1, which is perhaps another reason to not use these with pre-1.2
> worth mentioning (in addition to the AEAD availability).
>

MGLT: I believe the following text address your concern, however I am
wondering if we are not going beyond the scope of expected considerations.

In addition, it is worth noting that TLS1.0  and
TL1.2  splits the premaster in two parts. The PRF
results of mixing the two pseudorandom streams with distinct hash functions
(MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
authentication, the PSK and pre-master are treated by distinct hash
function with distinct properties. This may introduce vulnerabilities over
the expected security provided by the constructed pre-master. As such
TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.


> The security considerations largely refer to those of the other
> documents providing the pieces that are combined together here;
> those referenced security considerations sections are more than
> adequate here, as this document itself does not really do anything
> particularly novel.  That said, if we are going to reiterate the
> entropy requirement for PSKs inline, we probably ought to also
> reiterate the nonce-reuse considerations for GCM and CCM.  The
> relevant constructions help, but there are still ways to mess up and
> reuse a nonce when doing crypto in parallel, if I remember the
> GCM/TLS document's security considerations correctly.
>

MGLT: I believe the following text address your comments.

 GCM or CCM encryption - even of different clear text - re-using a
nonce with a same key undermines the security of GCM and CCM. As a
result, GCM and CCM MUST only be used with system guaranteeing nonce
uniqueness .


>
> Some other editorial nits follow.
>
> I see we're already discussing "perfect forward secrecy" vs.
> "forward secrecy"; my preference is for just "forward secrecy" (and
> I may have been one of the more active voices in causing TLS 1.3 to
> switch), but in the grand scheme of things it doesn't really matter.
>
> MGLT: perfect forward secrecy has been removed and replaced by forward
secrecy.


> In section 2, the RFC 7525 reference that "AEAD algorithms [...] are
> strongly recommended" is scoped to just (D)TLS, so the text here
> should probably also list that qualification.
>

MGLT: I believe the following text address your concern:

OLD text:
AEAD algorithms that combine encryption and integrity protection are
strongly recommended for  and non-AEAD algorithms
are forbidden to use in TLS 1.3 .

NEW text:
AEAD algorithms that combine encryption and integrity protection are
strongly recommended for (D)TLS  and non-AEAD
algorithms
are forbidden to use in TLS 1.3 .

> In section 4, "... make use of the authenticated encryption with
> additional data (AEAD) defined in TLS 1.2" seems to make AEAD into
> something of a unique object, as opposed to a class of things with
> multiple possible instantiations.  I would consider something like
> "... (AEAD) concept".
>
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.
>
> MGLT: I believe the following text address your comment:

OLD:
these cipher suites MUST NOT be negotiated in TLS  versions prior to 1.2.

NEW:
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.

 OLD:
Clients MUST NOT offer these cipher suites

NEW:
Clients MUST NOT offer these cipher suites defined in this document



> s/Servers,\nwhich/Servers\nthat/
>
>
MGLT: Done


> Does the last paragraph of section 5 want a note "RFC Editor please
> remove this paragraph"?
>
> MGLT: Done


> Section 6, third paragraph, s/by using short PSK/by using a short
> PSK/.  Also, s/by a human and thus/by a human which thus/, maybe?
>
> MGLT: Probably ;-) done. thanks.


> Last paragraph page 4, comma after "i.e.".
>

MGLT: Added

>
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c0e7d8859eec0054fe28dcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Benjamin, 

Thank you f=
or the review. Please find my comments inline and let me know if you agree =
with the proposed text. I believe the only point not addressed concerns the=
 addition of CCM-256 which has been remove after discussion during the WGLC=
. 

Thanks you for the review,

Yours, 
Da=
niel

On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk &l=
t;kaduk@mit.edu><=
/span> wrote:
Hi all,<=
br>


I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the

IESG.=C2=A0 These comments were written primarily for the benefit of the
security area directors.=C2=A0 Document editors and WG chairs should

treat these comments just like any other last call comments.



This document is ready with nits.



Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite

space, thought of as a cross product of key exchange and

cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE

but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but

not quite this one.



That said, it seems a little silly to only partially fill the gap

(by omitting the AES_256_CCM* cipher suites), even though there is

not currently demand for them.


MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and  TL=
S_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0 were mentioned in the 01 and remo=
ved after=C2=A0 the WGLC. [0] The issue was whether or not introducing new =
ciphers not supported by TLS1.3. In 01, we though of adding the code point =
for TLS1.2 and then specify that TLS1.3 was only implementing a **subset** =
of the cipher suites proposed.In case of needs these could still be support=
ed later by TLS1.3. The consensus seems to not introduce ciphers that would=
 not be handled by TLS1.3. If the WG decides otherwise, these could still b=
e added.=C2=A0 =C2=A0 

[0] https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4=
/?qid=3D6e4713be1d71bae6718c6e6e6c4b8007


=C2=A0

This document is just assembling pieces that were already specified

elsewhere, so it need not contain much detail itself, which is fine.

That said, I think section 3 should probably state explicitly which

pieces it uses, instead of a vague reference of being "based on RFC
4279".=C2=A0 So, "The ServerKeyExchange and ClientKeyExchange mes=
sages

from RFC 5489 for ECDHE_PSK are used, and the premaster secret is

computed in the same manner as for ECDHE_PSK key exchange in RFC

5489."=C2=A0 (I am not sure why RFC 4279 is cited in the current text;=
 it

does not cover ECDHE_PSK.)

MGLT: I agre=
e we coudl be more explicit, here are the changes I propose. I believe it a=
ddress your purpose. 

OLD:
Messages and pre-master secret construction in this 
document are base=
d on [RFC4279=
].

NEW:
Messages an=
d pre-master secret construction in this 
document are defined in [RFC54=
89]. The ServerKeyExchange
and ClientKeyExchange messages and premaster =
secret is 
computed as for  the ECDHE_PSK key exchange. =C2=A0
=




The premaster_secret structure so used basically ends up putting the

ECDH output first followed by the static PSK; with the pre-TLS 1.2

PRF, that would give the ECDH shared secret to md5 and the PSK to

sha1, which is perhaps another reason to not use these with pre-1.2

worth mentioning (in addition to the AEAD availability).

MGLT: I believe the following text address your concern, =
however I am wondering if we are not going beyond the scope of expected con=
siderations.=C2=A0 

In addition, it is worth noting that =
TLS1.0 <xref target=3D"RFC2246"/> and TL1.2 <xref target=
=3D"RFC4346"/> splits the premaster in two parts. The PRF resu=
lts of mixing the two pseudorandom streams with distinct hash functions (MD=
5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK aut=
hentication, the PSK and pre-master are treated by distinct hash function w=
ith distinct properties. This may introduce vulnerabilities over the expect=
ed security provided by the constructed pre-master. As such TLS1.0 and TLS1=
.1 SHOULD NOT be used with ECDHE_PSK. 
=C2=A0

The security considerations largely refer to those of the other

documents providing the pieces that are combined together here;

those referenced security considerations sections are more than

adequate here, as this document itself does not really do anything

particularly novel.=C2=A0 That said, if we are going to reiterate the

entropy requirement for PSKs inline, we probably ought to also

reiterate the nonce-reuse considerations for GCM and CCM.=C2=A0 The

relevant constructions help, but there are still ways to mess up and

reuse a nonce when doing crypto in parallel, if I remember the

GCM/TLS document's security considerations correctly.
<=
div>
MGLT: I believe the following text address your comments.

=
=C2=A0<t>GCM or CCM encryption - even of different clear text - re-us=
ing a 
nonce with a same key undermines the security of GCM and CCM. As =
a
result, GCM and CCM MUST only be used with system guaranteeing nonceuniqueness <xref target=3D"RFC5116"/>.</t>

<=
/div>





Some other editorial nits follow.



I see we're already discussing "perfect forward secrecy" vs.<=
br>
"forward secrecy"; my preference is for just "forward secrec=
y" (and

I may have been one of the more active voices in causing TLS 1.3 to

switch), but in the grand scheme of things it doesn't really matter.

MGLT: perfect forward secrecy has been removed and re=
placed by forward secrecy.
=C2=A0

In section 2, the RFC 7525 reference that "AEAD algorithms [...] are
strongly recommended" is scoped to just (D)TLS, so the text here

should probably also list that qualification.
=C2=A0
MGLT: I believe the following text address your concern:
OLD text: 
<t>AEAD algorithms that combine encryption=
 and integrity protection are
strongly recommended for <xref target=
=3D"RFC7525" /> and non-AEAD algorithms
are forbidden to us=
e in TLS 1.3 <xref target=3D"I-D.ietf-tls-tls13"/>. 
NEW text:
<t>AEAD algorithms that combine encryption a=
nd integrity protection are
strongly recommended for (D)TLS <xref tar=
get=3D"RFC7525" /> and non-AEAD algorithms
are forbidden to=
 use in TLS 1.3 <xref target=3D"I-D.ietf-tls-tls13"/>. 
=


In section 4, "... make use of the authenticated encryption with

additional data (AEAD) defined in TLS 1.2" seems to make AEAD into

something of a unique object, as opposed to a class of things with

multiple possible instantiations.=C2=A0 I would consider something like

"... (AEAD) concept".



In section 4, "these cipher suites MUST NOT be negotiated in TLS

versions prior to 1.2" should probably clarify that "these" =
cipher

suites are the new ones specified by this document.


MGLT: I believe the following text address your comme=
nt:

OLD:
these cipher suites MUST NOT be negotiated in=
 TLS=C2=A0 versions prior to 1.2.

NEW:
the cipher suit=
es defined in this document MUST NOT be negotiated in TLS 
versions prio=
r to 1.2.

=C2=A0OLD:
Clients MUST NOT offer these ciph=
er suites 

NEW: 
Clients MUST NOT offer these cipher s=
uites defined in this document 

=C2=A0 

s/Servers,\nwhich/Servers\nthat/



MGLT: Done
=C2=A0

Does the last paragraph of section 5 want a note "RFC Editor please
remove this paragraph"?


MGLT: Done
=C2=A0

Section 6, third paragraph, s/by using short PSK/by using a short

PSK/.=C2=A0 Also, s/by a human and thus/by a human which thus/, maybe?


MGLT: Probably ;-) done. thanks.
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Last paragraph page 4, comma after "i.e.".
<=
br>
MGLT: Added 





-Ben



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c0e7d8859eec0054fe28dcd--


From nobody Fri May 19 09:07:49 2017
Return-Path: 
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 27D681294EC; Fri, 19 May 2017 09:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PCfPhlC85vcB; Fri, 19 May 2017 09:07:39 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB561294A4; Fri, 19 May 2017 09:07:39 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id h4so3511215lfj.3; Fri, 19 May 2017 09:07:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uwHBmfuU4afjEOllwHYg5B3VzGqkeebVf6XvE+EY0gg=; b=PO7WgfJRI5Y2h5a5x+4Z48haRK7enlYhKEX82+icO7n1mXyV5LjnAMlkEKk8fxjSWz 0+jvf7sEfKtlfVuiiTLACjUsvyfQkiXTmfyx9+i+qErhswNaQ3CSyeA1YdCJvI4GU0Zn wasg2WwNIH6Mzx+NFCyywmA/GqQYfgeTmyxyt6E0l+zTHS8W3l+5XXEVLqvL4c535EOJ roVDEwTB/rrT+TjPv6DhSKU5JPNlvdHzK2GHmBa/MLwo7q43n2rQSEf5Ld4TT2Lw5TOt uLsg9L4mTEyeKkZVHW3xCYLxhNToAHy6IsuRNcDProQyaqvlaPHfbyHCzR70vDCTJ4gi C/QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uwHBmfuU4afjEOllwHYg5B3VzGqkeebVf6XvE+EY0gg=; b=jcE9OllRpEQvmDUK1qHMHPaF4cRWxb6b7K8a6D7knpGDQoYa4hb9bSn7PP2qkPKZhy kPmeVXUU6/krEFWdSXaKRe8AoDZim750iPbRXHyViaesNYSbAHn2rlAYxwQOmdWfGzaN +/KAliemmMBtDD2ZlUu5mJMu0BZM5o8OAejs73kzwic248aUAOGJiBSC5e4mq/JHaLjX UsUM3xy0Vz+3g54RSqIsUy+NobKhahCr9U9CkDo7FFjVzVRxhxs9w9fK8tNwXVwONqCw /Ak15+sViJxy7TzRfa1jNKytQ2mq2fyBMHQXKotof7YHkAlGw4bFGOB8YgxFeifX8tZh CqGQ==
X-Gm-Message-State: AODbwcAQaJZNqMAwWyonSD+mhrlgw3B0A/VEGis8np0z/FzsIfn/ut7C LZhl8xdQk0a+isiKe/At5gS06a1JVw==
X-Received: by 10.25.193.145 with SMTP id r139mr1531754lff.111.1495210057237;  Fri, 19 May 2017 09:07:37 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 09:07:36 -0700 (PDT)
In-Reply-To: <010db57b-37a9-a543-d33c-cc0dd7a75fcf@akamai.com>
References: <20170519043827.GL39245@kduck.kaduk.org> <201705190316.33316.davemgarrett@gmail.com> <010db57b-37a9-a543-d33c-cc0dd7a75fcf@akamai.com>
From: Daniel Migault 
Date: Fri, 19 May 2017 12:07:36 -0400
X-Google-Sender-Auth: 9qEQEUqd_BBy51at4x7pj0L4Fqc
Message-ID: 
To: Benjamin Kaduk 
Cc: Dave Garrett , tls , The IESG ,  Benjamin Kaduk , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org,  "ietf@ietf.org" , secdir@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1a0878538d39054fe2b8a6"
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 16:07:41 -0000

--94eb2c1a0878538d39054fe2b8a6
Content-Type: text/plain; charset="UTF-8"

Hi Benjamin and Dave,

Thanks for the clarification. Considering also Roman' s and Ben' s comments
the section is built as follow. 1) Limit cipher suites to TLS1.2, 2)
explain how TLS1.3 and higher version negotiate them 3) bring all
explanation foe the previous versions.

Yours,
Daniel

The text is as follows:

 The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS1.2.

 TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS1.2, TLS1.3 separates authentication and cipher suite
negotiation  Section 1.2. TLS1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. 

The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
 and DTLS 1.2 .
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS1.0
 and TL1.2  splits teh
pre-master in two parts. The PRF results of mixing the two pseudorandom
streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In the case of ECDHE_PSK authentication, the PSK and
pre-master are treated by distinct hash function with distinct
properties. This may introduce vulnerabilities over the expected
security provided by the constructed pre-master. As such TLS1.0 and
TLS1.1 SHOULD NOT be used with ECDHE_PSK.  Clients MUST NOT offer these
cipher suites defined in this document if they do not offer TLS 1.2 or
later. Servers that select an earlier version of TLS MUST NOT select one
of these cipher suites. A client MUST treat the selection of these
cipher suites in combination with a version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' TLS alert.




On Fri, May 19, 2017 at 10:39 AM, Benjamin Kaduk  wrote:

> On 05/19/2017 02:16 AM, Dave Garrett wrote:
>
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
>
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.
>
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
>
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
>
>
>
>
> That's probably best, yes.  The interaction between this document and TLS
> 1.3 is a little weird, and it's not entirely clear to me that this one
> needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all
> the relevant messages and key hierarchy and such.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c1a0878538d39054fe2b8a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Benjamin and Dave, 

Thanks for t=
he clarification. Considering also Roman' s and Ben' s comments the=
 section is built as follow. 1) Limit cipher suites to TLS1.2, 2) explain h=
ow TLS1.3 and higher version negotiate them 3) bring all explanation foe th=
e previous versions.

Yours, 
Daniel

=

The text is as follows:

<t> The cipher suites defined in=
 this document MUST NOT be negotiated
for any version of (D)TLS other th=
an TLS1.2.</t>

<t> TLS version 1.3 and later negotiate t=
hese features in a different
manner. Unlike TLS1.2, TLS1.3 separates aut=
hentication and cipher suite
negotiation <xref target=3D"I-D.iet=
f-tls-tls13"/> Section 1.2. TLS1.3
supports PSK with ECDHE key e=
xchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SH=
A384, TLS_AES_128_CCM_8_SHA256 
and=C2=A0 TLS_AES_128_CCM_SHA256 are par=
t of the specification. As a result,
TLS 1.3 and higher versions, negoti=
ate and support these cipher suites
in a different way. </t>
<t>The cipher suites defined in this document make use of the
au=
thenticated encryption with additional data (AEAD) defined in TLS 1.2
&l=
t;xref target=3D"RFC5246"/> and DTLS 1.2 <xref target=3D&qu=
ot;RFC6347" />.
Earlier versions of TLS do not have support for =
AEAD and consequently,
the cipher suites defined in this document MUST N=
OT be negotiated in TLS
versions prior to 1.2.=C2=A0 In addition, it is =
worth noting that TLS1.0
<xref target=3D"RFC2246"/> and =
TL1.2 <xref target=3D"RFC4346"/> splits teh
pre-master i=
n two parts. The PRF results of mixing the two pseudorandom
streams with=
 distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them togethe=
r. In the case of ECDHE_PSK authentication, the PSK and
pre-master are t=
reated by distinct hash function with distinct
properties. This may intr=
oduce vulnerabilities over the expected
security provided by the constru=
cted pre-master. As such TLS1.0 and
TLS1.1 SHOULD NOT be used with ECDHE=
_PSK.=C2=A0 Clients MUST NOT offer these
cipher suites defined in this d=
ocument if they do not offer TLS 1.2 or
later. Servers that select an ea=
rlier version of TLS MUST NOT select one
of these cipher suites. A clien=
t MUST treat the selection of these
cipher suites in combination with a =
version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as =
an error and generate a fatal 
'illegal_parameter' TLS alert.<=
;/t>

=C2=A0 

On Fri, May 19, 2017 at 10:39 AM, Benjamin Kadu=
k <bkaduk@akamai.com> wrote:

 =20
   =20
 =20
  

    On 05/19/2017 02:16 AM, Dave Garrett wrote:

    

      
On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:


      

        
In section 4, "these cipher suites MUST NOT be negotiated=
 in TLS
versions prior to 1.2" should probably clarify that "these" =
cipher
suites are the new ones specified by this document.


      

      
Probably should be: "the cipher suites defined in this docu=
ment
MUST NOT be negotiated for any version of TLS other than 1.2."

The sentence mentioning TLS 1.3+ could be moved up to right after
and just say: "TLS version 1.3 and later negotiate these features in
a different manner."




    

    

    That's probably best, yes.=C2=A0 The interaction between this docum=
ent
    and TLS 1.3 is a little weird, and it's not entirely clear to me
    that this one needs to say much of anything about TLS 1.3, given
    that TLS 1.3 changes all the relevant messages and key hierarchy and
    such.

    

    -Ben

  



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c1a0878538d39054fe2b8a6--


From nobody Fri May 19 09:26:21 2017
Return-Path: 
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 BCFF712955F; Fri, 19 May 2017 09:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R5W5i34hUVr6; Fri, 19 May 2017 09:25:54 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C441294F3; Fri, 19 May 2017 09:25:53 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id y126so3711035lfc.2; Fri, 19 May 2017 09:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bE8IPZygLAJ0pGuNryzThjkvrgswGRp2YcsgJ+gq/Rw=; b=iBczSge/YhesrK4a3UJvGU4UHTlmhhzglARpMLvX/+TDV7JuP4sGmK/8hvdcpRMgc7 OTOvCJ/oM5v+JdmmFxGKoL/5ImGrIaC3iKJ2+8QjBQBayrfz1i7FVvrNo0+laugh0ZrZ kOSi8txkxz7IbpMe2RFhaWhtS1nsQ4Er5kDMkCIDLfRiwE/xIEWjaAg2bZoQT3MvNlnb yGondVLxCcJ7ZJqBqYzC9HtzCXf8UA+WGcskSH9cmQ4En9dmJPmBTjCBIg3GiHSxpreM ucJcnwm7smgOIDNwPUtrNW5aJgO0DFn+pBskjGQvAVUBo8Eya9LHTpjKCW71jP78ng0D bBLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bE8IPZygLAJ0pGuNryzThjkvrgswGRp2YcsgJ+gq/Rw=; b=m/n42gDzlb3okWAzofhnc4nXIMYgO6GB3IxUWBri8M+tnqJRSdTpPvrDsAsPBSeeul ger5hE2H++WEHPhmLjMdJzV4i1EW36a00eDCiHHdoYH/GLYDGfx6wf5y4kPG6GHwc2/o XnGa9GvJb/biZfho8YSVe2MeciDziiQuBs3Fhwo+XuatF/8c0OHYNJcG7eFC0oI1XyqS DLt4KGx1mx1blGiCixHN5MH+EdSpWdDtKtDCmeKGA5Rri8PcGqIjMvBP0u3zjXwMBWwu jX0qjzHMFvGmkhTCtbbZ+cGe1IqQSDfs7dBHL8VdT+Iyc/lU1NbpFI/jh7sdqOC3dalb pcTA==
X-Gm-Message-State: AODbwcCBSP/jpEaaINwznvPwwiGzuoEh5N7VbglxFiplsfTfKGxgUxcO 1ZedHvywuQxWKsRa8SP2+Zmy/gpDdA==
X-Received: by 10.25.229.69 with SMTP id c66mr2783915lfh.102.1495211151786; Fri, 19 May 2017 09:25:51 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 09:25:51 -0700 (PDT)
In-Reply-To: <20170519141712.84D9A1A6A1@ld9781.wdf.sap.corp>
References: <20170519043827.GL39245@kduck.kaduk.org> <20170519141712.84D9A1A6A1@ld9781.wdf.sap.corp>
From: Daniel Migault 
Date: Fri, 19 May 2017 12:25:51 -0400
X-Google-Sender-Auth: WPgY13FdGIvJnTffCNRBub0cj_Q
Message-ID: 
To: mrex@sap.com
Cc: Benjamin Kaduk , tls ,  draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" ,  The IESG , secdir@ietf.org
Content-Type: multipart/alternative; boundary="001a113c0cb2910d10054fe2f9e6"
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 16:25:57 -0000

--001a113c0cb2910d10054fe2f9e6
Content-Type: text/plain; charset="UTF-8"

Hi Martin,

Thank you for the proposed text. It was very clear and I took it entirely,
just changing s/TLSv1/TLS 1/.

Yours,
Daniel


The current text is as follows:




 The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS 1.2.

 TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS 1.2, TLS 1.3 separates authentication and cipher suite
negotiation  Section 1.2. TLS 1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. 

The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
 and DTLS 1.2 .
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS 1.0
 and TL1.2  splits the
pre-master in two parts. The PRF results of mixing the two pseudorandom
streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In the case of ECDHE_PSK authentication, the PSK and
pre-master are treated by distinct hash function with distinct
properties. This may introduce vulnerabilities over the expected
security provided by the constructed pre-master. As such TLS 1.0 and
TLS 1.1 SHOULD NOT be used with ECDHE_PSK.

A client that offers the cipher suites from this document in
ClientHello.cipher_suites in combination with (3,1) "TLS 1.0" or (3,2)
"TLS 1.1" in ClientHello.client_version MUST support TLS 1.2 and MUST
accept the server to negotiate TLS 1.2 for the current session.  If the
client does not support TLS 1.2 or is not willing to negotiate TLS 1.2,
then this client MUST NOT offer any of these cipher suites with a lower
protocol version than (3,3) "TLS 1.2" in ClientHello.client_version.

A server receiving a ClientHello and a client_version indicating
(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
this document in ClientHello.cipher_suites can safely assume that the
client supports TLS 1.2 and is willing to use it. The server MUST NOT
negotiate these cipher suites with TLS protocol versions earlier than
TLS 1.2. Not requiring clients to indicate their support for TLS 1.2
cipher suites exclusively through ClientHello.client_hello improves the
interoperability in the installed base and use of TLS 1.2 AEAD cipher
suites without upsetting the installed base of version-intolerant TLS
servers, results in more TLS handshakes succeeding and obviates fallback
mechanisms.


On Fri, May 19, 2017 at 10:17 AM, Martin Rex  wrote:

> Benjamin Kaduk wrote:
> >
> > Some other editorial nits follow.
> >
> > In section 4, "these cipher suites MUST NOT be negotiated in TLS
> > versions prior to 1.2" should probably clarify that "these" cipher
> > suites are the new ones specified by this document.
>
>
> This reminds me of the specification goofs in several TLSv1.2-related
> documents about AEAD cipher suites which are responsible for the viability
> of the POODLE attack and other exploitable fallback hacks.
>
> It would be much preferable to avoid/fix those problems and facilitate
> the migration to and use of TLSv1.2 without failing TLS handshakes and
> band aids such as TLS_FALLBACK_SCSV
>
>
> Suggested improvement:
>
>    The cipher suites defined in this document make use of the
>    authenticated encryption with additional data (AEAD) defined in TLS
>    1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
>    have support for AEAD and consequently, these cipher suites MUST NOT
> -  be negotiated in TLS versions prior to 1.2.  Clients MUST NOT offer
> -  these cipher suites if they do not offer TLS 1.2 or later.  Servers,
> -  which select an earlier version of TLS MUST NOT select one of these
> -  cipher suites.  A client MUST treat the selection of these cipher
> -  suites in combination with a version of TLS that does not support
> -  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
> -  'illegal_parameter' TLS alert.
> +                                               A client that offers
> +  the cipher suites from this document in ClientHello.cipher_suites
> +  in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in
> +  ClientHello.client_version MUST support TLSv1.2 and MUST accept
> +  the server to negotiate TLSv1.2 for the current session.  If the
> +  client does not support TLSv1.2 or is not willing to negotiate TLSv1.2,
> +  then this client MUST NOT offer any of these cipher suites with a
> +  lower protocol version than (3,3) "TLSv1.2" in
> ClientHello.client_version.
> +  A server receiving a ClientHello and a client_version indicating
> +  (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the cipher suites from
> +  this document in ClientHello.cipher_suites can safely assume that the
> +  client supports TLSv1.2 and is willing to use it.  The server MUST
> +  NOT negotiate these cipher suites with TLS protocol versions earlier
> +  than TLSv1.2.
> +
> +  Not requiring clients to indicate their support for TLSv1.2 cipher
> +  suites exclusively through ClientHello.client_hello improves the
> +  interoperability in the installed base and use of TLSv1.2 AEAD
> +  cipher suites without upsetting the installed base of version-intolerant
> +  TLS servers, results in more TLS handshakes succeeding and obviates
> +  fallback mechanisms.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113c0cb2910d10054fe2f9e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Martin, 

Thank you for=
 the proposed text. It was very clear and I took it entirely, just changing=
 s/TLSv1/TLS 1/. 

Yours, 
Daniel


The=
 current text is as follows:
<section title=3D"Applicable TLS Ve=
rsions">


<t> The cipher suites defined in this doc=
ument MUST NOT be negotiated
for any version of (D)TLS other than TLS 1.=
2.</t>

<t> TLS version 1.3 and later negotiate these fea=
tures in a different
manner. Unlike TLS 1.2, TLS 1.3 separates authentic=
ation and cipher suite
negotiation <xref target=3D"I-D.ietf-tls-=
tls13"/> Section 1.2. TLS 1.3
supports PSK with ECDHE key exchan=
ge and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,=
 TLS_AES_128_CCM_8_SHA256
and=C2=A0 TLS_AES_128_CCM_SHA256 are part of t=
he specification. As a result,
TLS 1.3 and higher versions, negotiate an=
d support these cipher suites
in a different way. </t>

<=
t>The cipher suites defined in this document make use of the
authenti=
cated encryption with additional data (AEAD) defined in TLS 1.2
<xref=
 target=3D"RFC5246"/> and DTLS 1.2 <xref target=3D"RFC=
6347" />.
Earlier versions of TLS do not have support for AEAD a=
nd consequently,
the cipher suites defined in this document MUST NOT be =
negotiated in TLS
versions prior to 1.2.=C2=A0 In addition, it is worth =
noting that TLS 1.0
<xref target=3D"RFC2246"/> and TL1.2=
 <xref target=3D"RFC4346"/> splits the
pre-master in two=
 parts. The PRF results of mixing the two pseudorandom
streams with dist=
inct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In=
 the case of ECDHE_PSK authentication, the PSK and
pre-master are treate=
d by distinct hash function with distinct
properties. This may introduce=
 vulnerabilities over the expected
security provided by the constructed =
pre-master. As such TLS 1.0 and
TLS 1.1 SHOULD NOT be used with ECDHE_PS=
K.</t>

<t>A client that offers the cipher suites from th=
is document in
ClientHello.cipher_suites in combination with (3,1) "=
;TLS 1.0" or (3,2)
"TLS 1.1" in ClientHello.client_versio=
n MUST support TLS 1.2 and MUST
accept the server to negotiate TLS 1.2 f=
or the current session.=C2=A0 If the
client does not support TLS 1.2 or =
is not willing to negotiate TLS 1.2,
then this client MUST NOT offer any=
 of these cipher suites with a lower
protocol version than (3,3) "T=
LS 1.2" in ClientHello.client_version.</t>

<t>A ser=
ver receiving a ClientHello and a client_version indicating
(3,1) "=
TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites fro=
m
this document in ClientHello.cipher_suites can safely assume that the<=
br>client supports TLS 1.2 and is willing to use it. The server MUST NOTnegotiate these cipher suites with TLS protocol versions earlier than
T=
LS 1.2. Not requiring clients to indicate their support for TLS 1.2
ciph=
er suites exclusively through ClientHello.client_hello improves the
inte=
roperability in the installed base and use of TLS 1.2 AEAD cipher
suites=
 without upsetting the installed base of version-intolerant TLS
servers,=
 results in more TLS handshakes succeeding and obviates fallback
mechani=
sms.</t>


On Fri, May 19, 2017 at 10:17 AM, Martin Rex &=
lt;mrex@sap.com> wrote:
Benjamin Ka=
duk wrote:

>

> Some other editorial nits follow.

>

> In section 4, "these cipher suites MUST N=
OT be negotiated in TLS

> versions prior to 1.2" should probably clarify that "these&q=
uot; cipher

> suites are the new ones specified by this document.





This reminds me of the specification goofs in several TLSv1.2-relate=
d

documents about AEAD cipher suites which are responsible for the viability<=
br>
of the POODLE attack and other exploitable fallback hacks.



It would be much preferable to avoid/fix those problems and facilitate

the migration to and use of TLSv1.2 without failing TLS handshakes and

band aids such as TLS_FALLBACK_SCSV





Suggested improvement:



=C2=A0 =C2=A0The cipher suites defined in this document make use of the

=C2=A0 =C2=A0authenticated encryption with additional data=
 (AEAD) defined in TLS

=C2=A0 =C2=A01.2 [RFC5246] and DTLS 1.2 [RFC6347].=C2=A0 Earlier ver=
sions of TLS do not

=C2=A0 =C2=A0have support for AEAD and consequently, these cipher suites MU=
ST NOT

-=C2=A0 be negotiated in TLS versions prior to 1.2.=C2=A0 Clients MUST NOT =
offer

-=C2=A0 these cipher suites if they do not offer TLS 1.2 or later.=C2=A0 Se=
rvers,

-=C2=A0 which select an earlier version of TLS MUST NOT select one of these=


-=C2=A0 cipher suites.=C2=A0 A client MUST treat the selection of these cip=
her

-=C2=A0 suites in combination with a version of TLS that does not support
-=C2=A0 AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
-=C2=A0 'illegal_parameter' TLS alert.

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0A client that offers

+=C2=A0 the cipher suites from this document in ClientHello.cipher_suites
+=C2=A0 in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.=
1" in

+=C2=A0 ClientHello.client_version MUST support TLSv1.2 and MUST accept

+=C2=A0 the server to negotiate TLSv1.2 for the current session.=C2=A0 If t=
he

+=C2=A0 client does not support TLSv1.2 or is not willing to negotiate TLSv=
1.2,

+=C2=A0 then this client MUST NOT offer any of these cipher suites with a
+=C2=A0 lower protocol version than (3,3) "TLSv1.2" in ClientHell=
o.client_version.

+=C2=A0 A server receiving a ClientHello and a client_version indicating
+=C2=A0 (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of t=
he cipher suites from

+=C2=A0 this document in ClientHello.cipher_suites can safely assume that t=
he

+=C2=A0 client supports TLSv1.2 and is willing to use it.=C2=A0 The server =
MUST

+=C2=A0 NOT negotiate these cipher suites with TLS protocol versions earlie=
r

+=C2=A0 than TLSv1.2.

+

+=C2=A0 Not requiring clients to indicate their support for TLSv1.2 cipher<=
br>
+=C2=A0 suites exclusively through ClientHello.client_hello improves the
+=C2=A0 interoperability in the installed base and use of TLSv1.2 AEAD

+=C2=A0 cipher suites without upsetting the installed base of version-intol=
erant

+=C2=A0 TLS servers, results in more TLS handshakes succeeding and obviates=


+=C2=A0 fallback mechanisms.





-Martin




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113c0cb2910d10054fe2f9e6--


From nobody Fri May 19 09:28:10 2017
Return-Path: 
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 61EFA129526; Fri, 19 May 2017 09:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 rUKWvGG-H7b0; Fri, 19 May 2017 09:27:34 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4E7129447; Fri, 19 May 2017 09:27:33 -0700 (PDT)
X-AuditID: 1209190d-fd7ff700000023f1-de-591f1cf45586
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B6.96.09201.4FC1F195; Fri, 19 May 2017 12:27:32 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v4JGRU5P007560; Fri, 19 May 2017 12:27:31 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4JGRPmR013013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2017 12:27:29 -0400
Date: Fri, 19 May 2017 11:27:25 -0500
From: Benjamin Kaduk 
To: Daniel Migault 
Cc: The IESG , secdir@ietf.org, draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls , "ietf@ietf.org" 
Message-ID: <20170519162725.GM39245@kduck.kaduk.org>
References: <20170519043827.GL39245@kduck.kaduk.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrftFRj7SYOEGZYsp0/ewWbxZtonJ YsaficwWzzbOZ7H4sPAhi8Wn812MDmwev75eZfNYsuQnUwBTFJdNSmpOZllqkb5dAlfGnOZP 7AVrHCtONW1gb2BsNeli5OSQEDCRON3/lgnEFhJYzCSxb7EnhL2RUeLXvPQuRi4g+yqTxNpf J1hAEiwCqhLzJh1hBLHZBFQkGrovM4PYIgIGEi8n7GQDsZkFFjBKzPltCGILC7hIrOhbAlbD C7Rs79zdUMuqJY5cmMgGEReUODnzCQtEr5bEjX8vgWo4gGxpieX/OEDCnAKBElM+zAdbKyqg LPH38D2WCYwCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTS TYzgUJbk3cH4767XIUYBDkYlHt6EX3KRQqyJZcWVuYcYJTmYlER5HQ8DhfiS8lMqMxKLM+KL SnNSiw8xSnAwK4nwMojKRwrxpiRWVqUW5cOkpDlYlMR5xTUaI4QE0hNLUrNTUwtSi2CyMhwc ShK8G6WBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGvwOp4S0uSMwtzkyHyJ9iVJQS5z0EkhAASWSU 5sH1glKNRPb+mleM4kCvCPOqAROPEA8wTcF1vwIazAQ0uPmBNMjgkkSElFQDY8GJ5y4qF7be uHe8Qtfk+Pfp166E8p07ey9CUC3v0OfjAr3Xdko82Ph5/2Y534mt9w46znyynOGxl/SUvs2t asd3yc4Q8ddVdUpd0LhJ+viBwxW7dv/zsJmrWLT7emSly/XMcOntIlW23G7ftfau3DSjKK7j 53L2oG0WvSIBP3fWRubOPVQR/FWJpTgj0VCLuag4EQBhJEK1EAMAAA==
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 16:27:36 -0000

On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:
> Hi Benjamin,
> 
> Thank you for the review. Please find my comments inline and let me know if
> you agree with the proposed text. I believe the only point not addressed
> concerns the addition of CCM-256 which has been remove after discussion
> during the WGLC.
> 
> Thanks you for the review,
> 
> Yours,
> Daniel
> 
> On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:
> 
> > Hi all,
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should
> > treat these comments just like any other last call comments.
> >
> > This document is ready with nits.
> >
> > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> > space, thought of as a cross product of key exchange and
> > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> > not quite this one.
> >
> > That said, it seems a little silly to only partially fill the gap
> > (by omitting the AES_256_CCM* cipher suites), even though there is
> > not currently demand for them.
> >
> > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and removed
> after  the WGLC. [0] The issue was whether or not introducing new ciphers
> not supported by TLS1.3. In 01, we though of adding the code point for
> TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
> the cipher suites proposed.In case of needs these could still be supported
> later by TLS1.3. The consensus seems to not introduce ciphers that would
> not be handled by TLS1.3. If the WG decides otherwise, these could still be
> added.
> 
> [0]
> https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007

That seems like a reasonable position for the WG to take, given how
close TLS 1.3 is to publication.  (It would also be reasonable to
define the full cross-product for TLS 1.2 only and have TLS 1.3 just
use a subset, but I have no real preference.)

> 
> > This document is just assembling pieces that were already specified
> > elsewhere, so it need not contain much detail itself, which is fine.
> > That said, I think section 3 should probably state explicitly which
> > pieces it uses, instead of a vague reference of being "based on RFC
> > 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> > computed in the same manner as for ECDHE_PSK key exchange in RFC
> > 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> > does not cover ECDHE_PSK.)
> >
> 
> MGLT: I agree we coudl be more explicit, here are the changes I propose. I
> believe it address your purpose.
> 
> OLD:
> 
> Messages and pre-master secret construction in this
> document are based on [RFC4279 ].
> 
> NEW:
> 
> Messages and pre-master secret construction in this
> document are defined in [RFC5489]. The ServerKeyExchange
> and ClientKeyExchange messages and premaster secret is
> computed as for  the ECDHE_PSK key exchange.

That basically works for me, though I'd tweak the phrasing slightly
for clarity/grammar:

NEW2:

Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages are used and the premaster secret is
computed as for the ECDHE_PSK key exchange.


> 
> > The premaster_secret structure so used basically ends up putting the
> > ECDH output first followed by the static PSK; with the pre-TLS 1.2
> > PRF, that would give the ECDH shared secret to md5 and the PSK to
> > sha1, which is perhaps another reason to not use these with pre-1.2
> > worth mentioning (in addition to the AEAD availability).
> >
> 
> MGLT: I believe the following text address your concern, however I am
> wondering if we are not going beyond the scope of expected considerations.

It perhaps is and perhaps is not worth mentioning, yes.

> In addition, it is worth noting that TLS1.0  and
> TL1.2  splits the premaster in two parts. The PRF
> results of mixing the two pseudorandom streams with distinct hash functions

"results of" is an unusual phrasing; "results from" might be more
familiar.

> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities over
> the expected security provided by the constructed pre-master. As such
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and not bother putting it in, if
you don't think it's useful.  (BTW, I think we are still TLS1.0 and
TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
NOT in the last sentence is not quite what is intended.)

> 
> > The security considerations largely refer to those of the other
> > documents providing the pieces that are combined together here;
> > those referenced security considerations sections are more than
> > adequate here, as this document itself does not really do anything
> > particularly novel.  That said, if we are going to reiterate the
> > entropy requirement for PSKs inline, we probably ought to also
> > reiterate the nonce-reuse considerations for GCM and CCM.  The
> > relevant constructions help, but there are still ways to mess up and
> > reuse a nonce when doing crypto in parallel, if I remember the
> > GCM/TLS document's security considerations correctly.
> >
> 
> MGLT: I believe the following text address your comments.
> 
>  GCM or CCM encryption - even of different clear text - re-using a
> nonce with a same key undermines the security of GCM and CCM. As a
> result, GCM and CCM MUST only be used with system guaranteeing nonce
> uniqueness .

Sure, sounds good.  (Grammar nit: "a system".)

> 
> >
> > Some other editorial nits follow.
> >
> 
> > In section 2, the RFC 7525 reference that "AEAD algorithms [...] are
> > strongly recommended" is scoped to just (D)TLS, so the text here
> > should probably also list that qualification.
> >
> 
> MGLT: I believe the following text address your concern:
> 
> OLD text:
> AEAD algorithms that combine encryption and integrity protection are
> strongly recommended for  and non-AEAD algorithms
> are forbidden to use in TLS 1.3 .
> 
> NEW text:
> AEAD algorithms that combine encryption and integrity protection are
> strongly recommended for (D)TLS  and non-AEAD
> algorithms
> are forbidden to use in TLS 1.3 .

Yes, thanks.

> > In section 4, "... make use of the authenticated encryption with
> > additional data (AEAD) defined in TLS 1.2" seems to make AEAD into
> > something of a unique object, as opposed to a class of things with
> > multiple possible instantiations.  I would consider something like
> > "... (AEAD) concept".
> >
> > In section 4, "these cipher suites MUST NOT be negotiated in TLS
> > versions prior to 1.2" should probably clarify that "these" cipher
> > suites are the new ones specified by this document.
> >
> > MGLT: I believe the following text address your comment:
> 
> OLD:
> these cipher suites MUST NOT be negotiated in TLS  versions prior to 1.2.
> 
> NEW:
> the cipher suites defined in this document MUST NOT be negotiated in TLS
> versions prior to 1.2.
> 
>  OLD:
> Clients MUST NOT offer these cipher suites
> 
> NEW:
> Clients MUST NOT offer these cipher suites defined in this document

I think I only intended to comment about the first one, but there is
no harm in changing both.  Thanks!


-Ben


From nobody Fri May 19 09:58:22 2017
Return-Path: 
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 159E2129526; Fri, 19 May 2017 09:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YEOmbOLhX0KY; Fri, 19 May 2017 09:58:10 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55ED71294F4; Fri, 19 May 2017 09:58:10 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id 99so4186874lfu.1; Fri, 19 May 2017 09:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+V2BlG7CJ4wjwDCI5HgOPAYPEgdbYUi0drEqepx0PpY=; b=GbUP8NcWDSRJL37PEG3lENkC5o5sqFJGz5ZU0eXFG5i8s9C62XHUXcsNn4cI5OxExJ d97SlGJZCfnO1zDzsb2sYcSN5dLE275JNb2lqCZlCn/tySN5g179k1vLBljS2uCXsTVX zye2rF35ktbC/jQefDZfaABSGc+8NYU6zmznNjcgksl5lIS98BCTXce6jlKic5Xvwt86 wkmTCDXO1yL0cUbu8HLwil0gNYSFV3f+TH1KPM5GtoGIAvclqGGdi6yemYTvshSnvPfX qLJ7DC2Idah65cy0/hRilitcHS+pdCuw5TbTuCl2/AgY3DWyAzggrKGRF9o858tUGMYi H9tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+V2BlG7CJ4wjwDCI5HgOPAYPEgdbYUi0drEqepx0PpY=; b=HuMMTwJAVABH1Z+DtlrYk6zFcbSZomBlIAxR1ttJlCewDJMllGbK7TUhfG8MrtfCxg wzpyaodv7AkbK3ZrZ4X6w5gDfcgzIpUgowQjB6sz/DfPlU2N2c9M3z+8loNrWjkQFlN5 q7/1+ytbt7cCskkF8ntE4vR/RqUdm/LHR/p1zu3pLpZxThTGzLThws1tz1GBDjIR074F zDmtBrsfr7yS4gUv/yfTadtL58IK2IYxOoe99YeUPVO+DG9f5D4L4zTm7VxwcR+fbBb+ 6VStK2xOt1C/UsaDuxSL5TSXuijlLqWpifSlWCq858zVmzRc8eM7l6WqibY5v+RdCsM2 YflQ==
X-Gm-Message-State: AODbwcBRxwpTAYFV+Ev4iFBYLfpwf0Ib7ogoYG6+SxRKfkTHhkqZ5m+V nlBtL/V+wskUu9dFnwGTp2SAikFITw==
X-Received: by 10.46.69.8 with SMTP id s8mr2564481lja.55.1495213088509; Fri, 19 May 2017 09:58:08 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Fri, 19 May 2017 09:58:07 -0700 (PDT)
In-Reply-To: <20170519162725.GM39245@kduck.kaduk.org>
References: <20170519043827.GL39245@kduck.kaduk.org>  <20170519162725.GM39245@kduck.kaduk.org>
From: Daniel Migault 
Date: Fri, 19 May 2017 12:58:07 -0400
X-Google-Sender-Auth: 1raqJXhaY3kI7429EhZs5caQhV8
Message-ID: 
To: Benjamin Kaduk 
Cc: tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org,  "ietf@ietf.org" , The IESG , secdir@ietf.org
Content-Type: multipart/alternative; boundary="001a114b07fe0114c9054fe36d55"
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 16:58:14 -0000

--001a114b07fe0114c9054fe36d55
Content-Type: text/plain; charset="UTF-8"

Thank you,

Your comments have all been addressed. I have one remaining clarification.
In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not
only for the cipher suites of the draft. In your opinion do we clarify
this, and should we use something else than SHOULD NOT ?

Thanks for the reviews!

Yours,
Daniel

> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities over
> the expected security provided by the constructed pre-master. As such
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and not bother putting it in, if
you don't think it's useful.  (BTW, I think we are still TLS1.0 and
TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
NOT in the last sentence is not quite what is intended.)

On Fri, May 19, 2017 at 12:27 PM, Benjamin Kaduk  wrote:

> On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:
> > Hi Benjamin,
> >
> > Thank you for the review. Please find my comments inline and let me know
> if
> > you agree with the proposed text. I believe the only point not addressed
> > concerns the addition of CCM-256 which has been remove after discussion
> > during the WGLC.
> >
> > Thanks you for the review,
> >
> > Yours,
> > Daniel
> >
> > On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:
> >
> > > Hi all,
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the
> > > IESG.  These comments were written primarily for the benefit of the
> > > security area directors.  Document editors and WG chairs should
> > > treat these comments just like any other last call comments.
> > >
> > > This document is ready with nits.
> > >
> > > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> > > space, thought of as a cross product of key exchange and
> > > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> > > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> > > not quite this one.
> > >
> > > That said, it seems a little silly to only partially fill the gap
> > > (by omitting the AES_256_CCM* cipher suites), even though there is
> > > not currently demand for them.
> > >
> > > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
> > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and
> removed
> > after  the WGLC. [0] The issue was whether or not introducing new ciphers
> > not supported by TLS1.3. In 01, we though of adding the code point for
> > TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
> > the cipher suites proposed.In case of needs these could still be
> supported
> > later by TLS1.3. The consensus seems to not introduce ciphers that would
> > not be handled by TLS1.3. If the WG decides otherwise, these could still
> be
> > added.
> >
> > [0]
> > https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?
> qid=6e4713be1d71bae6718c6e6e6c4b8007
>
> That seems like a reasonable position for the WG to take, given how
> close TLS 1.3 is to publication.  (It would also be reasonable to
> define the full cross-product for TLS 1.2 only and have TLS 1.3 just
> use a subset, but I have no real preference.)
>
> >
> > > This document is just assembling pieces that were already specified
> > > elsewhere, so it need not contain much detail itself, which is fine.
> > > That said, I think section 3 should probably state explicitly which
> > > pieces it uses, instead of a vague reference of being "based on RFC
> > > 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> > > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> > > computed in the same manner as for ECDHE_PSK key exchange in RFC
> > > 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> > > does not cover ECDHE_PSK.)
> > >
> >
> > MGLT: I agree we coudl be more explicit, here are the changes I propose.
> I
> > believe it address your purpose.
> >
> > OLD:
> >
> > Messages and pre-master secret construction in this
> > document are based on [RFC4279 ].
> >
> > NEW:
> >
> > Messages and pre-master secret construction in this
> > document are defined in [RFC5489]. The ServerKeyExchange
> > and ClientKeyExchange messages and premaster secret is
> > computed as for  the ECDHE_PSK key exchange.
>
> That basically works for me, though I'd tweak the phrasing slightly
> for clarity/grammar:
>
> NEW2:
>
> Messages and pre-master secret construction in this
> document are defined in [RFC5489]. The ServerKeyExchange
> and ClientKeyExchange messages are used and the premaster secret is
> computed as for the ECDHE_PSK key exchange.
>
>
> >
> > > The premaster_secret structure so used basically ends up putting the
> > > ECDH output first followed by the static PSK; with the pre-TLS 1.2
> > > PRF, that would give the ECDH shared secret to md5 and the PSK to
> > > sha1, which is perhaps another reason to not use these with pre-1.2
> > > worth mentioning (in addition to the AEAD availability).
> > >
> >
> > MGLT: I believe the following text address your concern, however I am
> > wondering if we are not going beyond the scope of expected
> considerations.
>
> It perhaps is and perhaps is not worth mentioning, yes.
>
> > In addition, it is worth noting that TLS1.0  and
> > TL1.2  splits the premaster in two parts. The PRF
> > results of mixing the two pseudorandom streams with distinct hash
> functions
>
> "results of" is an unusual phrasing; "results from" might be more
> familiar.
>
> > (MD5 and SHA-1) by exclusive-ORing them together. In the case of
> ECDHE_PSK
> > authentication, the PSK and pre-master are treated by distinct hash
> > function with distinct properties. This may introduce vulnerabilities
> over
> > the expected security provided by the constructed pre-master. As such
> > TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.
>
> The general tenor of this text addresses my concern, yes, but feel
> free to use editorial discretion and not bother putting it in, if
> you don't think it's useful.  (BTW, I think we are still TLS1.0 and
> TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
> NOT in the last sentence is not quite what is intended.)
>
> >
> > > The security considerations largely refer to those of the other
> > > documents providing the pieces that are combined together here;
> > > those referenced security considerations sections are more than
> > > adequate here, as this document itself does not really do anything
> > > particularly novel.  That said, if we are going to reiterate the
> > > entropy requirement for PSKs inline, we probably ought to also
> > > reiterate the nonce-reuse considerations for GCM and CCM.  The
> > > relevant constructions help, but there are still ways to mess up and
> > > reuse a nonce when doing crypto in parallel, if I remember the
> > > GCM/TLS document's security considerations correctly.
> > >
> >
> > MGLT: I believe the following text address your comments.
> >
> >  GCM or CCM encryption - even of different clear text - re-using a
> > nonce with a same key undermines the security of GCM and CCM. As a
> > result, GCM and CCM MUST only be used with system guaranteeing nonce
> > uniqueness .
>
> Sure, sounds good.  (Grammar nit: "a system".)
>
> >
> > >
> > > Some other editorial nits follow.
> > >
> >
> > > In section 2, the RFC 7525 reference that "AEAD algorithms [...] are
> > > strongly recommended" is scoped to just (D)TLS, so the text here
> > > should probably also list that qualification.
> > >
> >
> > MGLT: I believe the following text address your concern:
> >
> > OLD text:
> > AEAD algorithms that combine encryption and integrity protection are
> > strongly recommended for  and non-AEAD
> algorithms
> > are forbidden to use in TLS 1.3 .
> >
> > NEW text:
> > AEAD algorithms that combine encryption and integrity protection are
> > strongly recommended for (D)TLS  and non-AEAD
> > algorithms
> > are forbidden to use in TLS 1.3 .
>
> Yes, thanks.
>
> > > In section 4, "... make use of the authenticated encryption with
> > > additional data (AEAD) defined in TLS 1.2" seems to make AEAD into
> > > something of a unique object, as opposed to a class of things with
> > > multiple possible instantiations.  I would consider something like
> > > "... (AEAD) concept".
> > >
> > > In section 4, "these cipher suites MUST NOT be negotiated in TLS
> > > versions prior to 1.2" should probably clarify that "these" cipher
> > > suites are the new ones specified by this document.
> > >
> > > MGLT: I believe the following text address your comment:
> >
> > OLD:
> > these cipher suites MUST NOT be negotiated in TLS  versions prior to 1.2.
> >
> > NEW:
> > the cipher suites defined in this document MUST NOT be negotiated in TLS
> > versions prior to 1.2.
> >
> >  OLD:
> > Clients MUST NOT offer these cipher suites
> >
> > NEW:
> > Clients MUST NOT offer these cipher suites defined in this document
>
> I think I only intended to comment about the first one, but there is
> no harm in changing both.  Thanks!
>
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a114b07fe0114c9054fe36d55
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you, 

Your comments have=
 all been addressed. I have one remaining clarification. In my text the SHO=
ULD NOT was intended to the ECDHE_PSK in general, and not only for the ciph=
er suites of the draft. In your opinion do we clarify this, and should we u=
se something else than SHOULD NOT ?

Thanks for the review=
s!

Yours, 
Daniel

> (MD5 and SHA-1) by exclusive-ORing them together. In the case o=
f ECDHE_PSK

> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities =
over

> the expected security provided by the constructed pre-master. As such<=
br>
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.



The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and not bother putting it in, if

you don't think it's useful.=C2=A0 (BTW, I think we are still TLS1.=
0 and

TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD

NOT in the last sentence is not quite what is intended.)
<=
div class=3D"gmail_extra">
On Fri, May 19, 20=
17 at 12:27 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, May=
 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:

> Hi Benjamin,

>

> Thank you for the review. Please find my comments inline and let me kn=
ow if

> you agree with the proposed text. I believe the only point not address=
ed

> concerns the addition of CCM-256 which has been remove after discussio=
n

> during the WGLC.

>

> Thanks you for the review,

>

> Yours,

> Daniel

>

> On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:

>

> > Hi all,

> >

> > I have reviewed this document as part of the security directorate=
's

> > ongoing effort to review all IETF documents being processed by th=
e

> > IESG.=C2=A0 These comments were written primarily for the benefit=
 of the

> > security area directors.=C2=A0 Document editors and WG chairs sho=
uld

> > treat these comments just like any other last call comments.

> >

> > This document is ready with nits.

> >

> > Essentially, we are filling in a gap in the TLS (< 1.3) cipher=
suite

> > space, thought of as a cross product of key exchange and

> > cipher+mac/AEAD -- we have some of the combinations (PSK with ECD=
HE

> > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but=


> > not quite this one.

> >

> > That said, it seems a little silly to only partially fill the gap=


> > (by omitting the AES_256_CCM* cipher suites), even though there i=
s

> > not currently demand for them.

> >

> > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and

> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0 were mentioned in the=
 01 and removed

> after=C2=A0 the WGLC. [0] The issue was whether or not introducing new=
 ciphers

> not supported by TLS1.3. In 01, we though of adding the code point for=


> TLS1.2 and then specify that TLS1.3 was only implementing a **subset**=
 of

> the cipher suites proposed.In case of needs these could still be suppo=
rted

> later by TLS1.3. The consensus seems to not introduce ciphers that wou=
ld

> not be handled by TLS1.3. If the WG decides otherwise, these could sti=
ll be

> added.

>

> [0]

> https://mailarchive.ietf.org/arch/msg/tls/M442CwmUM=
xrYJR8FjCh3h-a69o4/?qid=3D6e4713be1d71bae6718c6e6e6c4b8007




That seems like a reasonable position for the WG to take, given=
 how

close TLS 1.3 is to publication.=C2=A0 (It would also be reasonable to

define the full cross-product for TLS 1.2 only and have TLS 1.3 just

use a subset, but I have no real preference.)



>

> > This document is just assembling pieces that were already specifi=
ed

> > elsewhere, so it need not contain much detail itself, which is fi=
ne.

> > That said, I think section 3 should probably state explicitly whi=
ch

> > pieces it uses, instead of a vague reference of being "based=
 on RFC

> > 4279".=C2=A0 So, "The ServerKeyExchange and ClientKeyEx=
change messages

> > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is=


> > computed in the same manner as for ECDHE_PSK key exchange in RFC<=
br>
> > 5489."=C2=A0 (I am not sure why RFC 4279 is cited in the cur=
rent text; it

> > does not cover ECDHE_PSK.)

> >

>

> MGLT: I agree we coudl be more explicit, here are the changes I propos=
e. I

> believe it address your purpose.

>

> OLD:

>

> Messages and pre-master secret construction in this

> document are based on [RFC4279 <https://tools.ietf=
.org/html/rfc4279>].

>

> NEW:

>

> Messages and pre-master secret construction in this

> document are defined in [RFC5489]. The ServerKeyExchange

> and ClientKeyExchange messages and premaster secret is

> computed as for=C2=A0 the ECDHE_PSK key exchange.



That basically works for me, though I'd tweak the phrasing sligh=
tly

for clarity/grammar:



NEW2:



Messages and pre-master secret construction in this

document are defined in [RFC5489]. The ServerKeyExchange

and ClientKeyExchange messages are used and the premaster secret is<=
br>
computed as for the ECDHE_PSK key exchange.





>

> > The premaster_secret structure so used basically ends up putting =
the

> > ECDH output first followed by the static PSK; with the pre-TLS 1.=
2

> > PRF, that would give the ECDH shared secret to md5 and the PSK to=


> > sha1, which is perhaps another reason to not use these with pre-1=
.2

> > worth mentioning (in addition to the AEAD availability).

> >

>

> MGLT: I believe the following text address your concern, however I am<=
br>
> wondering if we are not going beyond the scope of expected considerati=
ons.



It perhaps is and perhaps is not worth mentioning, yes.



> In addition, it is worth noting that TLS1.0 <xref target=3D"RF=
C2246"/> and

> TL1.2 <xref target=3D"RFC4346"/> splits the premaster =
in two parts. The PRF

> results of mixing the two pseudorandom streams with distinct hash func=
tions



"results of" is an unusual phrasing; "results from&qu=
ot; might be more

familiar.



> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE=
_PSK

> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities =
over

> the expected security provided by the constructed pre-master. As such<=
br>
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.



The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and not bother putting it in, if

you don't think it's useful.=C2=A0 (BTW, I think we are still TLS1.=
0 and

TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD

NOT in the last sentence is not quite what is intended.)



>

> > The security considerations largely refer to those of the other
> > documents providing the pieces that are combined together here;
> > those referenced security considerations sections are more than
> > adequate here, as this document itself does not really do anythin=
g

> > particularly novel.=C2=A0 That said, if we are going to reiterate=
 the

> > entropy requirement for PSKs inline, we probably ought to also
> > reiterate the nonce-reuse considerations for GCM and CCM.=C2=A0 T=
he

> > relevant constructions help, but there are still ways to mess up =
and

> > reuse a nonce when doing crypto in parallel, if I remember the
> > GCM/TLS document's security considerations correctly.

> >

>

> MGLT: I believe the following text address your comments.

>

>=C2=A0 <t>GCM or CCM encryption - even of different clear text - =
re-using a

> nonce with a same key undermines the security of GCM and CCM. As a

> result, GCM and CCM MUST only be used with system guaranteeing nonce
> uniqueness <xref target=3D"RFC5116"/>.</t>



Sure, sounds good.=C2=A0 (Grammar nit: "a system".)



>

> >

> > Some other editorial nits follow.

> >

>

> > In section 2, the RFC 7525 reference that=
 "AEAD algorithms [...] are

> > strongly recommended" is scoped to just (D)TLS, so the text =
here

> > should probably also list that qualification.

> >

>

> MGLT: I believe the following text address your concern:

>

> OLD text:

> <t>AEAD algorithms that combine encryption and integrity protect=
ion are

> strongly recommended for <xref target=3D"RFC7525" /> a=
nd non-AEAD algorithms

> are forbidden to use in TLS 1.3 <xref target=3D"I-D.ietf-tls-t=
ls13"/>.

>

> NEW text:

> <t>AEAD algorithms that combine encryption and integrity protect=
ion are

> strongly recommended for (D)TLS <xref target=3D"RFC7525" =
/> and non-AEAD

> algorithms

> are forbidden to use in TLS 1.3 <xref target=3D"I-D.ietf-tls-t=
ls13"/>.



Yes, thanks.



> > In section 4, "... make use of the authenticated encryption =
with

> > additional data (AEAD) defined in TLS 1.2" seems to make AEA=
D into

> > something of a unique object, as opposed to a class of things wit=
h

> > multiple possible instantiations.=C2=A0 I would consider somethin=
g like

> > "... (AEAD) concept".

> >

> > In section 4, "these cipher suites MUST NOT be negotiated in=
 TLS

> > versions prior to 1.2" should probably clarify that "th=
ese" cipher

> > suites are the new ones specified by this document.

> >

> > MGLT: I believe the following text address your comment:

>

> OLD:

> these cipher suites MUST NOT be negotiated in TLS=C2=A0 versions prior=
 to 1.2.

>

> NEW:

> the cipher suites defined in this document MUST NOT be negotiated in T=
LS

> versions prior to 1.2.

>

>=C2=A0 OLD:

> Clients MUST NOT offer these cipher suites

>

> NEW:

> Clients MUST NOT offer these cipher suites defined in this document


I think I only intended to comment about the first one, but there is=


no harm in changing both.=C2=A0 Thanks!






-Ben



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114b07fe0114c9054fe36d55--


From nobody Fri May 19 10:00:02 2017
Return-Path: 
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 1C67812955A for ; Fri, 19 May 2017 10:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 uCOTivrtacim for ; Fri, 19 May 2017 09:59:59 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE44112954E for ; Fri, 19 May 2017 09:59:58 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id b68so37504541ywe.3 for ; Fri, 19 May 2017 09:59:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MMNbUTor1Ci3ctM6BTavS9rqN88pI8bXZBmFT8VBO48=; b=SZwatnVBkIdp9AGGaPH18mB+hoWj+VWE75Yhkcl5pbWQOW9dEr6oGPrlqpk/lF7BR5 U0/J1o1aKWva4L2p5AYD2mokEeAcwYaZZunNrAF3Opkix8OrvJffZDJCc+hAqN1cDN0h VhuAMF4oXKjAvE4R0uwIENLiN9UK64eNWITxuSpFfCl6PKT3XM0mFtamkRBDj4vFTtZO 591kafqDRspR0QwQ8mQ1LzH0KwI0EvV9iMEmV2jbgVG3PsD0TMeNv8s7rsofcBIKzpZD DkuUHqPW1lYqa0FaHN/PTd27DSNy0xyFKAcqXXihM7jW7UVOwWCbF2xsgu4uf1lnXnI1 sB/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MMNbUTor1Ci3ctM6BTavS9rqN88pI8bXZBmFT8VBO48=; b=mPmUfH82F+xwIULysnbetmLw8WTMTk6hFths7fJccUSzk4/7WWHoXRXlS2S9UrEd05 m21kR+cqKlFQnbE8/+o0Ylzd+FJp1fIlVCro/V1nCb4pZLetR6Uzsl64lje/CIvEUuVO QyHfFKrlr2tiFSoybbZSX+X4KqE1LbdwmklSSkjKnN3cfigWhQbAL5o2oqO8EPE4rQtO q3EsKCbNN4gy7YkUICoNAHccSJx5O3So3mnHZ1fo967i3Adj9aenOQL4+4kF9aDL5GC7 1kciDVyaQO7qXVHSMnVcBNTlFrP00imAUeRGZ537zLF7Rx60p5vTLFl3NrRGSZq3nRDE RZXA==
X-Gm-Message-State: AODbwcCSEK2jyuSD5/udhueflfxJwzld4iavNovVtvsj4EtFvnPvXxhK Rg+cMfSL/YOxFgidfGlzGhKORrwWvzsG
X-Received: by 10.129.152.68 with SMTP id p65mr8697409ywg.1.1495213197983; Fri, 19 May 2017 09:59:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Fri, 19 May 2017 09:59:57 -0700 (PDT)
In-Reply-To: <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Fri, 19 May 2017 09:59:57 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: Eric Rescorla , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0ba6ca87b024054fe37378"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 17:00:01 -0000

--94eb2c0ba6ca87b024054fe37378
Content-Type: text/plain; charset="UTF-8"

On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara 
wrote:
>
> To me, that reads as gross understatement about the dangers involved in
> 0-RTT:
>
> - The side channel attacks with millions or billions of replays are hard
>   to protect against. This is if the side channels are in TLS library.
>   If not, protecting against that sort of side channels becomes
>   virtually impossible.

- Furthermore, with that kind of replay volume, protecting against DoS
>   attacks is virtually impossible.


> - Even if once-per-server or once-per-cluster replay detection limits
>   the number of replays to few hundred to few thoursand at maximum,
>   where the low-level crypto side channels are much less of a threat,
>   cache attacks can be used to break security (in fact, not sending a
>   mad burst of data to any one server is useful for carrying out these).
>

I wouldn't be too fatalistic about it. The speed of light is too slow for
human interaction, and 0-RTT is an important and awesome feature that we
should make safe and near universal.

Some protection is necessary; but it isn't too hard - a single-use session
cache, or a strike register, do protect against the side-channel and DOS
problems. Combined with a "fail closed" strategy and tickets that are
scoped to clusters or servers, these techniques do hard-stop the literal
0-RTT replays, and they are practical. Many of us run systems like that
already.


> Also, the kind of thing going on here seems exactly how I would imagine
> the past very bad decisions from TLS WG, that were known to be insecure
> at the time of specification and where then successfully attacked later,
> played out. However, I have not read those discussions from the ML
> archives.
>

In this case, I think people see the trade-offs differently and that's ok.
There's a sense that the risks or cost are worth it. After all, you can
mitigate a lot of the risk if you have a team of experts on standby who
manually mitigate these kinds of attacks, or more advanced automated
response systems. And many big providers do have both of these.

What concerns me most is that the 0-RTT interactions here are formalizable
and that the messaging interactions can be modeled in TLA+, F*, etc ... but
that hasn't been done as it has with the rest of the TLS1.3 state machine.

My TLA+ simple model convinced me that what's in the draft doesn't actually
work; there's nothing in the messages that allows a server to de-dupe, I
wrote up a simple 3-message example of this earlier in the thread, and it
seems to hold to the breaking the "X-" header trick that one provider came
up with.  That already in this draft deployment phase, that can advanced,
knowledgable, provider's attempt at a mitigation can be shown to be broken
should be cause for alarm. It's not a safe set-up.

Here's all I think we need to fix all of this though, in order of priority:

For relatively "Normal" clients (e.g. Browsers):

* Servers supporting 0-RTT need to robustly prevent replay of literal 0-RTT
sections. No time-based mitigation, which simply doesn't work. This is the
"cost" of doing 0-RTT.
* Clients should be the real arbiter of what to use 0-RTT; e.g. never use
for POST, etc. This could bear some emphasis. It's important because
middle-boxes exist.

For careful clients, think about something implementing a transaction over
TLS:

* If a 0-RTT section is sent but does not result in a successful receipt,
that failure needs to be signaled to the client.
* In order to fully reason about when that message may later get received,
there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all
potential middle-boxes in the pipe that may be using 0-RTT.

And then separate to all of the above, and lower priority:

* There's a contradiction between the obfuscated ticket age add parameter
and the desire to use tickets multiple times in other (non-0RTT) cases. We
can't do one without defeating the point of the other. Either remove the
obfuscation because it is misleading, or move it into an encrypted message
so that it is robust.

-- 
Colm

--94eb2c0ba6ca87b024054fe37378
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
To me, that reads as gros=
s understatement about the dangers involved in

0-RTT:



- The side channel attacks with millions or billions of replays are hard
=C2=A0 to protect against. This is if the side channels are in TLS library.=


=C2=A0 If not, protecting against that sort of side channels becomes

=C2=A0 virtually impossible.
- Furthermore, wi=
th that kind of replay volume, protecting against DoS
=C2=A0 attacks is =
virtually impossible.


- Even if once-per-server or once-per-cluster replay detection limits

=C2=A0 the number of replays to few hundred to few thoursand at maximum,
=C2=A0 where the low-level crypto side channels are much less of a threat,<=
br>
=C2=A0 cache attacks can be used to break security (in fact, not sending a<=
br>
=C2=A0 mad burst of data to any one server is useful for carrying out these=
).

I wouldn't be too fatalistic abo=
ut it. The speed of light is too slow for human interaction, and 0-RTT is a=
n important and awesome feature that we should make safe and near universal=
.=C2=A0

Some protection is necessary; but it isn&#=
39;t too hard - a single-use session cache, or a strike register, do protec=
t against the side-channel and DOS problems. Combined with a "fail clo=
sed" strategy and tickets that are scoped to clusters or servers, thes=
e techniques do hard-stop the literal 0-RTT replays, and they are practical=
. Many of us run systems like that already.=C2=A0
=C2=A0
Also, the kind of thing going on here seems exactly how I wou=
ld imagine

the past very bad decisions from TLS WG, that were known to be insecure

at the time of specification and where then successfully attacked later,
played out. However, I have not read those discussions from the ML

archives.

In this case, I think people =
see the trade-offs differently and that's ok. There's a sense that =
the risks or cost are worth it. After all, you can mitigate a lot of the ri=
sk if you have a team of experts on standby who manually mitigate these kin=
ds of attacks, or more advanced automated response systems. And many big pr=
oviders do have both of these.=C2=A0

What concerns=
 me most is that the 0-RTT interactions here are formalizable and that the =
messaging interactions can be modeled in TLA+, F*, etc ... but that hasn=
9;t been done as it has with the rest of the TLS1.3 state machine.=C2=A0
=C2=A0
My TLA+ simple model convinced me that what's =
in the draft doesn't actually work; there's nothing in the messages=
 that allows a server to de-dupe, I wrote up a simple 3-message example of =
this earlier in the thread, and it seems to hold to the breaking the "=
X-" header trick that one provider came up with.=C2=A0 That already in=
 this draft deployment phase, that can advanced, knowledgable, provider'=
;s attempt at a mitigation can be shown to be broken should be cause for al=
arm. It's not a safe set-up.=C2=A0

Here&=
#39;s all I think we need to fix all of this though, in order of priority:<=
/div>

For relatively "Normal" clients (e.g. Br=
owsers):

* Servers supporting 0-RTT need to robust=
ly prevent replay of literal 0-RTT sections. No time-based mitigation, whic=
h simply doesn't work. This is the "cost" of doing 0-RTT.=C2=
=A0
* Clients should be the real arbiter of what to use 0-RTT; e.=
g. never use for POST, etc. This could bear some emphasis. It's importa=
nt because middle-boxes exist.

For careful clients=
, think about something implementing a transaction over TLS:

=

* If a 0-RTT section is sent but does not result in a successful=
 receipt, that failure needs to be signaled to the client.
* In o=
rder to fully reason about when that message may later get received, there =
needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all potent=
ial middle-boxes in the pipe that may be using 0-RTT.=C2=A0

<=
/div>
And then separate to all of the above, and lower priority:
<=
div>
* There's a contradiction between the obfuscated tic=
ket age add parameter and the desire to use tickets multiple times in other=
 (non-0RTT) cases. We can't do one without defeating the point of the o=
ther. Either remove the obfuscation because it is misleading, or move it in=
to an encrypted message so that it is robust. =C2=A0

--=
 
Colm




--94eb2c0ba6ca87b024054fe37378--


From nobody Fri May 19 11:40:58 2017
Return-Path: 
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 8802A1273B1 for ; Fri, 19 May 2017 11:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 vEK5XStK0LUz for ; Fri, 19 May 2017 11:40:55 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D143E12946C for ; Fri, 19 May 2017 11:40:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 7AC8B601D7; Fri, 19 May 2017 21:40:52 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id etO2tBjBQHV4; Fri, 19 May 2017 21:40:51 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id DE91AC4; Fri, 19 May 2017 21:40:51 +0300 (EEST)
Date: Fri, 19 May 2017 21:40:51 +0300
From: Ilari Liusvaara 
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= 
Cc: Eric Rescorla , "tls@ietf.org" 
Message-ID: <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 18:40:57 -0000

On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
> On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara 
> wrote:
> >
> > - Even if once-per-server or once-per-cluster replay detection limits
> >   the number of replays to few hundred to few thoursand at maximum,
> >   where the low-level crypto side channels are much less of a threat,
> >   cache attacks can be used to break security (in fact, not sending a
> >   mad burst of data to any one server is useful for carrying out these).
> >
> 
> I wouldn't be too fatalistic about it. The speed of light is too slow for
> human interaction, and 0-RTT is an important and awesome feature that we
> should make safe and near universal.
> 
> Some protection is necessary; but it isn't too hard - a single-use session
> cache, or a strike register, do protect against the side-channel and DOS
> problems. Combined with a "fail closed" strategy and tickets that are
> scoped to clusters or servers, these techniques do hard-stop the literal
> 0-RTT replays, and they are practical. Many of us run systems like that
> already.

Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
even with distributed servers for the origin.

Of course, this impiles that there is some small-enough spatial scope
for 0-RTT, so servers in scope can reach global consistency in acceptable
time (which also sets the server timeout!)

Latencies within a single datacenter should be pretty low, and routing
should be pretty sticky between datacenters.

> Here's all I think we need to fix all of this though, in order of priority:
> 
> For relatively "Normal" clients (e.g. Browsers):
> 
> * Servers supporting 0-RTT need to robustly prevent replay of literal 0-RTT
> sections. No time-based mitigation, which simply doesn't work. This is the
> "cost" of doing 0-RTT.
> * Clients should be the real arbiter of what to use 0-RTT; e.g. never use
> for POST, etc. This could bear some emphasis. It's important because
> middle-boxes exist.

Yeah, for clients that are as careless with HTTP as browsers, sending
POSTs in 0-RTT data is very bad idea.
 
> For careful clients, think about something implementing a transaction over
> TLS:
> 
> * If a 0-RTT section is sent but does not result in a successful receipt,
> that failure needs to be signaled to the client.

This is already required in order to implement HTTP semantics. E.g. so
that if 0-RTT section contains POST request, the HTTP library can signal
its client "failed: connection to server lost before reply was
received" (and retry GETs, PUTs and DEETEs).

> * In order to fully reason about when that message may later get received,
> there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all
> potential middle-boxes in the pipe that may be using 0-RTT.

Isn't that potentially multi-party problem if middleboxes are involved?


> And then separate to all of the above, and lower priority:
> 
> * There's a contradiction between the obfuscated ticket age add parameter
> and the desire to use tickets multiple times in other (non-0RTT) cases. We
> can't do one without defeating the point of the other. Either remove the
> obfuscation because it is misleading, or move it into an encrypted message
> so that it is robust.

The purpose of obfustication is not to hide sibling sessions. The
client already blows its cover by using the same session ID twice. The
purpose of obfustication is to hide the parent session.

Are you talking about attackers being able to determine the rate of
client clock?


-Ilari


From nobody Fri May 19 11:45:16 2017
Return-Path: 
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 513651292CE for ; Fri, 19 May 2017 11:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 aVgHGmeP4rQv for ; Fri, 19 May 2017 11:45:13 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E51D1273B1 for ; Fri, 19 May 2017 11:45:13 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id l74so38719696ywe.2 for ; Fri, 19 May 2017 11:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u/NxhEV2UJKKlpB5E8n1+GiiVAztbwYGmBHttO6gMGU=; b=rzO5Owv8+12JJ8hOaJGmf190xpNRxeQ5bf2SJR+cjCQSn1SioEqnTJGUhGxF/mcyQU ekg8h+Jq2JCHNEjLnJlZau8sY1bEGQXyUCOrCi2LgdNyj7W20raMVRV9XUDnI1FVz05D Vw7Bwm6la/pHtsBHzIkw0LrvkK1s7jeYigXc5EQlpVA8/0lejcnh/CTY6t6dZ0kGrKCH 0Rz38Mxd+BzkYHrAbUW8Q78oJsfcXiXFE09gEYpg8euwZsF9OqHNNkCglX8YdKz5y4gS GoruBETXtfxjEXgeBKjnOpZRV9aZk+7uOvtkVH/+jusLbxFMn/0VRSYlRv0Sn/3nqSkY RoKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u/NxhEV2UJKKlpB5E8n1+GiiVAztbwYGmBHttO6gMGU=; b=ZmqmMQnDMxzID6ZNZNvaIm/DEzwF+RqV3oKB1/D+MlXul0jtVnGoodx4tpVfPwLBW4 8hr5E4/mN5XyNtN/wq+844fOlfyHZER07pTPYjhHW4QkFo+aZkIsAgF5VfqZ5mgpVdMo 0n9BXuzHFyeU/spBeGpIIdH7O4XU5DlNLDgc+XIen6JDuGB6uqdjqlowKqhoctxVwryK aysEI/ax+/XPaf6zbk5lLQDcdu6TZb2jFlIrPIIw1if3eGskJVobWw/IZPCyhcKG6odA ChVNp70CCsyC+HEOj1kGl3dgBpnoh027cP+JBJGqW3II75QR1Ikfm4ByyB+oYFr0VBbb TcJw==
X-Gm-Message-State: AODbwcDuL+cWqR6xsnsNkBOH3F0ywwdWymUPLnsHh80aypVpFdo99ZyS RtJl1ykuIWpxNbVjGIcKk/2XAHUhKfx5
X-Received: by 10.129.85.83 with SMTP id j80mr9021390ywb.283.1495219512867; Fri, 19 May 2017 11:45:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Fri, 19 May 2017 11:44:32 -0700 (PDT)
In-Reply-To: <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Fri, 19 May 2017 14:44:32 -0400
Message-ID: 
To: Ilari Liusvaara 
Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f3cbeed3f82054fe4eb8c"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 18:45:15 -0000

--001a113f3cbeed3f82054fe4eb8c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara 
wrote:

> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacC=C3=A1rthaigh wrote:
> > On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> > >
> > > - Even if once-per-server or once-per-cluster replay detection limits
> > >   the number of replays to few hundred to few thoursand at maximum,
> > >   where the low-level crypto side channels are much less of a threat,
> > >   cache attacks can be used to break security (in fact, not sending a
> > >   mad burst of data to any one server is useful for carrying out
> these).
> > >
> >
> > I wouldn't be too fatalistic about it. The speed of light is too slow f=
or
> > human interaction, and 0-RTT is an important and awesome feature that w=
e
> > should make safe and near universal.
> >
> > Some protection is necessary; but it isn't too hard - a single-use
> session
> > cache, or a strike register, do protect against the side-channel and DO=
S
> > problems. Combined with a "fail closed" strategy and tickets that are
> > scoped to clusters or servers, these techniques do hard-stop the litera=
l
> > 0-RTT replays, and they are practical. Many of us run systems like that
> > already.
>
> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
> even with distributed servers for the origin.
>

I don't disagree with that necessarily, but if the client responds by
retransmitting
in 1-RTT, then you don't have overall at-most-once.

-Ekr



>
> Of course, this impiles that there is some small-enough spatial scope
> for 0-RTT, so servers in scope can reach global consistency in acceptable
> time (which also sets the server timeout!)
>
> Latencies within a single datacenter should be pretty low, and routing
> should be pretty sticky between datacenters.
>
> > Here's all I think we need to fix all of this though, in order of
> priority:
> >
> > For relatively "Normal" clients (e.g. Browsers):
> >
> > * Servers supporting 0-RTT need to robustly prevent replay of literal
> 0-RTT
> > sections. No time-based mitigation, which simply doesn't work. This is
> the
> > "cost" of doing 0-RTT.
> > * Clients should be the real arbiter of what to use 0-RTT; e.g. never u=
se
> > for POST, etc. This could bear some emphasis. It's important because
> > middle-boxes exist.
>
> Yeah, for clients that are as careless with HTTP as browsers, sending
> POSTs in 0-RTT data is very bad idea.
>
> > For careful clients, think about something implementing a transaction
> over
> > TLS:
> >
> > * If a 0-RTT section is sent but does not result in a successful receip=
t,
> > that failure needs to be signaled to the client.
>
> This is already required in order to implement HTTP semantics. E.g. so
> that if 0-RTT section contains POST request, the HTTP library can signal
> its client "failed: connection to server lost before reply was
> received" (and retry GETs, PUTs and DEETEs).
>
> > * In order to fully reason about when that message may later get
> received,
> > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> all
> > potential middle-boxes in the pipe that may be using 0-RTT.
>
> Isn't that potentially multi-party problem if middleboxes are involved?
>
>
> > And then separate to all of the above, and lower priority:
> >
> > * There's a contradiction between the obfuscated ticket age add paramet=
er
> > and the desire to use tickets multiple times in other (non-0RTT) cases.
> We
> > can't do one without defeating the point of the other. Either remove th=
e
> > obfuscation because it is misleading, or move it into an encrypted
> message
> > so that it is robust.
>
> The purpose of obfustication is not to hide sibling sessions. The
> client already blows its cover by using the same session ID twice. The
> purpose of obfustication is to hide the parent session.
>
> Are you talking about attackers being able to determine the rate of
> client clock?
>
>
> -Ilari
>

--001a113f3cbeed3f82054fe4eb8c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacC=C3=A1rthaigh =
wrote:

> On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <ilariliusvaara@welho.com>

> wrote:

> >

> > - Even if once-per-server or once-per-clu=
ster replay detection limits

> >=C2=A0 =C2=A0the number of replays to few hundred to few thoursand=
 at maximum,

> >=C2=A0 =C2=A0where the low-level crypto side channels are much les=
s of a threat,

> >=C2=A0 =C2=A0cache attacks can be used to break security (in fact,=
 not sending a

> >=C2=A0 =C2=A0mad burst of data to any one server is useful for car=
rying out these).

> >

>

> I wouldn't be too fatalistic about it. The speed of light is too s=
low for

> human interaction, and 0-RTT is an important and awesome feature that =
we

> should make safe and near universal.

>

> Some protection is necessary; but it isn't too hard - a single-use=
 session

> cache, or a strike register, do protect against the side-channel and D=
OS

> problems. Combined with a "fail closed" strategy and tickets=
 that are

> scoped to clusters or servers, these techniques do hard-stop the liter=
al

> 0-RTT replays, and they are practical. Many of us run systems like tha=
t

> already.



Yup. There are no known reasons that prevent at-most-once 0-RTT deli=
very,

even with distributed servers for the origin.

I don't disagree with that necessarily, but if the client respon=
ds by retransmitting
in 1-RTT, then you don't have overall at=
-most-once.

-Ekr

=C2=A0



Of course, this impiles that there is some small-enough spatial scope

for 0-RTT, so servers in scope can reach global consistency in acceptable
time (which also sets the server timeout!)



Latencies within a single datacenter should be pretty low, and routing

should be pretty sticky between datacenters.



> Here's all I think we need to fix all of this though, in order of =
priority:

>

> For relatively "Normal" clients (e.g. Browsers):

>

> * Servers supporting 0-RTT need to robustly prevent replay of literal =
0-RTT

> sections. No time-based mitigation, which simply doesn't work. Thi=
s is the

> "cost" of doing 0-RTT.

> * Clients should be the real arbiter of what to use 0-RTT; e.g. never =
use

> for POST, etc. This could bear some emphasis. It's important becau=
se

> middle-boxes exist.



Yeah, for clients that are as careless with HTTP as browsers, sendin=
g

POSTs in 0-RTT data is very bad idea.



> For careful clients, think about something implementing a transaction =
over

> TLS:

>

> * If a 0-RTT section is sent but does not result in a successful recei=
pt,

> that failure needs to be signaled to the client.



This is already required in order to implement HTTP semantics. E.g. =
so

that if 0-RTT section contains POST request, the HTTP library can signal
its client "failed: connection to server lost before reply was

received" (and retry GETs, PUTs and DEETEs).



> * In order to fully reason about when that message may later get recei=
ved,

> there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by=
 all

> potential middle-boxes in the pipe that may be using 0-RTT.



Isn't that potentially multi-party problem if middleboxes are in=
volved?





> And then separate to all of the above, and lower priority:

>

> * There's a contradiction between the obfuscated ticket age add pa=
rameter

> and the desire to use tickets multiple times in other (non-0RTT) cases=
. We

> can't do one without defeating the point of the other. Either remo=
ve the

> obfuscation because it is misleading, or move it into an encrypted mes=
sage

> so that it is robust.



The purpose of obfustication is not to hide sibling sessions. The
client already blows its cover by using the same session ID twice. The

purpose of obfustication is to hide the parent session.



Are you talking about attackers being able to determine the rate of

client clock?





-Ilari





--001a113f3cbeed3f82054fe4eb8c--


From nobody Fri May 19 13:02:54 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBE6129B05; Fri, 19 May 2017 13:02:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149522417301.23956.5128200733750772268@ietfa.amsl.com>
Date: Fri, 19 May 2017 13:02:53 -0700
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-04.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 19 May 2017 20:02:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)
        Authors         : John Mattsson
                          Daniel Migault
	Filename        : draft-ietf-tls-ecdhe-psk-aead-04.txt
	Pages           : 8
	Date            : 2017-05-19

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol.  The cipher suites are all based on
   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
   (ECDHE_PSK) key exchange together with the Authenticated Encryption
   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
   provides light and efficient authentication, ECDHE provides forward
   secrecy, and AES-GCM and AES-CCM provides encryption and integrity
   protection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri May 19 13:10:34 2017
Return-Path: 
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 93C74129AB6 for ; Fri, 19 May 2017 13:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 iq019IRf3oMY for ; Fri, 19 May 2017 13:10:31 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DCB127867 for ; Fri, 19 May 2017 13:10:31 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id p73so28988293ywp.0 for ; Fri, 19 May 2017 13:10:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G/We2CXvLDEwa/pWnCZn7P9kZJDzk5iyFntAoDImjMY=; b=AMQpW1N6luh0mtgBMqXN0APi8W4QXZiOXktYfrSfMsw3frPgwmjPiuiSY5jYQN9jOm tjcvNA1290AE+DisTuR4snv339piLPjyH4aRM7k+8v6g7mSliP4CzJ6QB6D1k2f9B5w2 V0xQlewqdjlDj4g3GgmU+2BamItVddP6H7Y9YDd2Keoa657+V3r0hqL7scMDAnCPi/ZH TAgkf0Kk/jgJ6CW8I0Em3M+HFs1D+NAh8KbkAFl4r1b3iJpd0irHPHrbuptSxvKYLyDQ Pe1Rw+M7tDo9SOhjZwqjEd5vuNjjcR+WvJyt7rm+Jdgv6/bONST1wVR8pMqXLdVNynCN q/Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G/We2CXvLDEwa/pWnCZn7P9kZJDzk5iyFntAoDImjMY=; b=WcijNaW0fdoItkIyW7p09ku5rixgMSKv7ng93Tvd1CxYzlz9qeb3/TvKorUQLGFfEE prqrNHKAoLyccTheZx6Mp/b2kOxOrRYyht1/ESwkXnHeF3B+0QOB7OO8DMgj1+U5RaFq 8vTymDACz5QEwhTXN1fbx+Yg06fX13j08G4Cj/BwYSqEYi07TkEaYBLsmgfWa4Cg6Eiw GMxg8L8yyB/hTxQGwrQ5jSNQs4VO8OQZLn5giL4WMLUwG3+3rGss0xhdp03Ht0BfyGrz 4KOUNItEkm4aLHdcQtI0BVzSKdvATMwQ1ronLhFzH0a7/J52v8ndo0xx9U2VQwIIr9Of jwSg==
X-Gm-Message-State: AODbwcBfpqmlfJ0G3ilX5gHOryAQeplsmn1eEC2VULqso1Qo8cuXU1To aaMdoSjZp1qpjk1MzVe1ukqV4vBxrtHF
X-Received: by 10.129.152.68 with SMTP id p65mr9312498ywg.1.1495224630437; Fri, 19 May 2017 13:10:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Fri, 19 May 2017 13:10:29 -0700 (PDT)
In-Reply-To: <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Fri, 19 May 2017 13:10:29 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: Eric Rescorla , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0ba6caf50b36054fe61c47"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 20:10:32 -0000

--94eb2c0ba6caf50b36054fe61c47
Content-Type: text/plain; charset="UTF-8"

On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara 
wrote:

> > * In order to fully reason about when that message may later get
> received,
> > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> all
> > potential middle-boxes in the pipe that may be using 0-RTT.
>
> Isn't that potentially multi-party problem if middleboxes are involved?
>

Yes; but if we can agree on a hard maximum time-window for the 0RTT
section, and all of the parties agree, it's possible for a careful client
to negotiate its way around it. Even if it's 10 seconds, this still has
some value I think.


> > And then separate to all of the above, and lower priority:
> >
> > * There's a contradiction between the obfuscated ticket age add parameter
> > and the desire to use tickets multiple times in other (non-0RTT) cases.
> We
> > can't do one without defeating the point of the other. Either remove the
> > obfuscation because it is misleading, or move it into an encrypted
> message
> > so that it is robust.
>
> The purpose of obfustication is not to hide sibling sessions. The
> client already blows its cover by using the same session ID twice. The
> purpose of obfustication is to hide the parent session.


> Are you talking about attackers being able to determine the rate of
> client clock?
>

Right now if a ticket is used multiple times, then the ticket age can be
derived (trivial cryptanalysis due to re-using the same obfuscated offset,
and because the progression of time between the ticket uses is public);
that means the parent session can be identified. So the point is defeated.

Either the one-time-pad can be used just one time (which means the ticket
can be used just once) or we should move it to an encrypted message. Or
just get rid of it and not be so misleading. But the current state is
weird, to say the least.

-- 
Colm

--94eb2c0ba6caf50b36054fe61c47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> * In order to fully reason about when that message may later get re=
ceived,

> there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by=
 all

> potential middle-boxes in the pipe that may be using 0-RTT.



Isn't that potentially multi-party problem if middleboxes are in=
volved?

Yes; but if we can agree on a h=
ard maximum time-window for the 0RTT section, and all of the parties agree,=
 it's possible for a careful client to negotiate its way around it. Eve=
n if it's 10 seconds, this still has some value I think.=C2=A0
=C2=A0

> And then separate to all of the above, and lower priority:

>

> * There's a contradiction between the obfuscated ticket age add pa=
rameter

> and the desire to use tickets multiple times in other (non-0RTT) cases=
. We

> can't do one without defeating the point of the other. Either remo=
ve the

> obfuscation because it is misleading, or move it into an encrypted mes=
sage

> so that it is robust.



The purpose of obfustication is not to hide sibling sessions. The
client already blows its cover by using the same session ID twice. The

purpose of obfustication is to hide the parent session.=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


Are you talking about attackers being able to determine the rate of

client clock?

Right now if a ticket is =
used multiple times, then the ticket age can be derived (trivial cryptanaly=
sis due to re-using the same obfuscated offset, and because the progression=
 of time between the ticket uses is public); that means the parent session =
can be identified. So the point is defeated.=C2=A0

Either the one-time-pad can be used just one time (which means the ticket =
can be used just once) or we should move it to an encrypted message. Or jus=
t get rid of it and not be so misleading. But the current state is weird, t=
o say the least.=C2=A0

-- 
Colm




--94eb2c0ba6caf50b36054fe61c47--


From nobody Fri May 19 13:18:11 2017
Return-Path: 
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 916EA1296B3; Fri, 19 May 2017 13:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 cRLqjpH99LDE; Fri, 19 May 2017 13:18:08 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5C6129601; Fri, 19 May 2017 13:18:07 -0700 (PDT)
X-AuditID: c6180641-379ff700000037f2-56-591f0c9ea9ca
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id A7.5C.14322.E9C0F195; Fri, 19 May 2017 17:17:53 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Fri, 19 May 2017 16:18:03 -0400
From: Daniel Migault 
To: "tls@ietf.org" 
CC: tls-chairs , Kathleen Moriarty , Eric Rescorla 
Thread-Topic: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
Thread-Index: AQHS0NrpVSJ41Ryl70qjrVxUdZ5LmKH8E36w
Date: Fri, 19 May 2017 20:18:03 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDBB01@eusaamb107.ericsson.se>
References: <149522417333.23956.7024977757521677892.idtracker@ietfa.amsl.com>
In-Reply-To: <149522417333.23956.7024977757521677892.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPgu5CHvlIg807DSxWvD7HbtGwM99i zokbLBafzncxOrB47Jx1l91jyZKfTB6TH7cxBzBHcdmkpOZklqUW6dslcGW8P/OWvaBLoeLb 28vMDYwL5LsYOTgkBEwkJl4W7mLk5BASOMooseNRdhcjF5C9nFHi4e3FbCAJNgEjibZD/ewg toiAosSOq91gNrNAlcSxZ8uZQWxhgQCJJ3f2MkHUBEpMWnsbyjaSeLOljRXEZhFQlZi38jAL iM0r4Ctx4OkiVpAbhIDsxQctQcKcAn4STZMXMYLYjAJiEt9PrWGCWCUucevJfDBbQkBAYsme 88wQtqjEy8f/WCFsJYmPv+ezg4xkFtCUWL9LH6JVUWJK90N2iK2CEidnPmGZwCg6C8nUWQgd s5B0zELSsYCRZRUjR2lxQU5uupHhJkZghByTYHPcwbi31/MQowAHoxIPryGnfKQQa2JZcWXu IUYJDmYlEd7FAUAh3pTEyqrUovz4otKc1OJDjNIcLErivO/KL0QICaQnlqRmp6YWpBbBZJk4 OKUaGL0WXbfqy3aq3LI/ZLtL8eZJdTEzeFZriLcfWDPvR8ncB8sTHx241fZv2aYtrpf+ztSS 9RVvdz98XZd10cppJ/sUi+Y85C9p9Fj/94eNqu18s69cU/X/3fY69K/lSVRlOl/VE3shdTvN ypUPTM4dOb5kvcayTSctOYKmaBtu+Xbk6skjGzyWK6xQYinOSDTUYi4qTgQAyzsEC4wCAAA=
Archived-At: 
Subject: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 20:18:10 -0000

SGksIA0KDQpUaGFuayB5b3UgdG8gYWxsIHJldmlld2VycyBmb3IgdGhlaXIgZmVlZCBiYWNrcy4g
UGxlYXNlIGZpbmQgdGhlIGxhdGVzdCB2ZXJzaW9uLCB3aGljaCBhcyBmYXIgYXMgSSBrbm93IGlu
Y2x1ZGVzIGFsbCBjb21tZW50cy4gQ29tbWVudHMgd2VyZSBub3QgY29udHJvdmVyc2lhbC4gSW4g
b3JkZXIgdG8gcmFpc2UgbmV4dCByZXZpZXdzIEkgYW0gcmFpc2luZyBhc3BlY3RzIHRoYXQgbWln
aHQgbmVlZCBhIGJpdCBtb3JlIGF0dGVudGlvbi4gIA0KDQoxKSAgVGhlIGN1cnJlbnQgZG9jdW1l
bnQgbWVudGlvbnMgSS1ELmlldGYtdGxzLXJmYzQ0OTJiaXMgYW5kIEktRC5pZXRmLXRscy10bHMx
MyBhcyBub3JtYXRpdmUuIFdlIGNhbiB3YWl0IGZvciB0aGVzZSBkb2N1bWVudHMgdG8gYmVjb21l
IFJGQ3MsIGJ1dCB3ZSBjYW4gYWxzbyBkb3dyZWYgdGhlbSB0byBpbmZvcm1hdGlvbmFsIHJlZmVy
ZW5jZSBpZiB3ZSB3YW50IHRvIG1vdmUgdGhhdCBkb2N1bWVudCBmb3J3YXJkLiBJIHdpbGwgbGVh
dmUgdGhlIEFEIHRvIGRlY2lkZSwgYW5kIGNoYW5nZXMgaWYgbmVlZGVkIGNhbiBiZSBkb25lIGJ5
IHRoZSBSRkMgLWVkaXRvcg0KDQoyKSAgU2VjdGlvbiA0IGhhcyB0aGUgZm9sbG93aW5nIHRleHQ6
DQoNCiIiIkluIHRoZSBjYXNlIG9mIEVDREhFX1BTSyBhdXRoZW50aWNhdGlvbiwgdGhlIFBTSyBh
bmQgcHJlLW1hc3RlciBhcmUgdHJlYXRlZCBieSBkaXN0aW5jdCBoYXNoIGZ1bmN0aW9uIHdpdGgg
ZGlzdGluY3QgcHJvcGVydGllcy4gIFRoaXMgbWF5IGludHJvZHVjZSB2dWxuZXJhYmlsaXRpZXMg
b3ZlciB0aGUgZXhwZWN0ZWQgc2VjdXJpdHkgcHJvdmlkZWQgYnkgdGhlIGNvbnN0cnVjdGVkIHBy
ZS1tYXN0ZXIuIEFzIHN1Y2ggVExTIDEuMCBhbmQgVExTIDEuMSBzaG91bGQgbm90IGJlICB1c2Vk
IHdpdGggRUNESEVfUFNLLiAiIiINCg0KV2l0aCBFRENIRV9QU0sgYmVpbmcgdGhlIEVDREhFIFBT
SyBtZXRob2Qgbm90IHJlc3RyaWN0ZWQgdG8gdGhlIGNpcGhlciBzdWl0ZXMgZGVmaW5lZCBpbiB0
aGUgZG9jdW1lbnQuICBJIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUgd2UgYXJlIG9rIHdpdGggdGhl
IGxhc3Qgc2VudGVuY2UuIA0KDQpZb3VycywgDQpEYW5pZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE1heSAxOSwgMjAxNyA0OjAzIFBNDQpU
bzogSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+OyBEYW5pZWwgTWln
YXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPjsgdGxzLWNoYWlyc0BpZXRmLm9yZw0K
U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRscy1lY2Ro
ZS1wc2stYWVhZC0wNC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi10
bHMtZWNkaGUtcHNrLWFlYWQtMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk
IGJ5IERhbmllbCBNaWdhdWx0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K
TmFtZToJCWRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkDQpSZXZpc2lvbjoJMDQNClRpdGxl
OgkJRUNESEVfUFNLIHdpdGggQUVTLUdDTSBhbmQgQUVTLUNDTSBDaXBoZXIgU3VpdGVzIGZvciBU
cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykNCkRvY3VtZW50IGRhdGU6CTIwMTctMDUtMTgN
Ckdyb3VwOgkJdGxzDQpQYWdlczoJCTgNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQtMDQudHh0
DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
aWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLTA0DQpIdG1saXplZDog
ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRs
cy1lY2RoZS1wc2stYWVhZC0wNA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn
L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wNA0KDQpBYnN0cmFj
dDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZv
ciB0aGUgVHJhbnNwb3J0DQogICBMYXllciBTZWN1cml0eSAoVExTKSBwcm90b2NvbC4gIFRoZSBj
aXBoZXIgc3VpdGVzIGFyZSBhbGwgYmFzZWQgb24NCiAgIHRoZSBFcGhlbWVyYWwgRWxsaXB0aWMg
Q3VydmUgRGlmZmllLUhlbGxtYW4gd2l0aCBQcmUtU2hhcmVkIEtleQ0KICAgKEVDREhFX1BTSykg
a2V5IGV4Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0K
ICAgd2l0aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpIGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVT
LUNDTS4gIFBTSw0KICAgcHJvdmlkZXMgbGlnaHQgYW5kIGVmZmljaWVudCBhdXRoZW50aWNhdGlv
biwgRUNESEUgcHJvdmlkZXMgZm9yd2FyZA0KICAgc2VjcmVjeSwgYW5kIEFFUy1HQ00gYW5kIEFF
Uy1DQ00gcHJvdmlkZXMgZW5jcnlwdGlvbiBhbmQgaW50ZWdyaXR5DQogICBwcm90ZWN0aW9uLg0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg
dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp
bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll
dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Fri May 19 13:18:34 2017
Return-Path: 
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 9A87312945A for ; Fri, 19 May 2017 13:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level: 
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 JVH-l0CoMGHP for ; Fri, 19 May 2017 13:18:31 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCE5124BFA for ; Fri, 19 May 2017 13:18:30 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id l14so39739456ywk.1 for ; Fri, 19 May 2017 13:18:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/96ZD0HZAe7UH1q+dTszIRABA+9Mbd9yT4HIwW5saBo=; b=AevEvDGe+sesn+8xl3o4doXWWpoV1urynduvqE+aC+FaDPhtLbu/BYrbSrFiZ1gqcK kMfOJxI27vhPVDszXrWuHJSueLA9BW+cVFj/D5A/vJyq/4ojo2YQk1VNSsBCjlqv8qk6 Vl9+olJ5SaHbscyK2ng7NlYgEh2fRMRIFzTGZ251r7Vheb6VAmAi5Yjygu9xOzxoedIi Bloql3wvTxEQ7dcM5aA5PVvBuqCmnkr0zWVjjifKulVjyEoklzJA7LTytrLty1gR1RNz qNXzw2Rd4+CCv1yhE+e1O3/FeiZjqHNKTst1U3rNjivtvcyJ3n7cABhwbGS3Cu6h8gnG KVug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/96ZD0HZAe7UH1q+dTszIRABA+9Mbd9yT4HIwW5saBo=; b=fGrfRgFaiPsHTC3qBBFWagtGSFkSEbIfjT51z38y2kayoCvsjrEnqk+LPTfsmhTCZZ Ogy4b8drgsUZossYsehsYji2qvvgYMjQhRQ0q9mVmXRc/GY+iPiOjwBNhfPK3/Q6Y4kq sOtT0xn6ckmSdEgBOs3kFSqKoifeFE5Rcwy0V4sABLWAutoTxv5p85t0CGn5mmeAus3s pMrcKQvwtFsxr9DIqU57/2WUYPT07hgwODCrZFzLTPPpuqsyVsWKd0OwX6iIxGOOThnw pcJIm1d5slvaQzZvKdke/A24nl6sjRJFDPba+pq8CCViDSzFj2BenDWHQiss2VGhnONY Hzig==
X-Gm-Message-State: AODbwcCBSucjLtytupRcd+EpeTOwrAqe9QQ/mysogZpiAhIeIwf/Nfi2 tdFYUVAHINCHc4FeL58gmBjRBypDVRO9
X-Received: by 10.129.157.142 with SMTP id u136mr10101724ywg.323.1495225110203;  Fri, 19 May 2017 13:18:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Fri, 19 May 2017 13:18:29 -0700 (PDT)
In-Reply-To: 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi> 
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Fri, 19 May 2017 13:18:29 -0700
Message-ID: 
To: Eric Rescorla 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0b68aa8ddfca054fe6399d"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 20:18:33 -0000

--94eb2c0b68aa8ddfca054fe6399d
Content-Type: text/plain; charset="UTF-8"

On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla  wrote:

> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
>
>> even with distributed servers for the origin.
>>
>
> I don't disagree with that necessarily, but if the client responds by
> retransmitting
> in 1-RTT, then you don't have overall at-most-once.
>

Obviously this is fine for browsers; retry's make sense there anyway, and
so if we prevent mass-replay then there are no new attacks like the
side-channels and DOSes.

If a client needs to be more careful; with a hard-time limit on ticket use,
it can actually reason its way to at-most-once. It needs to wait out the
time limit, then do a read; to see if the original attempt succeeded or
not, and only then retry. That's a fairly common mode in eventually
consistent systems, loss-tolerant protocols and distributed consensus
protocols. For example some S3 clients and PAXOS systems work like this.

Of course it's very inconvenient to have to sometimes block for 10 seconds
(or whatever we pick), in return for a speed up of maybe as much as ~200ms
in the "ordinary" case; but it's the kind of trade-off that an
instrumentation system might make; like an industrial controller - where
day-to-day system liveness is a massive optimization benefit and the
occasional interruption is no big deal.

Super esoteric, and maybe we shouldn't even think too much about it, but I
bring it out because that construction is the only one I've found that gets
to at-most-once delivery; and it highlights that the existing system
explicitly doesn't and might just be needless complexity (the multiple
streams signaling).

-
Colm

--94eb2c0b68aa8ddfca054fe6399d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla <<=
a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:
Yup. There are =
no known reasons that prevent at-most-once 0-RTT delivery,

even with distributed servers for the origin.

I don't disagree with that necessarily, but if the client=
 responds by retransmitting
in 1-RTT, then you don't have ove=
rall at-most-once.

=
Obviously this is fine for browsers; retry's make sense there anyway, a=
nd so if we prevent mass-replay then there are no new attacks like the side=
-channels and DOSes. =C2=A0

If a client needs to b=
e more careful; with a hard-time limit on ticket use, it can actually reaso=
n its way to at-most-once. It needs to wait out the time limit, then do a r=
ead; to see if the original attempt succeeded or not, and only then retry. =
That's a fairly common mode in eventually consistent systems, loss-tole=
rant protocols and distributed consensus protocols. For example some S3 cli=
ents and PAXOS systems work like this.

Of course i=
t's very inconvenient to have to sometimes block for 10 seconds (or wha=
tever we pick), in return for a speed up of maybe as much as ~200ms in the =
"ordinary" case; but it's the kind of trade-off that an instr=
umentation system might make; like an industrial controller - where day-to-=
day system liveness is a massive optimization benefit and the occasional in=
terruption is no big deal.=C2=A0

Super esoteric, a=
nd maybe we shouldn't even think too much about it, but I bring it out =
because that construction is the only one I've found that gets to at-mo=
st-once delivery; and it highlights that the existing system explicitly doe=
sn't and might just be needless complexity (the multiple streams signal=
ing).=C2=A0
=C2=A0
-=C2=A0
Colm




--94eb2c0b68aa8ddfca054fe6399d--


From nobody Fri May 19 13:49:58 2017
Return-Path: 
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 1E51A129B23 for ; Fri, 19 May 2017 13:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=chromium.org
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 gsgJ5t0zbnkO for ; Fri, 19 May 2017 13:49:54 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DEC129B19 for ; Fri, 19 May 2017 13:49:54 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id x64so42997705pgd.3 for ; Fri, 19 May 2017 13:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b4lt4YyChyTKzQOgpBN3zVNwq0mQ5kAxcRfknxj5izY=; b=CSoZCjcv4PQT+vibNrvoIM8MCsF+K298rjYpvwi2VhpNZ25mAEF8dOMbFJ6c6i0Fmv oRLN0CUCQU/a80eoJRlYRfAgwUAyicaNcjB3+hrpVv8GfAsxX6/AlAL76sY9W6fwUVpY wJ5O54Ldh91f04+HxwSJTbZMZRdM3wIxeBgsc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b4lt4YyChyTKzQOgpBN3zVNwq0mQ5kAxcRfknxj5izY=; b=cFA03cbd3cfCctJwCVEpOGBw7MRuVVCit9DOqIWoFrOvSrUXIm/sAk43w8OS/W5VUo TblF8IN4dmdxzd7h++8r3nqYKC9VSEl2h3SMtxeJQUMz7d0p21S7L6F70vycOcyKB/kH 3+IZ2ZhbxbBJIbxkN2YAmN4p0EYGcg5sD/mGECp2umktKjtl25mSWNxou8gptO3HcO6x AHkb/eWFP6xrVeHaqP6VwnscrvAt7bI/xVXBolE2KqqnWTMH4OhQzP8GZfONWkF3q46i glwIkHrS5C5NPfwhOEI5I3BTh7q73yYbKwVJ8xq3utxmnCMMi2bkeuyDC5qYdPvwiV4S af8Q==
X-Gm-Message-State: AODbwcC+cCHj/G3z3yj28qmHgpg/w2S4M5O+Flm7oumHE7OQkl45+JjJ bm/BWsbKM8dGLUBxQgKX9JTKekIPa0PT
X-Received: by 10.98.153.76 with SMTP id d73mr12490725pfe.223.1495226993856; Fri, 19 May 2017 13:49:53 -0700 (PDT)
MIME-Version: 1.0
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi> 
In-Reply-To: 
From: David Benjamin 
Date: Fri, 19 May 2017 20:49:42 +0000
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  Ilari Liusvaara 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0bd3ead4483f054fe6a9ca"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 20:49:56 -0000

--94eb2c0bd3ead4483f054fe6a9ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Seeing as this utterly ridiculous ticket_age_add thing is partially my
fault, I suppose I should respond:

On Fri, May 19, 2017 at 4:10 PM Colm MacC=C3=A1rthaigh 
wrote:

> > And then separate to all of the above, and lower priority:
>> >
>> > * There's a contradiction between the obfuscated ticket age add
>> parameter
>> > and the desire to use tickets multiple times in other (non-0RTT) cases=
.
>> We
>> > can't do one without defeating the point of the other. Either remove t=
he
>> > obfuscation because it is misleading, or move it into an encrypted
>> message
>> > so that it is robust.
>>
>> The purpose of obfustication is not to hide sibling sessions. The
>> client already blows its cover by using the same session ID twice. The
>> purpose of obfustication is to hide the parent session.
>
>
>> Are you talking about attackers being able to determine the rate of
>> client clock?
>>
>
> Right now if a ticket is used multiple times, then the ticket age can be
> derived (trivial cryptanalysis due to re-using the same obfuscated offset=
,
> and because the progression of time between the ticket uses is public);
> that means the parent session can be identified. So the point is defeated=
.
>

Could you expand on your cryptanalysis? I don't believe this is actually
leaked. It's addition mod 2^32, not XOR, which means you effectively
randomize the parent starting time. (It was initially XOR, and then
shortly changed
to addition
.)
Consider:

initial connection at time t1, issues a ticket with ticket_age_add =3D x. L=
et
t1' =3D t1 - x.
Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 +
x =3D t2 - t1'.
Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The
attacker learns t3 - t1 + x =3D t3 - t1'.

x is uniformly distributed over [0, 2^32), so t1' =3D t1 - x is as well. Th=
is
is a one-time pad on t1, correctly used only once. x is only ever used to
encrypt one timestamp, t1.

Of course, the attacker can correlate t2 and t3 by subtracting the two
public values and checking against the public difference between
connections they observe. But the ticket's already leaked anyway.


> Either the one-time-pad can be used just one time (which means the ticket
> can be used just once) or we should move it to an encrypted message. Or
> just get rid of it and not be so misleading. But the current state is
> weird, to say the least.
>

I believe stuffing something into an AEAD was proposed and then rejected by
the cryptographers for some reason? You'd have to ask other folks for
details. I just recall being told that was a previous rejected proposal.
Accordingly, I suggested the dumbest thing that could possibly work,
intending it be so dumb that it could not possibly have consequences beyond
patching that correlation hole. :-)

David

--94eb2c0bd3ead4483f054fe6a9ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Seeing as this utterly rid=
iculous ticket_age_add thing is partially my fault, I suppose I should resp=
ond:

On Fri, May 19, 2017 at 4:10 PM Colm MacC=C3=
=A1rthaigh <colm@=
allcosts.net> wrote:=C2=A0
<=
div dir=3D"ltr">

> And then separate to all of the above, and lower priority:

>

> * There's a contradiction between the obfuscated ticket age add pa=
rameter

> and the desire to use tickets multiple times in other (non-0RTT) cases=
. We

> can't do one without defeating the point of the other. Either remo=
ve the

> obfuscation because it is misleading, or move it into an encrypted mes=
sage

> so that it is robust.



The purpose of obfustication is not to hide sibling sessions. The
client already blows its cover by using the same session ID twice. The

purpose of obfustication is to hide the parent session.=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


Are you talking about attackers being able to determine the rate of

client clock?

Right now i=
f a ticket is used multiple times, then the ticket age can be derived (triv=
ial cryptanalysis due to re-using the same obfuscated offset, and because t=
he progression of time between the ticket uses is public); that means the p=
arent session can be identified. So the point is defeated.=C2=A0

Could you expand on your cryptanalysis? I don=
9;t believe this is actually leaked. It's addition mod 2^32, not XOR, w=
hich means you=C2=A0effectively randomize the parent starting time. (It was=
 initially XOR, and then shortly=C2=A0changed to additio=
n.) Consider:

initial connection at time t1, i=
ssues a ticket with ticket_age_add =3D x. Let t1' =3D t1 - x.
Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - =
t1=C2=A0+ x =3D t2 - t1'.
Resumption 2 (or HelloRetryRequest)=
 at time t3, offers t1's ticket.=C2=A0The attacker learns t3 - t1 + x=
=C2=A0=3D t3 - t1'.

x is uniformly distributed=
 over [0, 2^32), so t1' =3D t1 - x is as well. This is a one-time pad o=
n t1, correctly used only once. x is only ever used to encrypt one timestam=
p, t1.

Of course, the attacker can corr=
elate t2 and t3 by subtracting the two public values and checking against t=
he public difference between connections they observe. But the ticket's=
 already leaked anyway.
=C2=A0
=

Either the one-t=
ime-pad can be used just one time (which means the ticket can be used just =
once) or we should move it to an encrypted message. Or just get rid of it a=
nd not be so misleading. But the current state is weird, to say the least.=
=C2=A0

I believe stuffing something in=
to an AEAD was proposed and then rejected by the cryptographers for some re=
ason? You'd have to ask other folks for details. I just recall being to=
ld that was a previous rejected proposal. Accordingly, I suggested the dumb=
est thing that could possibly work, intending it be so dumb that it could n=
ot possibly have consequences beyond patching that correlation hole. :-)

David


--94eb2c0bd3ead4483f054fe6a9ca--


From nobody Fri May 19 13:51:26 2017
Return-Path: 
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 BB7D0129B19 for ; Fri, 19 May 2017 13:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 VEq1vd-DxMkg for ; Fri, 19 May 2017 13:51:23 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C8D129B45 for ; Fri, 19 May 2017 13:51:22 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 24F557A32F1 for ; Fri, 19 May 2017 20:51:22 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Fri, 19 May 2017 16:51:21 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org>
References: 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 20:51:25 -0000

> On May 19, 2017, at 5:34 AM, Sankalp Bagaria  =
wrote:
>=20
> I would like to mention that TLS can be used with non-X.509 =
certificates also.
> In particular, it can be used with ITS ETSI and IEEE certificates.=20
> =
https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609
>=20
> So, in my opinion, TLS should be very loosely or not at all coupled =
with=20
> RFC 5280.

Which brings us to some more undesirable layer violation in the current
draft.  The language in question is appropriate for updates to RFC5280,
but does not belong in TLS.  The problems in question are largely
already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
certificates, browsers no longer support them, ...) and continue to
be further remediated in the appropriate standards and products.

Therefore delete:

   Section 4.2.3 (Legacy algorithms paragraph final sentence):

      ...                                       TLS 1.3 servers
      MUST NOT offer a SHA-1 signed certificate unless no valid
      certificate chain can be produced without it (see
      Section 4.4.2.2).

   Section 4.4.2.2:

   ...          This fallback chain MAY use the deprecated SHA-1 hash
   algorithm only if the "signature_algorithms" extension provided by
   the client permits it.  If the client cannot construct an acceptable
   chain using the provided certificates and decides to abort the
   handshake, then it MUST abort the handshake with an
   "unsupported_certificate" alert.

   Section 4.4.2.4:

   Any endpoint receiving any certificate signed using any signature
   algorithm using an MD5 hash MUST abort the handshake with a
   "bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
   that any endpoint receiving any certificate signed using any
   signature algorithm using a SHA-1 hash abort the handshake with a
   "bad_certificate" alert.  All endpoints are RECOMMENDED to transition
   to SHA-256 or better as soon as possible to maintain interoperability
   with implementations currently in the process of phasing out SHA-1
   support.

I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
MD4, RIPEMD160, private signature oids, ... that may be weaker than =
SHA-1
or even MD5.

Opportunistic unauthenticated TLS ignores the peer certificate and =
should
not have to fall back to cleartext just because some certificate in the
chain is not sufficiently sexy.  There are other legitimate use cases =
where
the restrictions above are inappropriate.

The reason I am pointing this out is that I just had to waste a bunch of
time convincing the rest of the OpenSSL team to ignore the draft =
language
in question, and just stick with whatever "security level" (floor on
algorithm strength) the application or default settings requested.  This
already excludes MD5 by default, and we'll likely adjust the collision
resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength =
(from
the recent Google collision announcement), after which SHA-1 will also
be excluded at security level 1.  This will be done in the X.509 ala =
PKIX
code and not the TLS code, and applications that ignore the chain or do
DANE-EE(3), ... will not be affected.

I propose that the current draft language is just a landmine for TLS
implementations, that addresses a non-problem (or more precisely a
problem that is more properly and well addressed elsewhere).

--=20
	Viktor.


From nobody Fri May 19 13:58:35 2017
Return-Path: 
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 161A4129B19 for ; Fri, 19 May 2017 13:58:35 -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] 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 EurZ0nfTMAAo for ; Fri, 19 May 2017 13:58:33 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14381296D2 for ; Fri, 19 May 2017 13:58:33 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 11A587A32F1 for ; Fri, 19 May 2017 20:58:33 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Fri, 19 May 2017 16:58:32 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <5513C0EF-3282-4B87-AF0B-3B07D1094B50@dukhovni.org>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>  
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 20:58:35 -0000

> On May 19, 2017, at 4:49 PM, David Benjamin  =
wrote:
>=20
> Could you expand on your cryptanalysis? I don't believe this is =
actually leaked. It's addition mod 2^32, not XOR, which means you =
effectively randomize the parent starting time. (It was initially XOR, =
and then shortly changed to addition.) Consider:
>=20
> initial connection at time t1, issues a ticket with ticket_age_add =3D =
x. Let t1' =3D t1 - x.
> Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - =
t1 + x =3D t2 - t1'.
> Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. =
The attacker learns t3 - t1 + x =3D t3 - t1'.
>=20
> x is uniformly distributed over [0, 2^32), so t1' =3D t1 - x is as =
well. This is a one-time pad on t1, correctly used only once. x is only =
ever used to encrypt one timestamp, t1.
>=20
> Of course, the attacker can correlate t2 and t3 by subtracting the two =
public values and checking against the public difference between =
connections they observe. But the ticket's already leaked anyway.

+1.  The additive obfuscation leaks nothing that is not already leaked =
just by sending the tickets.

--=20
	Viktor.


From nobody Fri May 19 14:35:33 2017
Return-Path: 
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 9436F12717E for ; Fri, 19 May 2017 14:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 DW_KTzyOTby9 for ; Fri, 19 May 2017 14:35:31 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FDC1200F1 for ; Fri, 19 May 2017 14:35:31 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 86B5A20051C27; Fri, 19 May 2017 14:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=pbwhRz3gsB/pxUJphPCGSLBU4zA =; b=HWNeL/ZNTyF+rvYNL2S+x1f4GtEsNvC2BXNfsbqq38RSUppFJOqLbtmZBOM 62CqnZdbNrhIoKyaH/kZmoRcapq7pMnWCNmIJvJ9wm9ozUEvdejhSaf/o40N0ME1 DAHS/i6QSmiC+bBCb7Ytbu1LCE2C7imr4yGVkXSegm4TNxRA=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 5221C20051C24; Fri, 19 May 2017 14:35:30 -0700 (PDT)
Date: Fri, 19 May 2017 16:35:27 -0500
From: Nico Williams 
To: TLS WG 
Message-ID: <20170519213526.GL10188@localhost>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 21:35:32 -0000

On Fri, May 19, 2017 at 04:51:21PM -0400, Viktor Dukhovni wrote:
> Which brings us to some more undesirable layer violation in the current
> draft.  The language in question is appropriate for updates to RFC5280,
> but does not belong in TLS.  The problems in question are largely
> already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
> certificates, browsers no longer support them, ...) and continue to
> be further remediated in the appropriate standards and products.
> 
> Therefore delete:

+1

Grounds:

 - layering violation (though arguably this TLS 1.3 could be made to
   update RFC5280, we shouldn't want to do that)

 - banning some, but not all weak algorithms is a knee-jerk reaction --
   it's reactionary

 - this hurts applications that don't care for TLS server
   authentication -- applications which either don't care for server
   authentication at all, or which will use channel binding

 - it's much better to have a security level knob that disables weak
   algorithms

   (apps which don't care for TLS server authentication... need two such
   knobs: one for server authentication (on/off) and one for security
   level for key agreement, PRF, and ciphersuite negotiation)

> I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
> or even MD5.

That could be fixed, of course.  But let's not.

> The reason I am pointing this out is that I just had to waste a bunch of
> time convincing the rest of the OpenSSL team to ignore the draft language
> in question, and just stick with whatever "security level" (floor on
> algorithm strength) the application or default settings requested.  This

I much prefer the idea that there MUST be a security level knob for the
user/application.

> already excludes MD5 by default, and we'll likely adjust the collision
> resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from
> the recent Google collision announcement), after which SHA-1 will also
> be excluded at security level 1.  This will be done in the X.509 ala PKIX
> code and not the TLS code, and applications that ignore the chain or do
> DANE-EE(3), ... will not be affected.

That's right: for PKIX server authentication, the security level
enforcement should be done in PKIX code, not in TLS code.  This is an
excellent example of how layering in Internet protocols should translate
into layering into implementations.  Conversely, this is also an example
of how layering violations in Internet protocols lead to layering
violations in implementations.

> I propose that the current draft language is just a landmine for TLS
> implementations, that addresses a non-problem (or more precisely a
> problem that is more properly and well addressed elsewhere).

+1.

Nico
-- 


From nobody Fri May 19 15:06:50 2017
Return-Path: 
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 18233129AAA for ; Fri, 19 May 2017 15:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 0caBQGZxTlvo for ; Fri, 19 May 2017 15:06:47 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672991294C4 for ; Fri, 19 May 2017 15:06:47 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id l14so40665344ywk.1 for ; Fri, 19 May 2017 15:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=sNveR7guMwKFj7hYi0otiwVnOt7V/BcqJE0INDGmcEo=; b=aQAkqN8hPlPWftqCp77bzQG9U5PCYX730xyD3Idq1hl3W9nEWj869kiwT/fScVB5xN 6EoMWz0p36tW38G358uSXl1e85dsTrfCFfQSPTFKl/p5PFlSeWvNg2y7dD202szkszAM +5DUxFwJpCswMcNkiSdyhrV3bQZT3H38y4DDpEVJ1sWknpmrVNFJ1xldfPGQjUvdeDaf FT3n5B6kuRJMKJXoab8Ik3yEQB12ZqY9PsKh1/9FZEuTkMYbZdDXHTWw22ztJsgWCFig 8o0Yn+D8BYFVDHbU10Bjd9md32B9ntDztmHVAtEPaUP4qV1pgLtuk68JBYjj5ZRwWRxN HMUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=sNveR7guMwKFj7hYi0otiwVnOt7V/BcqJE0INDGmcEo=; b=EaLxmg4isi+H4CHoMaHz/5LOQW/EJSJJnZKqhbpA3iBRjNDwXc9cpYV7SDlTB4AIIu JC63RIamBfixS1YbsstpoEOMLRSKhLz/4VkexVrD5L8EwJAuOTJ/u0ZG4yA8kh8p8DTR Rn2h/gkKOsV8h/SyGVlvbqy5EYpoH2DlfuKse+uhft1YvfmaHLB6q9P7HAmtc080k7r0 +WuOebiDaiBTCV3rwR8eQ5fFBJmpjDwOIW/K9E1feX5xUyJC8MuMMTj9VrIyoI4sa2v0 4CVhDtZ6vSof27Syg2hmol7c+tc5zHwycMNSCPWocJLI9biAYxJcqwYxcyUX7HsB6qIF 8qDg==
X-Gm-Message-State: AODbwcA66tg7fIuC9PM0vouol92bli1To507GIEoon+oHR+gck7jp9LF LQXodeDY2eL+3m0QgusnxYir/cTF6/+7MVA=
X-Received: by 10.13.237.134 with SMTP id w128mr9536866ywe.122.1495231605993;  Fri, 19 May 2017 15:06:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Fri, 19 May 2017 15:06:45 -0700 (PDT)
In-Reply-To: <5513C0EF-3282-4B87-AF0B-3B07D1094B50@dukhovni.org>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>   <5513C0EF-3282-4B87-AF0B-3B07D1094B50@dukhovni.org>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Fri, 19 May 2017 15:06:45 -0700
Message-ID: 
To: TLS WG 
Content-Type: multipart/alternative; boundary="94eb2c08853ebbb4af054fe7bcd5"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 22:06:49 -0000

--94eb2c08853ebbb4af054fe7bcd5
Content-Type: text/plain; charset="UTF-8"

On Fri, May 19, 2017 at 1:58 PM, Viktor Dukhovni 
wrote:
>
> +1.  The additive obfuscation leaks nothing that is not already leaked
> just by sending the tickets.
>

You're both right, that does work out. I was thinking my balanced equations
stupidly and solving for x while forgetting that t1' is secret.

-- 
Colm

--94eb2c08853ebbb4af054fe7bcd5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, May 19, 2017 at 1:58 PM, Viktor Dukhovni <=
ietf-dane@dukho=
vni.org> wrote:
+1.=C2=A0 The additive obfusc=
ation leaks nothing that is not already leaked just by sending the tickets.=


You're both right, that does work =
out. I was thinking my balanced equations stupidly and solving for x while =
forgetting that t1' is secret.=C2=A0

-- 
<=
div class=3D"gmail_signature">Colm




--94eb2c08853ebbb4af054fe7bcd5--


From nobody Fri May 19 15:43:28 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E1E129B5E; Fri, 19 May 2017 15:43:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu 
To: 
Cc: draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, ietf@ietf.org, tls@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149523380739.28567.9584998643479497589@ietfa.amsl.com>
Date: Fri, 19 May 2017 15:43:27 -0700
Archived-At: 
Subject: [TLS] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 19 May 2017 22:43:27 -0000

Reviewer: Dan Romascanu
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-ecdhe-psk-aead-??
Reviewer: Dan Romascanu
Review Date: 2017-05-19
IETF LC End Date: 2017-05-18
IESG Telechat date: 2017-05-25

Summary:

This is a straight-forward and clear document that defines several new
cipher suites for the Transport Layer Security (TLS) protocol version
1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
with Pre-Shared Key (ECDHE_PSK) key exchange together with the
Authenticated Encryption with Associated Data (AEAD) algorithms
AES-GCM and AES-CCM. The document is well written and I appreciate the
effort to clarify in the Introduction the context, what was missing,
and why the document is necessary. One issue raised in my initial
review for draft-03 was addressed, discussed and draft-04 includes
useful clarification text. 

The document is Ready

Major issues:

Minor issues:

Nits/editorial comments: 



From nobody Fri May 19 15:47:17 2017
Return-Path: 
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 8EC49129B5F for ; Fri, 19 May 2017 15:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 50ICqK9y8PDW for ; Fri, 19 May 2017 15:47:13 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748B8129B4D for ; Fri, 19 May 2017 15:47:13 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id l14so40927278ywk.1 for ; Fri, 19 May 2017 15:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BdOfDOTBZIbhiKGX9idcYMf66qmhEj8CDo6OAtPiklc=; b=SPcrOQKXWwWMqUwAbR6QvcaChQrKzITFiClhNraNLGKStOJ2PRX2tKiskQC3QxQpA8 RKlkFhQoxw0L+kZcxaM9J+d6BZHeL271Qtog6wV3l6OpJrmY9NSb9csB1k7i7C0H6Lxy JXbzWrBu4Dfs5PSsruuhqNnSPqlO0lrn/12IiBYYkRrNY1o3HL0gd69B0D5hTceuGYZt Xl611pn3XJSXn1FDM3YoTFmKHp59GWSlv8Gp8ph5hNG5/Va+sW72gG6zRKjgxd1mzfjg oDvueJYy34FaHT4d9nYxjTA6ixL/feHoOFDsHb6T5tYXtKQhxjsAsqIkGHxMY9JG++hs kB+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BdOfDOTBZIbhiKGX9idcYMf66qmhEj8CDo6OAtPiklc=; b=MY7XXYg++vcAYnO6LRM5UvniBQGSDJjrRy+bpxD927nvESFtZAvIr435WqOJw59Xp2 dRv5IsyfHcX0OZ9fkJEnC58Fc1wBDQvF66QWZ6iOCZIqmqv3jnWTB1K3/sNz9JHCGcgi wO4fkYZKxIU7soGqgpJn1FJcf7vYCBXig2aHI6vVVHiLY7GgfP5Mm1lmgxZcVUHMoHUT tcm1dxz4N/PlJHBi11RMKsgAz2HU++75kz7GQdJyB3jJJ/2svwI3MNEtJQsvb+8GPGce D1cIXKR3qHVCFqOww/WMnIo5qb9hfEoKj5ngEpvq/hYe4h/4ZnNsS290UdbFP/ETP06s oUjg==
X-Gm-Message-State: AODbwcBL4uZYHOUBBygP2jcQTVpRnGOGO2RNeswJZTgkEQWbLolnWduS CPAOAlqmARhgf1EZjsXifccapsIIPCHk
X-Received: by 10.13.212.1 with SMTP id w1mr9565878ywd.24.1495234032751; Fri, 19 May 2017 15:47:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Fri, 19 May 2017 15:46:32 -0700 (PDT)
In-Reply-To: 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>  
From: Eric Rescorla 
Date: Fri, 19 May 2017 18:46:32 -0400
Message-ID: 
To: David Benjamin 
Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114fb0f6610677054fe84dc5"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 22:47:15 -0000

--001a114fb0f6610677054fe84dc5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 19, 2017 at 4:49 PM, David Benjamin 
wrote:

> Seeing as this utterly ridiculous ticket_age_add thing is partially my
> fault, I suppose I should respond:
>
> On Fri, May 19, 2017 at 4:10 PM Colm MacC=C3=A1rthaigh 
> wrote:
>
>> > And then separate to all of the above, and lower priority:
>>> >
>>> > * There's a contradiction between the obfuscated ticket age add
>>> parameter
>>> > and the desire to use tickets multiple times in other (non-0RTT)
>>> cases. We
>>> > can't do one without defeating the point of the other. Either remove
>>> the
>>> > obfuscation because it is misleading, or move it into an encrypted
>>> message
>>> > so that it is robust.
>>>
>>> The purpose of obfustication is not to hide sibling sessions. The
>>> client already blows its cover by using the same session ID twice. The
>>> purpose of obfustication is to hide the parent session.
>>
>>
>>> Are you talking about attackers being able to determine the rate of
>>> client clock?
>>>
>>
>> Right now if a ticket is used multiple times, then the ticket age can be
>> derived (trivial cryptanalysis due to re-using the same obfuscated offse=
t,
>> and because the progression of time between the ticket uses is public);
>> that means the parent session can be identified. So the point is defeate=
d.
>>
>
> Could you expand on your cryptanalysis? I don't believe this is actually
> leaked. It's addition mod 2^32, not XOR, which means you effectively
> randomize the parent starting time. (It was initially XOR, and then short=
ly changed
> to addition
> .)
> Consider:
>
> initial connection at time t1, issues a ticket with ticket_age_add =3D x.
> Let t1' =3D t1 - x.
> Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 =
+
> x =3D t2 - t1'.
> Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The
> attacker learns t3 - t1 + x =3D t3 - t1'.
>
> x is uniformly distributed over [0, 2^32), so t1' =3D t1 - x is as well.
> This is a one-time pad on t1, correctly used only once. x is only ever us=
ed
> to encrypt one timestamp, t1.
>
> Of course, the attacker can correlate t2 and t3 by subtracting the two
> public values and checking against the public difference between
> connections they observe. But the ticket's already leaked anyway.
>
>
>> Either the one-time-pad can be used just one time (which means the ticke=
t
>> can be used just once) or we should move it to an encrypted message. Or
>> just get rid of it and not be so misleading. But the current state is
>> weird, to say the least.
>>
>
> I believe stuffing something into an AEAD was proposed and then rejected
> by the cryptographers for some reason? You'd have to ask other folks for
> details. I just recall being told that was a previous rejected proposal.
> Accordingly, I suggested the dumbest thing that could possibly work,
> intending it be so dumb that it could not possibly have consequences beyo=
nd
> patching that correlation hole. :-)
>

What was rejected was actually having the stuffed Finished be an
AEAD-encrypted block
containing stuff like the ticket_age. We could certainly derive a new key
and AEAD it if
we wanted to, that just seemed like a lot more work than I think people
wanted to do.

-Ekr


>
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114fb0f6610677054fe84dc5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, May 19, 2017 at 4:49 PM, David Benjamin <<=
a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium=
.org> wrote:
Seeing as this utterly ridiculous ticket=
_age_add thing is partially my fault, I suppose I should respond:

On Fri, May 19, 2017 at 4:10 PM Colm MacC=
=C3=A1rthaigh <co=
lm@allcosts.net> wrote:=C2=A0

> And then separate to all of the above, and lower priority:

>

> * There's a contradiction between the obfuscated ticket age add pa=
rameter

> and the desire to use tickets multiple times in other (non-0RTT) cases=
. We

> can't do one without defeating the point of the other. Either remo=
ve the

> obfuscation because it is misleading, or move it into an encrypted mes=
sage

> so that it is robust.



The purpose of obfustication is not to hide sibling sessions. The
client already blows its cover by using the same session ID twice. The

purpose of obfustication is to hide the parent session.=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


Are you talking about attackers being able to determine the rate of

client clock?

Right now i=
f a ticket is used multiple times, then the ticket age can be derived (triv=
ial cryptanalysis due to re-using the same obfuscated offset, and because t=
he progression of time between the ticket uses is public); that means the p=
arent session can be identified. So the point is defeated.=C2=A0

Could you expand on your cryptanalysis? I=
 don't believe this is actually leaked. It's addition mod 2^32, not=
 XOR, which means you=C2=A0effectively randomize the parent starting time. =
(It was initially XOR, and then shortly=C2=A0changed to =
addition.) Consider:

initial connection at tim=
e t1, issues a ticket with ticket_age_add =3D x. Let t1' =3D t1 - x.
Resumption 1 at time t2, offers t1's ticket. The attacker learn=
s t2 - t1=C2=A0+ x =3D t2 - t1'.
Resumption 2 (or HelloRetryR=
equest) at time t3, offers t1's ticket.=C2=A0The attacker learns t3 - t=
1 + x=C2=A0=3D t3 - t1'.

x is uniformly distri=
buted over [0, 2^32), so t1' =3D t1 - x is as well. This is a one-time =
pad on t1, correctly used only once. x is only ever used to encrypt one tim=
estamp, t1.

Of course, the attacker can=
 correlate t2 and t3 by subtracting the two public values and checking agai=
nst the public difference between connections they observe. But the ticket&=
#39;s already leaked anyway.
=C2=A0
Either the one-time-pad can be used just one time (which means the ti=
cket can be used just once) or we should move it to an encrypted message. O=
r just get rid of it and not be so misleading. But the current state is wei=
rd, to say the least.=C2=A0

I b=
elieve stuffing something into an AEAD was proposed and then rejected by th=
e cryptographers for some reason? You'd have to ask other folks for det=
ails. I just recall being told that was a previous rejected proposal. Accor=
dingly, I suggested the dumbest thing that could possibly work, intending i=
t be so dumb that it could not possibly have consequences beyond patching t=
hat correlation hole. :-)
=C2=A0
What was rejected was actually having the stuffed Finished be an A=
EAD-encrypted block
containing stuff like the ticket_age. We coul=
d certainly derive a new key and AEAD it if
we wanted to, that ju=
st seemed like a lot more work than I think people wanted to do.
=

-Ekr
=C2=A0


David


_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114fb0f6610677054fe84dc5--


From nobody Fri May 19 18:22:01 2017
Return-Path: 
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 B34DB124D6C; Fri, 19 May 2017 18:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nC6kSG00Bm6N; Fri, 19 May 2017 18:21:58 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B9A1243F3; Fri, 19 May 2017 18:21:58 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id y201so73873620qka.0; Fri, 19 May 2017 18:21:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=3II2yMK+DpEQBU3X7DTbIlW58DfNRGqxoPfKnhx6hKU=; b=Yf8ORFYMSUgBgSSKHdoFD7oWs8vfQ8vPqcoFc5iCYiPWZ+nmQFP/L0F+QHagpJ178K 5U832L+U1jQT1/ZYQ5rsYdE4/biaXz+T+zM3mDu9TNuUdmHz8s7Mmge5j/fFX5nbKsES AKItYgDsix78VKLDZr0989JcvrDG2lBoxx4S8mzqw3Z4JllciPa1nmcC3yUANoBZWWOu G4r8XHBAtV1WI5EB3upiqCHq6f9oe8LuwKOyq4788Eq7jVEeiXpcmGKnpsOSs8Vvnj2L Vk33F28VviE3/kj+LZdGCurj///QxOE+hNCNuaRRjjrygVsXZpM7L+6I+NVPu3W6tPk1 p1LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=3II2yMK+DpEQBU3X7DTbIlW58DfNRGqxoPfKnhx6hKU=; b=etezdsua418eAzHN5EivXDi256bQ+cIoFGwVQd4ztc0HqSIg28cUBz/c6bKGqt1L9p qpcnXUoDS11/hEKRvLlJTTB47f/mpQkHiqlnLPwMCG2esVPGT7tMvuaq3pBPjwtQVipe CiuCaRh2ugs6lWgwvu8zumxzaDYVmVteDlubqX6a/aqdGMod3Fh68g8Qfxbl2VRvGT2W s8wpUsBrUa31vEAyPaRm5lm9cyhYm3LV/W24DKMdKV/UkrgIWKOMky+bLYRr5/bV/Eup ANlab/o7YNRKT8koD4Fb40lXCphcY8az5KO6eHBQwKABfkpCPf9ljkjaJTEW6E8YxYuu 1wwA==
X-Gm-Message-State: AODbwcAWRCp3z5Qd8yKAiauRXnfnDhpFuQyce0QVBCcUzH43KCwQ6IRg znnL0t/obZVmog==
X-Received: by 10.55.20.9 with SMTP id e9mr11064079qkh.94.1495243317294; Fri, 19 May 2017 18:21:57 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id r40sm7370151qkr.13.2017.05.19.18.21.56 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 May 2017 18:21:56 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 19 May 2017 21:21:54 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
Cc: Daniel Migault , "tls-chairs" 
References: <149522417333.23956.7024977757521677892.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDBB01@eusaamb107.ericsson.se>
In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDBB01@eusaamb107.ericsson.se>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201705192121.55279.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 01:22:00 -0000

On Friday, May 19, 2017 04:18:03 pm Daniel Migault wrote:
> 1)  The current document mentions I-D.ietf-tls-rfc4492bis and I-D.ietf-tls-tls13 as normative. We can wait for these documents to become RFCs, but we can also dowref them to informational reference if we want to move that document forward. I will leave the AD to decide, and changes if needed can be done by the RFC -editor

Listing TLS 1.3 as normative when it explicitly doesn't affect/support it is weird. I don't see the need for this to not be an informational reference. 4492bis lists TLS 1.3 as informative as well, yet is more relevant to it. I think just downgrading the reference is fine.


Dave


From nobody Fri May 19 18:43:27 2017
Return-Path: 
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 D63881271FD for ; Fri, 19 May 2017 18:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9GB9851WIQYP for ; Fri, 19 May 2017 18:43:23 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1411204DA for ; Fri, 19 May 2017 18:43:22 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id f55so70529807qta.3 for ; Fri, 19 May 2017 18:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=ntgufxNNtnOOsrneKHTFHCvWlyYUu/vW9eZOHtC8czs=; b=vSUFBerljo0ZzjbQKEyvf1M5H2dsx7MdZ1Zw5G+nzipfDZjQJuVbUQlsoZVYk6i6/e /xX3yQ0v6WeEleiymnFlrF86xNV6rVjQzgkOhlOXY/STwrnpPKHyEgTHWaEpZMqfXdFP cVC2NFbxzryo9ux8EfzA6DBHQQ53rw8eqnsPTKaDzeKbbilnxYV/EZc5tmJy2aOpl086 Z5Ncic+WGyhW7J4Xp3HX/yeXltJroJkBBdQD+cXOsboWjVXbZEADOTh5axSuYhYnf3pt 50dnYhoJNQF+qzsGFwE675U/UdY9n3/5VUMMol3FrHS3SqU93CamWu/U/INA1MTRx+B6 mV2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=ntgufxNNtnOOsrneKHTFHCvWlyYUu/vW9eZOHtC8czs=; b=hqyg/Jlu1fXO4PXCdm0QHXYjGOtUZcKEL1WefpRAGkzgDNehuTM2e1H0/KQStTPtof f7yLoC0mFPDjBUsj2cgZlENrR1uaif+u7/AhkStmqJIjTC31/bhzI0DK4gvipnDLKJ/O z8jxq9enDymywk2e/0Q388XJJsOQKPVWHDllWTzUlse1lH41x8IOZ2Bkd5BpxQzTeopS nkIw9HYoNw2vGrxKDHeGGRrbLYexLssz7Ge5OGTDp3yhxD5XhzypBheohGhmamKmUFT1 ziDOLn414kHxg7+JAExc55AqffIZoBEqIuANzWB+3xEIEpWIeThPfLvOQGFQkJY116ww 6w8g==
X-Gm-Message-State: AODbwcD/sVgSbr8iM772dEV1ppiSFHF3UKP8Ad2I8luS4Sj/tO2HcUiL Byy4vJmnu+oYFw==
X-Received: by 10.200.42.252 with SMTP id c57mr12563835qta.282.1495244601750;  Fri, 19 May 2017 18:43:21 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id y48sm4635673qta.66.2017.05.19.18.43.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 May 2017 18:43:20 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org, Viktor Dukhovni 
Date: Fri, 19 May 2017 21:43:19 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org>
In-Reply-To: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201705192143.19490.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 01:43:25 -0000

On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote:
> Which brings us to some more undesirable layer violation in the current
> draft.  The language in question is appropriate for updates to RFC5280,
> but does not belong in TLS.  The problems in question are largely
> already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
> certificates, browsers no longer support them, ...) and continue to
> be further remediated in the appropriate standards and products.
> 
> Therefore delete:
> 
>    Section 4.2.3 (Legacy algorithms paragraph final sentence):
> 
>       ...                                       TLS 1.3 servers
>       MUST NOT offer a SHA-1 signed certificate unless no valid
>       certificate chain can be produced without it (see
>       Section 4.4.2.2).
> 
>    Section 4.4.2.2:
> 
>    ...          This fallback chain MAY use the deprecated SHA-1 hash
>    algorithm only if the "signature_algorithms" extension provided by
>    the client permits it.  If the client cannot construct an acceptable
>    chain using the provided certificates and decides to abort the
>    handshake, then it MUST abort the handshake with an
>    "unsupported_certificate" alert.
> 
>    Section 4.4.2.4:
> 
>    Any endpoint receiving any certificate signed using any signature
>    algorithm using an MD5 hash MUST abort the handshake with a
>    "bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
>    that any endpoint receiving any certificate signed using any
>    signature algorithm using a SHA-1 hash abort the handshake with a
>    "bad_certificate" alert.  All endpoints are RECOMMENDED to transition
>    to SHA-256 or better as soon as possible to maintain interoperability
>    with implementations currently in the process of phasing out SHA-1
>    support.

No. I strongly oppose stripping all off this out.

> I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
> or even MD5.

They're not listed as possible field values anywhere directly in the TLS spec.
If someone wants to add a line to one of the "MUST NOT" lists somewhere for
all hashes weaker than SHA-1, that sounds fine to me.

> Opportunistic unauthenticated TLS ignores the peer certificate and should
> not have to fall back to cleartext just because some certificate in the
> chain is not sufficiently sexy.  There are other legitimate use cases where
> the restrictions above are inappropriate.

Opportunistic unauthenticated TLS isn't the protocol we're defining here.
If your goal isn't authentication, then by all means violate the requirements
laid out for authentication. I have no problem making that explicit, if desired,
however this is not the primary desired operating mode of TLS.

> The reason I am pointing this out is that I just had to waste a bunch of
> time convincing the rest of the OpenSSL team to ignore the draft language
> in question, and just stick with whatever "security level" (floor on
> algorithm strength) the application or default settings requested.  This
> already excludes MD5 by default, and we'll likely adjust the collision
> resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from
> the recent Google collision announcement), after which SHA-1 will also
> be excluded at security level 1.  This will be done in the X.509 ala PKIX
> code and not the TLS code, and applications that ignore the chain or do
> DANE-EE(3), ... will not be affected.
> 
> I propose that the current draft language is just a landmine for TLS
> implementations, that addresses a non-problem (or more precisely a
> problem that is more properly and well addressed elsewhere).

TLS is already a minefield of problems. Enumerating many of them explicitly
is a step forward to avoiding them more easily in the future. In a complex
system, just fixing something in one place is not enough. If we list it as
a possible option in the spec, we should be _very_ clear when it is crap.

I'm aware that this is unavoidably messy. Viktor, your input has greatly
helped improve the language here to accommodate varying use-cases,
and I would personally prefer we work together to make the mess correct,
rather than give up and delete the relevant text.


Dave


From nobody Fri May 19 19:15:40 2017
Return-Path: 
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 0C01E12944C for ; Fri, 19 May 2017 19:15:39 -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] 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 BH6NsQ2wzEdS for ; Fri, 19 May 2017 19:15:35 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1530E12778D for ; Fri, 19 May 2017 19:15:35 -0700 (PDT)
Received: from [10.26.15.151] (214.sub-70-214-113.myvzw.com [70.214.113.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AB67B7A32F1 for ; Sat, 20 May 2017 02:15:33 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <201705192143.19490.davemgarrett@gmail.com>
Date: Fri, 19 May 2017 22:15:31 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 02:15:39 -0000

> On May 19, 2017, at 9:43 PM, Dave Garrett  =
wrote:
>=20
>> I note that TLS 1.3 does not have any language prohibiting MD2, =
MDC2DES,
>> MD4, RIPEMD160, private signature oids, ... that may be weaker than =
SHA-1
>> or even MD5.
>=20
> They're not listed as possible field values anywhere directly in the =
TLS spec.
> If someone wants to add a line to one of the "MUST NOT" lists =
somewhere for
> all hashes weaker than SHA-1, that sounds fine to me.

That list was not intended to be take as a serious suggestion.  Note =
that
it is NOT the job of TLS to specify a comprehensive list of X.509 =
certificate
signature algorithm OIDS, which are MTI, which deprecated, and so on.  =
The
security floor you're looking for needs to be set in update to RFC5280
via the "curdle" WG or wherever else such an update belongs.

>=20
>> Opportunistic unauthenticated TLS ignores the peer certificate and =
should
>> not have to fall back to cleartext just because some certificate in =
the
>> chain is not sufficiently sexy.  There are other legitimate use cases =
where
>> the restrictions above are inappropriate.
>=20
> Opportunistic unauthenticated TLS isn't the protocol we're defining =
here.

Actually, it very much is.  This WG defines TLS (period).  That includes
opportunistic unauthenticated TLS, opportunistic DANE TLS, TLS with
pre-shared public key fingerprints, TLS with TOFU key pinning and so on.

One reason TLS is complicated is its versatility.

> If your goal isn't authentication, then by all means violate the =
requirements
> laid out for authentication.

There is no requirement for authentication.  There is only a mechanism
to make it possible.  And opportunistic TLS is NOT a violation of the
TLS specification.

> I have no problem making that explicit, if desired,
> however this is not the primary desired operating mode of TLS.

Yes, the "primary mode" is authentication via a profusion of CAs,
with most certificates being "DV" certificates, which are issued
after perfunctory verification by the CA and memoized in the form
of a certificate for the world to trust.  This means that the MiTM
BGP route injection attack has to target the route between some
trusted CA and the victim domain, rather than between the user
and the victim domain.  It's not much better than opportunistic
TLS, but yes, it does protect against low-tech attacks that only
subvert the user's network (coffee-shop, airport WiFi, ...).

So the X.509 PKI in TLS is not entirely a case of the emperor's new
clothes, but we need to be a bit more realistic about the resulting
security, and not forget that it is far from airtight, and that the
non-mainstream use-cases sometimes yield more actual security than
one might get from an all-or-nothing approach.

>> I propose that the current draft language is just a landmine for TLS
>> implementations, that addresses a non-problem (or more precisely a
>> problem that is more properly and well addressed elsewhere).
>=20
> TLS is already a minefield of problems. Enumerating many of them =
explicitly
> is a step forward to avoiding them more easily in the future. In a =
complex
> system, just fixing something in one place is not enough. If we list =
it as
> a possible option in the spec, we should be _very_ clear when it is =
crap.

PKIX (RFC5280 via X.509) is already a minefield of problems.  The fixes
and ratcheting up the associated security parameters belong there, and
NOT in TLS.  The TLS 1.3 draft does a reasonabl job of improving the =
actual
TLS security design and parameters, and should properly stick to that.

[ Yes, it also adds a potential pitfall in the form of 0-RTT, but that
  is of course another thread. ]

> I'm aware that this is unavoidably messy. Viktor, your input has =
greatly
> helped improve the language here to accommodate varying use-cases,
> and I would personally prefer we work together to make the mess =
correct,
> rather than give up and delete the relevant text.

I'd be  happy to review relevant changes in an RFC5280 update where this
belongs, and would also benefit S/MIME, CMS, etc and not just TLS.

--=20
	Viktor.


From nobody Fri May 19 22:41:24 2017
Return-Path: 
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 9788D129466 for ; Fri, 19 May 2017 22:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 w92yHd4E4EzX for ; Fri, 19 May 2017 22:41:22 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AFD126E64 for ; Fri, 19 May 2017 22:41:22 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 6D67020051C24; Fri, 19 May 2017 22:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=eK2wuhFrHk/0pX +G4SQAF+37KjE=; b=fokjlC7szl3rEUMWhNhZ7dPlGlMipSukJK08gyb/6HwDxU iERZVvP0prFLcpNLUuurodnujSfM3YyQDvKtM+5cu2uIu76tLwA2dEx4pyz6ek9j QyVtdP8hBBKjn1+2NuCPo9fbzhDSZ6f02Rh/sGZCFCllCG+9ErbOQaf6kzdm0=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 1F4D220051C23; Fri, 19 May 2017 22:41:21 -0700 (PDT)
Date: Sat, 20 May 2017 00:41:18 -0500
From: Nico Williams 
To: Dave Garrett 
Cc: tls@ietf.org, Viktor Dukhovni 
Message-ID: <20170520054117.GM10188@localhost>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201705192143.19490.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 05:41:24 -0000

On Fri, May 19, 2017 at 09:43:19PM -0400, Dave Garrett wrote:
> On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote:

> > I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
> > MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
> > or even MD5.
> 
> They're not listed as possible field values anywhere directly in the TLS spec.

That's because it wouldn't be TLS that mentions them but PKIX, so _of
course_ TLS doesn't reiterate everything that PKIX says.

> > Opportunistic unauthenticated TLS ignores the peer certificate and should
> > not have to fall back to cleartext just because some certificate in the
> > chain is not sufficiently sexy.  There are other legitimate use cases where
> > the restrictions above are inappropriate.
> 
> Opportunistic unauthenticated TLS isn't the protocol we're defining here.

TLS certainly can be used that way.  And it is.

> If your goal isn't authentication, then by all means violate the requirements
> laid out for authentication. I have no problem making that explicit, if desired,
> however this is not the primary desired operating mode of TLS.

Then state the requirements in such a way that it is still possible to
use TLS in this way.

"When using TLS to authenticate the server, certificate signature
algorithms weaker than 
MUST NOT be used."

Nico
-- 


From nobody Fri May 19 22:55:12 2017
Return-Path: 
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 C0028129AAD for ; Fri, 19 May 2017 22:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 bNIEUwR_1-RL for ; Fri, 19 May 2017 22:55:10 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34524129544 for ; Fri, 19 May 2017 22:55:09 -0700 (PDT)
Received: from [192.168.0.8] (cpe-67-241-70-168.twcny.res.rr.com [67.241.70.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B7F3C7A32F1 for ; Sat, 20 May 2017 05:55:08 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <20170520054117.GM10188@localhost>
Date: Sat, 20 May 2017 01:55:07 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 05:55:12 -0000

> On May 20, 2017, at 1:41 AM, Nico Williams  wrote:
> 
> "When using TLS to authenticate the server, certificate signature
> algorithms weaker than 
> MUST NOT be used."

Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX)
to authenticate... (the [server or client?]).  TLS is just the transport
after all.

This formulation does correctly place the security floor in the proper
context, namely PKIX authentication, and does not inappropriately
mandate aborting connections and the like.

A peer presenting certificates with deprecated algorithms would then
not pass PKIX authentication.  It is then up to the other party to
decide whether this matters and how to react.

This would amount in essence to a TLS-specific "profile" for PKIX.
If such a thing is really needed, so be it.  So long as we have no
text mandating connection termination based on potentially irrelevant
certificate details I can go along with a compromise in which a more
narrow prohibition of MD5 and SHA-1 remains along the lines above.

-- 
	Viktor.


From nobody Sat May 20 01:29:04 2017
Return-Path: 
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 F16E21273E2 for ; Sat, 20 May 2017 01:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 u-QiE0Pwnjgk for ; Sat, 20 May 2017 01:29:00 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 585A5124234 for ; Sat, 20 May 2017 01:28:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id B5DE422EE1; Sat, 20 May 2017 11:28:57 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id fo17uBzEIWOX; Sat, 20 May 2017 11:28:57 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 571B52313; Sat, 20 May 2017 11:28:57 +0300 (EEST)
Date: Sat, 20 May 2017 11:28:56 +0300
From: Ilari Liusvaara 
To: Dave Garrett 
Cc: tls@ietf.org, Viktor Dukhovni 
Message-ID: <20170520082855.GA32428@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <201705192143.19490.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 08:29:03 -0000

On Fri, May 19, 2017 at 09:43:19PM -0400, Dave Garrett wrote:
> On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote:
> > Which brings us to some more undesirable layer violation in the current
> > draft.  The language in question is appropriate for updates to RFC5280,
> > but does not belong in TLS.  The problems in question are largely
> > already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
> > certificates, browsers no longer support them, ...) and continue to
> > be further remediated in the appropriate standards and products.
> > 
> > Therefore delete:
> > 
> >    Section 4.2.3 (Legacy algorithms paragraph final sentence):
> > 
> >       ...                                       TLS 1.3 servers
> >       MUST NOT offer a SHA-1 signed certificate unless no valid
> >       certificate chain can be produced without it (see
> >       Section 4.4.2.2).
> > 
> >    Section 4.4.2.2:
> > 
> >    ...          This fallback chain MAY use the deprecated SHA-1 hash
> >    algorithm only if the "signature_algorithms" extension provided by
> >    the client permits it.  If the client cannot construct an acceptable
> >    chain using the provided certificates and decides to abort the
> >    handshake, then it MUST abort the handshake with an
> >    "unsupported_certificate" alert.
> > 
> >    Section 4.4.2.4:
> > 
> >    Any endpoint receiving any certificate signed using any signature
> >    algorithm using an MD5 hash MUST abort the handshake with a
> >    "bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
> >    that any endpoint receiving any certificate signed using any
> >    signature algorithm using a SHA-1 hash abort the handshake with a
> >    "bad_certificate" alert.  All endpoints are RECOMMENDED to transition
> >    to SHA-256 or better as soon as possible to maintain interoperability
> >    with implementations currently in the process of phasing out SHA-1
> >    support.
> 
> No. I strongly oppose stripping all off this out.

This requirement is bad layering violation.

It is even further made problematic by:

- TLS and PKIX libraries are often decoupled, making this difficult to
  implement.
- It requires code to support MD5, which as weak algorithm is hazardous.

I do have written TLS implementation. It does not follow this, because I
regard the aborting requirements as insane (it does not have any code to
support MD5, and is not architecturally capable of aborting based on
signature algorithm).

The code treats MD5 as unknown signature algorithm, which does not
require hazardous code. Pathbuilding avoids MD5 signatures and it is
not possible to validate signatures using MD5 (algorithm conversion
will return an error).

(The SHA-1 handling is more complex, as RSA-PKCS#1v1.5-SHA1 is actually
validateable, but only in certain context. Suffice to say, I would
love to just dump the SHA-1 code).

> > I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
> > MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
> > or even MD5.
> 
> They're not listed as possible field values anywhere directly in the TLS spec.
> If someone wants to add a line to one of the "MUST NOT" lists somewhere for
> all hashes weaker than SHA-1, that sounds fine to me.

These are values internal to PKIX. And the draft _does_ allow sending a
certificate contaning those (hint: If the server does not have any
other chain using only signaled algorithms).

And MD5 isn't listed as possible field value either.



-Ilari


From nobody Sat May 20 02:33:54 2017
Return-Path: 
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 BEBD912704A for ; Sat, 20 May 2017 02:33:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 MAFiyhT4lvo7 for ; Sat, 20 May 2017 02:33:51 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id AFD9A1200FC for ; Sat, 20 May 2017 02:33:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DD8E42368F; Sat, 20 May 2017 12:33:48 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ovHf-jN6lO0Q; Sat, 20 May 2017 12:33:48 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id AC881C4; Sat, 20 May 2017 12:33:48 +0300 (EEST)
Date: Sat, 20 May 2017 12:33:47 +0300
From: Ilari Liusvaara 
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= 
Cc: Eric Rescorla , "tls@ietf.org" 
Message-ID: <20170520093347.GB32428@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 09:33:54 -0000

On Fri, May 19, 2017 at 01:10:29PM -0700, Colm MacCárthaigh wrote:
> On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara 
> wrote:
> 
> > > * In order to fully reason about when that message may later get
> > received,
> > > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> > all
> > > potential middle-boxes in the pipe that may be using 0-RTT.
> >
> > Isn't that potentially multi-party problem if middleboxes are involved?
> >
> 
> Yes; but if we can agree on a hard maximum time-window for the 0RTT
> section, and all of the parties agree, it's possible for a careful client
> to negotiate its way around it. Even if it's 10 seconds, this still has
> some value I think.

I meant what prevents the (say 10 second) windows from stacking up into
(say 20 second windows) if 0-RTT is used on multiple hops (client-
middlebox and middlebox-server)?

One can not assume that the client has knowledge of any middlebox on
the path (e.g. CDNs in HTTP are in general invisible to the client).


-Ilari


From nobody Sat May 20 03:16:23 2017
Return-Path: 
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 6F7B4128CFF for ; Sat, 20 May 2017 03:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 KBOYjx1O3LXw for ; Sat, 20 May 2017 03:16:19 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1F127333 for ; Sat, 20 May 2017 03:16:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 63639602B9; Sat, 20 May 2017 13:16:17 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id PUYW8sGSTsKz; Sat, 20 May 2017 13:16:17 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2E21E283; Sat, 20 May 2017 13:16:17 +0300 (EEST)
Date: Sat, 20 May 2017 13:16:16 +0300
From: Ilari Liusvaara 
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= 
Cc: Eric Rescorla , "tls@ietf.org" 
Message-ID: <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 10:16:21 -0000

On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:

> 
> Some protection is necessary; but it isn't too hard - a single-use session
> cache, or a strike register, do protect against the side-channel and DOS
> problems. Combined with a "fail closed" strategy and tickets that are
> scoped to clusters or servers, these techniques do hard-stop the literal
> 0-RTT replays, and they are practical. Many of us run systems like that
> already.

As requirements:

- Clients SHOULD NOT use the same ticket multiple times.
- Clients MUST NOT use the same ticket multiple times for 0-RTT.
- Servers MAY accept the same ticket multiple times.
- Servers MUST NOT accept the same ticket with the same binder multiple
  times for 0-RTT (if any part of ClientHello covered by binder is
  different, one can assume binders are different). This holds even
  across servers (i.e., if server1 accepts 0-RTT with ticket X and
  binder Y, then server2 can not accept 0-RTT with ticket X and binder
  Y).

The "with the same binder" requirement is to deal with the following:

1) Bad client sends 0-RTT with ticket X and in-window age age1.
2) Some days pass...
3) Bad client sends 0-RTT with ticket X and in-window age age2.

Without the "with the same binder", that would mean the server MUST
reject the 0-RTT for 3), which would mean keeping state for days,
which leads to excessive resource usage.

With the "with same binder", the server can time out the state for
1) as soon as the age1 is out-of-window. And then it MAY accept
0-RTT for 3). This will not lead into mass replay possibility for
either 1) nor 3).

The part of assuming binders different if any part covered is
different comes from strong hash requirement TLS 1.3 has.


?


From nobody Sun May 21 15:48:08 2017
Return-Path: 
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 B7959129A9D for ; Sun, 21 May 2017 15:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 pcyJ5iwnOiO8 for ; Sun, 21 May 2017 15:48:05 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20E3129526 for ; Sun, 21 May 2017 15:48:04 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l14so52744996ywk.1 for ; Sun, 21 May 2017 15:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8jQQyLhijYHZaPE6f+hBwDWoId4CANtNFWXBotgz6aY=; b=E4gvRsmoxfFIT4xoQoMmJYJaytZZOffemAcUvfc2ix3JkgOp+mXv7jpxdmm25QPihR 0Ox5V61bE/35rWxpd8gfL/4RMODmC/0vWYGwc5uyafqvTNjWquEIo5VxO5oDOOguJlA8 DxMC/TM7/4nC1g39nT9FAz/qQFl+T4OrHpU60/pjy8Q9Hw4ReG+bwoM3eEHgKDzHwooU b7Y55TtmldioeZFCLuUy2I4A2wBAs6+6yO+/dCdc1t0LDn410cdWqKksyfvLo2azd7zb 60uU4hVGGCVO2E7JhAl2/IRcpm2nbj1kszj1vfDqnGnaGBSikTFWMi81fv2pbOntyzER H3Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8jQQyLhijYHZaPE6f+hBwDWoId4CANtNFWXBotgz6aY=; b=rojVDk7LUC2Ie/Ss6IubzWQbRM80LmnPdJu29BbJIC5BYoX1fIe26mqss3czhdEZ1C x06MnEG+GR2SdJSrbL+/iW4TTJWavkhacp27IzrMPJWhu4pJDzLEYirRNknm9jL7SB6o v4BTVouThJx2IRFYPNI+lQ1wqoi/x0yx6XTjb4HX/IHShz5o2f1GXLXZFoGZRugtDH8K ZKrDTuXvZwgrZ+uSvodO8PvygNvUM2qD0QN5bNooL82BJuCMoS8OV04jgn8ZHtdwxh7G HB/5LA0Y5REFiFTXaJJ/LP/G1oAE6MPSXUIRDpAEBIZPbly2ywv2j1r9T178lD78ZNFZ e4GA==
X-Gm-Message-State: AODbwcASggT9jaQwpI1oa5rJfaJCtl10HQZELFA2zZ90t5i+8y6uwIm7 ULMSp5YYYmfo9wPbwlCPHG41OVxbFRaQ
X-Received: by 10.13.212.1 with SMTP id w1mr15909952ywd.24.1495406884259; Sun, 21 May 2017 15:48:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Sun, 21 May 2017 15:47:22 -0700 (PDT)
In-Reply-To: <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Sun, 21 May 2017 18:47:22 -0400
Message-ID: 
To: Ilari Liusvaara 
Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= ,  "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114fb0f621a3080550108c8d"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 May 2017 22:48:07 -0000

--001a114fb0f621a3080550108c8d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara 
wrote:

> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacC=C3=A1rthaigh wrote:
>
> >
> > Some protection is necessary; but it isn't too hard - a single-use
> session
> > cache, or a strike register, do protect against the side-channel and DO=
S
> > problems. Combined with a "fail closed" strategy and tickets that are
> > scoped to clusters or servers, these techniques do hard-stop the litera=
l
> > 0-RTT replays, and they are practical. Many of us run systems like that
> > already.
>
> As requirements:
>
> - Clients SHOULD NOT use the same ticket multiple times.
>

This is already in the document.



> - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>

I don't understand the purpose of this requirement. As you note below,
servers are ultimately responsible for enforcing it, and it's not clear to
me why clients obeying it makes life easier for the server.



> - Servers MAY accept the same ticket multiple times.
>

This seems implicit.



> - Servers MUST NOT accept the same ticket with the same binder multiple
>   times for 0-RTT (if any part of ClientHello covered by binder is
>   different, one can assume binders are different). This holds even
>   across servers (i.e., if server1 accepts 0-RTT with ticket X and
>   binder Y, then server2 can not accept 0-RTT with ticket X and binder
>   Y).
>

I assume that what you have in mind here is that the server would know
which tickets it was authoritative for anti-replay and would simply reject
0-RTT if it wasn't authoritative? This seems like it would significantly cu=
t
down on mass replays, though it would of course still make application-leve=
l
replay a problem.

I'm happy to write this up as part of the first two techniques. I'd be
interested in hearing from others in the WG what they think about:

1. Requiring it.
2. Whether they still want to retain the stateless technique.

-Ekr

--001a114fb0f621a3080550108c8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacC=C3=A1rthaigh =
wrote:



>

> Some protection is necessary; but it isn't=
 too hard - a single-use session

> cache, or a strike register, do protect against the side-channel and D=
OS

> problems. Combined with a "fail closed" strategy and tickets=
 that are

> scoped to clusters or servers, these techniques do hard-stop the liter=
al

> 0-RTT replays, and they are practical. Many of us run systems like tha=
t

> already.



As requirements:



- Clients SHOULD NOT use the same ticket multiple times.

This is already in the document.

=C2=A0

- Clients MUST NOT use the same ticket multiple times for 0-RTT.

I don't understand the purpose of this requir=
ement. As you note below,
servers are ultimately responsible for =
enforcing it, and it's not clear to
me why clients obeying it=
 makes life easier for the server.

=C2=A0

- Servers MAY accept the same ticket multiple times.
<=
br>
This seems implicit.

=C2=A0

- Servers MUST NOT accept the same ticket with the same binder multiple

=C2=A0 times for 0-RTT (if any part of ClientHello covered by binder is

=C2=A0 different, one can assume binders are different). This holds even
=C2=A0 across servers (i.e., if server1 accepts 0-RTT with ticket X and

=C2=A0 binder Y, then server2 can not accept 0-RTT with ticket X and binder=


=C2=A0 Y).

I assume that what you have =
in mind here is that the server would know
which tickets it was a=
uthoritative for anti-replay and would simply reject
0-RTT if it =
wasn't authoritative? This seems like it would significantly cut
<=
div>down on mass replays, though it would of course still make application-=
level
replay a problem.

I'm happy to=
 write this up as part of the first two techniques. I'd be=C2=A0
<=
div>interested in hearing from others in the WG what they think about:

1. Requiring it.
2. Whether they still want =
to retain the stateless technique.

-Ekr
=




--001a114fb0f621a3080550108c8d--


From nobody Sun May 21 19:28:51 2017
Return-Path: 
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 3B43B1200F1 for ; Sun, 21 May 2017 19:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 2j8V3Gk6E92L for ; Sun, 21 May 2017 19:28:47 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4676E1200C1 for ; Sun, 21 May 2017 19:28:47 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id p143so27363248yba.2 for ; Sun, 21 May 2017 19:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YHjB42H15R2jTeDv1/C43m3c0pqEbivsLzZbiQYmhyo=; b=GiQJJhJzvhwvD0/9hiaX6pW8QvlQuU0kN58MfXhuvrWO6+AF09QTG9G+lV59JUYmfw Dkr4RQTqrJZTPneoLdVtfb+FpmIqPdFzsjT4tU500q+njmIyNBLGZRCxUpW3Gz8XT4Wv Y79xj48gYJgrSeocKsEQotIDK5XOYOb/aarjHO3lK5ntRpmMbZeYLISIPiPP8c1RTxKI 5AKm2YLVh70g9S2hWdoBtBddIaVdoDcK1jcdOHrWp/MCgDgPp3F6iNOozMizGGUJwMuq oBGjAv4nik7BB/iVsR4P5tlHAV1GepxIQhnVBfg7j0D6JxYt3cx1iFkwq28970R/Jzhd MP8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YHjB42H15R2jTeDv1/C43m3c0pqEbivsLzZbiQYmhyo=; b=cyfuzMdmPRv+7TmhZwyrJYflVI1Jj+hI0E1rQfieVWiNN5zmS8FI1jLmYuP44FCxdG iF3IkGTtUrENVrFOqqNGVUIYsFBZFVU3O0tMcRDnD3nQEQ2Y9Zib/JP/StQv1QgMFv8s 7y0IqHNjUrDYxGjz3EJchCbACJJttoI3x3mNTEiqvkC/cjxaHAQaBjcKdkb39PxrXNH1 GQLRkLQZgh+innUasdxAzEZVld3KV1M4KZtF6jiYqI5xHJSqjRI0nimUyUGRqgpPj8a4 6fu9qmIdiQQgHA4218QKn8VpPrz5dnK8z56ZiuyE5Y0Z6wuLLvSP8512eKvlhDhRc/0F BYIA==
X-Gm-Message-State: AODbwcCdPP16r9kmf1tplk4g8fjroDufPLetVnLs4Ky+7YXuYuRcUxkg oRDnsz3xP/q5E8aZKDvvpG21t4Y3F2bj
X-Received: by 10.37.15.213 with SMTP id 204mr17374806ybp.127.1495420126366; Sun, 21 May 2017 19:28:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.97.3 with HTTP; Sun, 21 May 2017 19:28:45 -0700 (PDT)
In-Reply-To: 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi> 
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Sun, 21 May 2017 19:28:45 -0700
Message-ID: 
To: Eric Rescorla 
Cc: Ilari Liusvaara , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f5ae66c3327055013a1a5"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 02:28:49 -0000

--001a113f5ae66c3327055013a1a5
Content-Type: text/plain; charset="UTF-8"

On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla  wrote:
>
> - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>>
>
> I don't understand the purpose of this requirement. As you note below,
> servers are ultimately responsible for enforcing it, and it's not clear to
> me why clients obeying it makes life easier for the server.
>

I think clients should duplicate them sometimes, just to keep servers on
their toes ;-) this is what we talked about maybe being a grease thing ..
if at all.

- Servers MUST NOT accept the same ticket with the same binder multiple
>>   times for 0-RTT (if any part of ClientHello covered by binder is
>>   different, one can assume binders are different). This holds even
>>   across servers (i.e., if server1 accepts 0-RTT with ticket X and
>>   binder Y, then server2 can not accept 0-RTT with ticket X and binder
>>   Y).
>>
>
> I assume that what you have in mind here is that the server would know
> which tickets it was authoritative for anti-replay and would simply reject
> 0-RTT if it wasn't authoritative? This seems like it would significantly
> cut
> down on mass replays, though it would of course still make
> application-level
> replay a problem.
>
> I'm happy to write this up as part of the first two techniques. I'd be
> interested in hearing from others in the WG what they think about:
>
> 1. Requiring it.
> 2. Whether they still want to retain the stateless technique.
>

I'm for requiring it, and for removing the stateless technique ... because
it prevents the side-channel and DOS attacks and those seem like the most
serious ones (and also, the new ones).

So far each case where we've thought "Actually stateless might be ok in
this case" ... like the example of DNS ... turns out not to be safe when
examined more closely (in DNSes case it would compromise privacy because
caches could be probed).

-- 
Colm

--001a113f5ae66c3327055013a1a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <ekr@rtfm.com>=
 wrote:

- Clients MUST NOT use the same ticket multiple times for 0-RTT.

I don't understand the purpose of this=
 requirement. As you note below,
servers are ultimately responsib=
le for enforcing it, and it's not clear to
me why clients obe=
ying it makes life easier for the server.

I think clients should duplicate them sometimes, jus=
t to keep servers on their toes ;-) this is what we talked about maybe bein=
g a grease thing .. if at all.=C2=A0


- Servers MUST NOT accept the same ticket with the same binder multiple

=C2=A0 times for 0-RTT (if any part of ClientHello covered by binder is

=C2=A0 different, one can assume binders are different). This holds even
=C2=A0 across servers (i.e., if server1 accepts 0-RTT with ticket X and

=C2=A0 binder Y, then server2 can not accept 0-RTT with ticket X and binder=


=C2=A0 Y).

I assume that what yo=
u have in mind here is that the server would know
which tickets i=
t was authoritative for anti-replay and would simply reject
0-RTT=
 if it wasn't authoritative? This seems like it would significantly cut=

down on mass replays, though it would of course still make appli=
cation-level
replay a problem.

I'm h=
appy to write this up as part of the first two techniques. I'd be=C2=A0=

interested in hearing from others in the WG what they think abou=
t:

1. Requiring it.
2. Whether they stil=
l want to retain the stateless technique.

I'm for requiring it, and for removing the state=
less technique ... because it prevents the side-channel and DOS attacks and=
 those seem like the most serious ones (and also, the new ones).=C2=A0

So far each case where we've thought "Actuall=
y stateless might be ok in this case" ... like the example of DNS ... =
turns out not to be safe when examined more closely (in DNSes case it would=
 compromise privacy because caches could be probed).=C2=A0
=

-- 
Colm




--001a113f5ae66c3327055013a1a5--


From nobody Sun May 21 22:26:24 2017
Return-Path: 
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 F33C9129B30 for ; Sun, 21 May 2017 22:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 VnNgMR5ONSkJ for ; Sun, 21 May 2017 22:26:21 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC31129B3C for ; Sun, 21 May 2017 22:26:19 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dCfrF-0004UR-1R for tls@ietf.org; Mon, 22 May 2017 07:26:17 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dCfr9-0003Ng-C5 for tls@ietf.org; Mon, 22 May 2017 01:26:15 -0400
Received: (qmail 27739 invoked from network); 22 May 2017 05:26:09 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.111]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 May 2017 05:26:07 -0000
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Eric Rescorla 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>  
Cc: "tls@ietf.org" 
From: Christian Huitema 
Message-ID: 
Date: Sun, 21 May 2017 22:26:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------3E06E92CC622CDB4A6B9E27A"
X-Originating-IP: 168.144.250.230
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpynqmxH7KpPKZAVjX1Se8CRcOb18WfxGyg6Om6u4YYm9YArbdtautoyLzS s/JWDXc5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aInTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0AdUEPptZ 3fLBarnabQfPf7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa0k1QmJ32eA5/D47ikwJamSKsuHVheBSoveD wM1QT+afxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 05:26:23 -0000

This is a multi-part message in MIME format.
--------------3E06E92CC622CDB4A6B9E27A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 5/21/2017 7:28 PM, Colm MacC=E1rthaigh wrote:
>
>
> On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla  > wrote:
>
>
>
>     ...
>
>     I'm happy to write this up as part of the first two techniques.
>     I'd be=20
>     interested in hearing from others in the WG what they think about:
>
>     1. Requiring it.
>     2. Whether they still want to retain the stateless technique.
>
>
> I'm for requiring it, and for removing the stateless technique ...
> because it prevents the side-channel and DOS attacks and those seem
> like the most serious ones (and also, the new ones).=20
>
> So far each case where we've thought "Actually stateless might be ok
> in this case" ... like the example of DNS ... turns out not to be safe
> when examined more closely (in DNSes case it would compromise privacy
> because caches could be probed).=20

I would much rather see this specified within TLS than within the
application. Specifically, I would not like to see application making
statements that they can only use 0-RTT if the TLS software that they
use does implement "at most once" limitations on 0-RTT tickets. You
know, pretty much like those security sections that explain than a
careless application will be safe if it runs over IPSEC. Maybe with some
RFC 6919 language.

-- Christian Huitema

--------------3E06E92CC622CDB4A6B9E27A
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 5/21/2017 7:28 PM, Colm MacCárthaigh
      wrote:

    

    

      


        


          
On Sun, May 21, 2017 at 3:47 PM, Eric
            Rescorla <ekr@rtfm.com>
            wrote:
            

              

                

                  

                      


                      

                      


                      

                    
                    
...
                      


                      

                      
I'm happy to write this up as part of the
                        first two techniques. I'd be 

                      
interested in hearing from others in the WG
                        what they think about:

                      


                      

                      
1. Requiring it.

                      
2. Whether they still want to retain the
                        stateless technique.

                    

                  

                

              

            

            

              

                

              

            

            


            

            
I'm for requiring it, and for removing the stateless
              technique ... because it prevents the side-channel and DOS
              attacks and those seem like the most serious ones (and
              also, the new ones). 

            


            

            
So far each case where we've thought "Actually
              stateless might be ok in this case" ... like the example
              of DNS ... turns out not to be safe when examined more
              closely (in DNSes case it would compromise privacy because
              caches could be probed). 

          

        

      

    

    

    I would much rather see this specified within TLS than within the
    application. Specifically, I would not like to see application
    making statements that they can only use 0-RTT if the TLS software
    that they use does implement "at most once" limitations on 0-RTT
    tickets. You know, pretty much like those security sections that
    explain than a careless application will be safe if it runs over
    IPSEC. Maybe with some RFC 6919 language.

    

    -- Christian Huitema

  


--------------3E06E92CC622CDB4A6B9E27A--


From nobody Sun May 21 22:52:13 2017
Return-Path: 
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 02487129B3A for ; Sun, 21 May 2017 22:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YAgEpbV_pLnk for ; Sun, 21 May 2017 22:52:09 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8C91296B3 for ; Sun, 21 May 2017 22:52:08 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id w10so148851773oif.0 for ; Sun, 21 May 2017 22:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=rP+aOYR4m72Xmu9xde75IQxoVF5G7M6rh7uzvDyUgng=; b=kX3GjIDRa8uHgrUBIQSKPHCMa+fXA483NNitCt7jKlWNtio/YrcbSLD6dBgS46ZATn stuezRkBoe3ki0y4eFg+jbn7/2MIRpP/A5R138MngFULJMM2RFswXaq0CMqD6+XDqpp1 zWsQBH1TpHSoCY6E+rQZ0zQqaYHZx/fSQS5bfQpcUyiFAXkRGlNB1rLc3ovv5+LW5eWr BLu8tU6rnmxqt8pVvMf3CrE8AcWNWDX/9oAgB3pKsG/1R9alHqBBc1oB4spj20iDPkmV Ylw7LavAtwIXTYrxEuOzIJQ66jSi//WHCai/GHN9K0nq2IrPVB+WHLt3bBo1X+VOxovu OPrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=rP+aOYR4m72Xmu9xde75IQxoVF5G7M6rh7uzvDyUgng=; b=n4ALH6msZRovc3cihD4X0tdd5ieDCdnxgfWSXFoC3UaUpLQyF4KSCkz3vqJdRQwvB4 9NuBWDiWiAVCUEWB3sGqyxDm3pD/nmPOzp6xEBDAgFbt+aCM809XDfwmQq1KeQNUSd6J 1aI9FbbJeT/DgaEdyFyaKn6G88hIqW5mL8m1twprVm27FkokqawT+Jd6K5cLcKwfjtWb 6dNU93Z0IY2nknZNIJj0d6n4iLIoAD6BXt9tvVUK7maVbkV36kr6HkvKN+A6P42fvEiK 7SRbj+xvjR9jG7qz4Nknj6Aw6BCdcDhAgIPwq6gBMtatPFixuvDwygdqytv/doTTpne7 Knyw==
X-Gm-Message-State: AODbwcDVIwmtGu/1US+4ejYcehglKOceSMutUHauXENVnCBdGQZfD/Sh MobaPVOZAHKl8J1zmxM55oYk9dYO1A==
X-Received: by 10.157.16.55 with SMTP id h52mr10201564ote.218.1495432328358; Sun, 21 May 2017 22:52:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.56.24 with HTTP; Sun, 21 May 2017 22:52:07 -0700 (PDT)
From: Sankalp Bagaria 
Date: Mon, 22 May 2017 11:22:07 +0530
Message-ID: 
To: tls@ietf.org
Cc: sankalp , Balaji Rajendran 
Content-Type: multipart/alternative; boundary="001a113d0342b7afda0550167836"
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-00.txt (internet-drafts@ietf.org)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 05:52:11 -0000

--001a113d0342b7afda0550167836
Content-Type: text/plain; charset="UTF-8"

Hi,

I have a couple of questions:
1) How will the out-of-band request for certificate be sent by the server/
client ?
What format will be used ? (Only Reply's format is given in draft)
2a) If certificate verification is unsuccessful, will the existing
connection also be
dropped or will it be continued ?
2b) If certificate verification is successful, how will the state of the
connection
change ? Will there be a re-direction to new entity ? If yes, how will that
be
achieved ?

Regards,
Sankalp Bagaria.


>
> ------------------------------
>
> Message: 3
> Date: Thu, 18 May 2017 14:04:38 -0700
> From: internet-drafts@ietf.org
> To: 
> Cc: tls@ietf.org
> Subject: [TLS] I-D Action:
>         draft-ietf-tls-exported-authenticator-00.txt
> Message-ID: <149514147857.6720.16783609697509356369@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security of the IETF.
>
>         Title           : Exported Authenticators in TLS
>         Author          : Nick Sullivan
>         Filename        : draft-ietf-tls-exported-authenticator-00.txt
>         Pages           : 6
>         Date            : 2017-05-18
>
> Abstract:
>    This document describes a mechanism in Transport Layer Security (TLS)
>    to provide an exportable proof of ownership of a certificate that can
>    be transmitted out of band and verified by the other party.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-00
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-
> exported-authenticator-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
>

--001a113d0342b7afda0550167836
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I have a couple of questions:
=

1) How will the out-of-band request for certificate be sent by the ser=
ver/ client ?
What format will be used ? (Only Reply's format=
 is given in draft)
2a) If certificate verification is unsuccessf=
ul, will the existing connection also be=C2=A0
dropped or will it=
 be continued ?
2b) If certificate verification is successful, ho=
w will the state of the connection
change ? Will there be a re-di=
rection to new entity ? If yes, how will that be
achieved ?
=


Regards,
Sankalp Bagaria.




------------------------------



Message: 3

Date: Thu, 18 May 2017 14:04:38 -0700

From: internet-drafts@ietf.org<=
/a>

To: <i-d-announce@ietf.org&=
gt;

Cc: tls@ietf.org

Subject: [TLS] I-D Action:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-tls-exported-authenticator-00.t=
xt

Message-ID: <149514147857.6720.16783609697509356369@ietfa.amsl.c=
om>

Content-Type: text/plain; charset=3D"utf-8"





A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Transport Layer Security of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Exported Authenticators in TLS

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Nick=
 Sullivan

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-tls-exported-authenticator-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-05-18



Abstract:

=C2=A0 =C2=A0This document describes a mechanism in Transport Layer Securit=
y (TLS)

=C2=A0 =C2=A0to provide an exportable proof of ownership of a certificate t=
hat can

=C2=A0 =C2=A0be transmitted out of band and verified by the other party.




The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/=
doc/draft-ietf-tls-exported-authenticator/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-00

https://datatracker.ie=
tf.org/doc/html/draft-ietf-tls-exported-authenticator-00





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/








--001a113d0342b7afda0550167836--


From nobody Sun May 21 23:00:08 2017
Return-Path: 
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 05EE5129B49 for ; Sun, 21 May 2017 23:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oviomQupA7GT for ; Sun, 21 May 2017 23:00:04 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD619129B33 for ; Sun, 21 May 2017 23:00:03 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id h4so24785900lfj.3 for ; Sun, 21 May 2017 23:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZAfsJT2tqonqqO1ugXR86LAGthDBdaDpfrueH+RPEwc=; b=PYUEQGV/r1oEZsBCxC29W2/wgcHfBCH8lMmMTY2PLZscg+2B4T+UW/+mM3NQ7tWcwo hfFrRVQ3C9XaPEQePXmsQ+J3jt/38gXQJpUC4jGhBbntJRI8y3u8AdDlMMZQLMO3bghb mLJbXSijteftyQEsWDOL6PMXhagOI1dkawDKEigCIl2CvIHiLB8ukgad/anv9H/6WagM xh5Qr2gtDvOKX/xjWR21PIafZ4hEnqwrNKHKRZVeVFGvgmKGbajgBzeQoqDbjcqr5iye KCUT0hYZVbXsi4vp367IJABUgWEYmvnloP7W553MveMpYIrsHxYa0Czo9M7/XKnrX9vl 7eCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZAfsJT2tqonqqO1ugXR86LAGthDBdaDpfrueH+RPEwc=; b=gWWWgjF6MIpYj1eBZy8VAKEhOUDDLkOUkHpgrrc6rCd++jV4V/d6F/ZWp4mZ6JSa14 3xyUSquEIFnqvi+woostYPlB4lOdRlxv49SMOgSsiDq8pEPzV+7QxP996lKI8mcF+EtE 3eFuar3mD0NL4uAxEfDiumv4afBseOSbwfX8GwHJpgqkcp35z7EM2uPCSK8Odtavv3OY PVFvesRYurRS98ylvP0sjH1OxsGs4ve9OyE7SobbGsFaLcyszLcORy9Fw+8w1roUsWJw vGYH1dz2NL9sC44ziOKfe+bW9OcOZSM3DH5DWS5QUUgCerx8PqZl8Yfe1kRdfibF2dUW MN+Q==
X-Gm-Message-State: AODbwcConG+wvLmQdVxTPKuB/WWln0+ABJlYfyYn9Xp8qe1QEnkst+94 7droDk37zzwvrzTpUPtbNpVOSizmMg==
X-Received: by 10.46.76.1 with SMTP id z1mr4601909lja.128.1495432801758; Sun, 21 May 2017 23:00:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Sun, 21 May 2017 23:00:01 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Mon, 22 May 2017 16:00:01 +1000
Message-ID: 
To: Sankalp Bagaria 
Cc: "tls@ietf.org" , Balaji Rajendran , sankalp 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-00.txt (internet-drafts@ietf.org)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 06:00:06 -0000

This defines a tool, in the same way that RFC 5705 does.  See
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
for a use of that tool.

On 22 May 2017 at 15:52, Sankalp Bagaria  wrote:
> Hi,
>
> I have a couple of questions:
> 1) How will the out-of-band request for certificate be sent by the server/
> client ?
> What format will be used ? (Only Reply's format is given in draft)
> 2a) If certificate verification is unsuccessful, will the existing
> connection also be
> dropped or will it be continued ?
> 2b) If certificate verification is successful, how will the state of the
> connection
> change ? Will there be a re-direction to new entity ? If yes, how will that
> be
> achieved ?
>
> Regards,
> Sankalp Bagaria.
>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 18 May 2017 14:04:38 -0700
>> From: internet-drafts@ietf.org
>> To: 
>> Cc: tls@ietf.org
>> Subject: [TLS] I-D Action:
>>         draft-ietf-tls-exported-authenticator-00.txt
>> Message-ID: <149514147857.6720.16783609697509356369@ietfa.amsl.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Layer Security of the IETF.
>>
>>         Title           : Exported Authenticators in TLS
>>         Author          : Nick Sullivan
>>         Filename        : draft-ietf-tls-exported-authenticator-00.txt
>>         Pages           : 6
>>         Date            : 2017-05-18
>>
>> Abstract:
>>    This document describes a mechanism in Transport Layer Security (TLS)
>>    to provide an exportable proof of ownership of a certificate that can
>>    be transmitted out of band and verified by the other party.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-00
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-00
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Mon May 22 07:50:17 2017
Return-Path: 
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 7022612EADB for ; Mon, 22 May 2017 07:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 QUCHKOojaIrY for ; Mon, 22 May 2017 07:50:14 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAF7127078 for ; Mon, 22 May 2017 07:50:14 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 0D55D20051C29; Mon, 22 May 2017 07:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=mcEolSDH2qMqIBjN79Nlzuj2Qjs =; b=G9esvAjhMnoP3R8ZPFV73lJHQYOXjeKzZkKKvxeUNn7oneXrQ4l1hmgSOCN WJv3ytG0dLloeRMzPDLFugTKVaoEB2Bg9061RaQU1DmiE3z3dia9tmVxsFBj9G8b znMpAyJuZsBTYtvUmYO5CwTfWeT3bja0BbM2qcFq2nhjN6W4=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id BAB5B20051C26; Mon, 22 May 2017 07:50:13 -0700 (PDT)
Date: Mon, 22 May 2017 09:50:09 -0500
From: Nico Williams 
To: TLS WG 
Message-ID: <20170522145008.GN10188@localhost>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 14:50:15 -0000

On Sat, May 20, 2017 at 01:55:07AM -0400, Viktor Dukhovni wrote:
> > On May 20, 2017, at 1:41 AM, Nico Williams  wrote:
> > "When using TLS to authenticate the server, certificate signature
> > algorithms weaker than 
> > MUST NOT be used."
> 
> Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX)
> to authenticate... (the [server or client?]).  TLS is just the transport
> after all.

No, I meant what I said, as in "as opposed to using TLS
opportunistically".

Nico
-- 


From nobody Mon May 22 08:35:37 2017
Return-Path: 
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 0020412422F for ; Mon, 22 May 2017 08:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-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 WgdYo818wGNY for ; Mon, 22 May 2017 08:35:33 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6D51200CF for ; Mon, 22 May 2017 08:35:32 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 16A4E7A32F1 for ; Mon, 22 May 2017 15:35:32 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <20170522145008.GN10188@localhost>
Date: Mon, 22 May 2017 11:35:31 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <2D45C128-BF84-481C-AC28-87A9793B5E00@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org> <20170522145008.GN10188@localhost>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:35:35 -0000

> On May 22, 2017, at 10:50 AM, Nico Williams  =
wrote:
>=20
>>> "When using TLS to authenticate the server, certificate signature
>>> algorithms weaker than 
>>> MUST NOT be used."
>>=20
>> Minor correction, perhaps you really mean to say "when using RFC5280 =
(PKIX)
>> to authenticate... (the [server or client?]).  TLS is just the =
transport
>> after all.
>=20
> No, I meant what I said, as in "as opposed to using TLS
> opportunistically".

While we are quibbling over terminology and not substance:

Note that opportunistically !=3D unauthenticated.  Opportunistic DANE =
TLS
still authenticates when the peer has TLSA records, and even uses PKIX
when the TLSA record certificate usage is DANE-TA(2).  And sufficiently
strong algorithms are desirable even under those conditions:

   =
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_clien=
t.c#L955

So it seems the phrase "using TLS to authenticate" in fact means using
RFC5280 (PKIX) to authenticate the peer via its signature over its
Cerificate Verify message:

	=
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.3

The phrase used to describe the situation in that section of the draft =
is
"when authenticating via a certificate", which is part of the story, =
what
would need to be added to that to get the right context for setting a =
floor
on acceptable certificate signature algorithms is something along the =
lines
of "with PKIX chain verification".

Still, all of this belongs in an update of RFC5280, but if we just can't
resist saying something here along the lines you suggest then it might =
be:

"When peer authentication is via a certificate, with RFC5280 (PKIX) =
chain
verification, certificate signature algorithms weaker than  MUST NOT be trusted."

I carefully say "MUST NOT be trusted" rather than "MUST NOT be used", it =
is
the relying party that decides what minimal algorithm strength is =
acceptable.
The peer may send whatever chain it has (lacking one that meets the =
advertised
supported signature algorithms).

Peers that desire broadly interoperable RFC5280 authentication via their
certificate chain should of course be configured to present chains that =
avoid
deprecated certificate signature algorithms (except in self-signatures =
of
trust-anchors).

--=20
	Viktor.


From nobody Mon May 22 08:53:16 2017
Return-Path: 
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 42B81124D85 for ; Mon, 22 May 2017 08:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SIQLae5eFHMf for ; Mon, 22 May 2017 08:53:12 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6031200E5 for ; Mon, 22 May 2017 08:53:12 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 38DB67A32F1 for ; Mon, 22 May 2017 15:53:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <2D45C128-BF84-481C-AC28-87A9793B5E00@dukhovni.org>
Date: Mon, 22 May 2017 11:53:10 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org> <20170522145008.GN10188@localhost> <2D45C128-BF84-481C-AC28-87A9793B5E00@dukhovni.org>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:53:14 -0000

> On May 22, 2017, at 11:35 AM, Viktor Dukhovni  =
wrote:
>=20
> Still, all of this belongs in an update of RFC5280, but if we just =
can't
> resist saying something here along the lines you suggest then it might =
be:
>=20
> "When peer authentication is via a certificate, with RFC5280 (PKIX) =
chain
> verification, certificate signature algorithms weaker than  acceptable signature algs here> MUST NOT be trusted."

I want to reiterate, that the simplest approach, and the one that I
would prefer, is not to repurpose the TLS 1.3 specification to carry
language that properly belongs in PKIX.  The "MUST NOT" language
related to MD5 and SHA-1 in *certificate signatures* should be removed.

--=20
	Viktor.


From nobody Mon May 22 10:06:56 2017
Return-Path: 
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 079B2126CF6 for ; Mon, 22 May 2017 10:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 dL_KQJbiIt0Z for ; Mon, 22 May 2017 10:06:53 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C061201F2 for ; Mon, 22 May 2017 10:06:53 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4MGv1R3016289; Mon, 22 May 2017 18:06:48 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=feTyB1MLUXJp/c/yfnni6YdtNNhzlFOfTQ9soNnvfi4=; b=HSHRLD00+huZoRQiizCzP0oFx2tI3ejyx62PdlEE2WSZXu8KoWpgOiAa1d9IrdGG1fpI YyiTCq90KjzlRkUQKTCC2j9lnqj/MmEFwiWRtAz2Ax1/MvY9PN9xfUuOfMh/XVgJx2Vm WwEGU5BFL6SzloSVuuR0RwsJPfk11cgQL2cPANZrSgwh7eA0d6eoS+puSW32f5Cf4Ro1 AJ/P/mVJSjVN5Efql80E/z6j3yPi+X3C06Sz0tXc6CZz+ha1X0lQQDoVOXjo9iMkHMiA L4NqjZ5gbBi2GvqMh3q1vfCc7JlWDB2WBuQ6tnv1T7fjQkVPWOnlROntxZZ6rfLhntl6 5Q== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2aje78btvj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 May 2017 18:06:48 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4MH6dJ4026783; Mon, 22 May 2017 13:06:47 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ajh4up4kw-1; Mon, 22 May 2017 13:06:47 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 72E2E1FC73; Mon, 22 May 2017 17:06:47 +0000 (GMT)
To: TLS WG , Viktor Dukhovni 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>
From: Benjamin Kaduk 
Message-ID: 
Date: Mon, 22 May 2017 12:06:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>
Content-Type: multipart/alternative; boundary="------------0AE0384D8C92110539DD1F5F"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220090
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220089
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:06:55 -0000

This is a multi-part message in MIME format.
--------------0AE0384D8C92110539DD1F5F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/20/2017 12:55 AM, Viktor Dukhovni wrote:
>> On May 20, 2017, at 1:41 AM, Nico Williams  wrote:
>>
>> "When using TLS to authenticate the server, certificate signature
>> algorithms weaker than 
>> MUST NOT be used."
> Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX)
> to authenticate... (the [server or client?]).  TLS is just the transport
> after all.
>

Given the apparent strength of opinion against removing these supposed
restrictions entirely, it seems like this text (or something similar) is
probably the best we can do.

-Ben

--------------0AE0384D8C92110539DD1F5F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 05/20/2017 12:55 AM, Viktor Dukhovni wrote:

    

      

      

        
On May 20, 2017, at 1:41 AM, Nico Williams <nico@cryptonector.com> wrote:

"When using TLS to authenticate the server, certificate signature
algorithms weaker than <list of weakest acceptable signature algs here>
MUST NOT be used."


      

      
Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX)
to authenticate... (the [server or client?]).  TLS is just the transport
after all.



    

    

    Given the apparent strength of opinion against removing these
    supposed restrictions entirely, it seems like this text (or
    something similar) is probably the best we can do.

    

    -Ben

  


--------------0AE0384D8C92110539DD1F5F--


From nobody Mon May 22 10:12:27 2017
Return-Path: 
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 CCB3A12EB30 for ; Mon, 22 May 2017 10:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level: 
X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=pvPyNqpH; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=OnQ7mnj8
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 NDT5ZsR0mX1L for ; Mon, 22 May 2017 10:12:24 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B05126C23 for ; Mon, 22 May 2017 10:12:24 -0700 (PDT)
Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4MH9tB8015354; Mon, 22 May 2017 10:12:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=uJ36TymipTgbwDtH07ehlRnP2lFZap/P8SFXxamoU0U=; b=pvPyNqpHTR3+Tr0HCSVuj5he38MA0+5lqi3ye+ZidLq/GR3SkbvJ5wCxHzXZj79QyRL2 eg00MnkDpTNKNz5SDcpPaq6fW0UXm3bAfg7AiV920ZkMwdCTVG1lpHfBZGYq4y0cXydI iY3aLFfAG0xp2V46uB/REaPCkQXxkToz6nc= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2am22t8j58-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 May 2017 10:12:22 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.28) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 22 May 2017 13:12:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=uJ36TymipTgbwDtH07ehlRnP2lFZap/P8SFXxamoU0U=; b=OnQ7mnj8sGPduohmfm3HiUN8OukIJ7eioJOoUYoglzoVk5OnosBf7HmlOvST5Juw2UdZcRFP1kdktdTdUR9sTwb01SH3EHNacd4iK17PrXJV1k1+SgrQXCsSSGuvwN4UP8glogkFW0jvjv+r2EnHmvnI32YutrIwraTV0EcVYxc=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Mon, 22 May 2017 17:12:19 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.1101.019; Mon, 22 May 2017 17:12:19 +0000
From: Kyle Nekritz 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Eric Rescorla 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NWfzhsEfLgEUy3mG3N+R1DLqHjghwAgAAB3wCAAABtgIABK3OAgBMVs4CAA79FgIAAdzaAgAEhiwCAAmQwAIAAPdqAgADlUOA=
Date: Mon, 22 May 2017 17:12:19 +0000
Message-ID: 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none;allcosts.net; dmarc=none action=none header.from=fb.com;
x-originating-ip: [2620:10d:c091:200::4:3a71]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 7:UKcVxpfvgd2PPN3HwKpYrzm+FLTz6YyYM5prMYZBkQ60UGZ7VV1D/FfNMSV3Bclh4L66UOJfJ0ApCw950YD9aaRKZDqCw/GT5jfxQK2V8RXm6/0EhxJZrSDkEMFERf9kw4emd0bwYOdH/KfbgP5vF5nXfjvvv0k21Clfja/brE5Oyo51VA9bhVDN+hFmIkDhnDiG/Rh9MKLgFs2LLcPyIQLfMmJUk30CAsBLjr5e1Mvr4vGlIxwcaELw0iK/b2vKeSJ5uU9nAxfSyP/d7nkD7cwhLqMmWEXkQiBOLZ7PJbPFTWWYPoQp3/rzSBrt1jzDCdaHJ2m7p5LRlC0d54Ia8A==; 20:Le+DK2kHyQIbcKNzUoMqHhTJ7wVeBz0xjqqyci2KwgYoKJdBduvL6XXU0gYdSXt65UafnVIa/8bXt/GZ9Y8AwKnTTOUqtmgm7bVniEanmouFMxfzPtzRcO/3ArVmorEtSNhWmd7YRNOdRjhDbf5CjwlvdUCZzdijsmbZ9WYOEzQ=
x-ms-traffictypediagnostic: MWHPR15MB1182:
x-ms-office365-filtering-correlation-id: b08abe49-6a0c-468e-e761-08d4a135b426
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1182; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182; 
x-forefront-prvs: 03152A99FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39450400003)(39400400002)(39850400002)(377454003)(24454002)(54356999)(46360400001)(5660300001)(74316002)(3660700001)(7736002)(3280700002)(76176999)(50986999)(53546009)(93886004)(38730400002)(4326008)(99286003)(54896002)(53936002)(9686003)(10710500007)(236005)(55016002)(33656002)(6306002)(6246003)(2906002)(122556002)(8936002)(2900100001)(19609705001)(2950100002)(6506006)(77096006)(229853002)(6436002)(478600001)(7696004)(81166006)(25786009)(189998001)(7110500001)(102836003)(15650500001)(6116002)(2420400007)(86362001)(8676002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182F59E2B60534CB20EC9C4AFF80MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 17:12:19.1427 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:12:27 -0000

--_000_MWHPR15MB1182F59E2B60534CB20EC9C4AFF80MWHPR15MB1182namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIHN0YXRlbGVzcyB0ZWNobmlxdWUgY2VydGFpbmx5IGRvZXNu4oCZdCBzb2x2ZSBhbGwgaXNz
dWVzIHdpdGggcmVwbGF5LiBOZWl0aGVyIGRvIHRoZSBvdGhlciB0ZWNobmlxdWVzLCB1bmxlc3Mg
YSBmYWlybHkgdW5yZWFsaXN0aWMgKGltbywgaW4gbW9zdCB1c2UgY2FzZXMpIHJldHJ5IHN0cmF0
ZWd5IGlzIHVzZWQuIEJ1dCB0aGUgc3RhdGVsZXNzIHRlY2huaXF1ZSBpcyBkZWZpbml0ZWx5IGFu
IGltcHJvdmVtZW50IG92ZXIgbm8gYW50aS1yZXBsYXkgbWVjaGFuaXNtIGF0IGFsbCAoZm9yIGlu
c3RhbmNlIGl0IHJlZHVjZXMgdGhlIHBvc3NpYmxlIG51bWJlciBvZiByb3VuZHMgb2YgYSBjYWNo
ZSBwcm9iaW5nIGF0dGFjaywgYXNzdW1pbmcgdGhlIGNhY2hlIFRUTCA+IHJlcGxheSB3aW5kb3cp
LiBXaGljaCBtZWNoYW5pc21zIHRvIHVzZSwgYW5kIHdoZXRoZXIgdG8gZW5hYmxlIDAtUlRUIGlu
IHRoZSBmaXJzdCBwbGFjZSAob3IgUFNLIG1vZGUgYXQgYWxsKSwgc2hvdWxkIGJlIGRlY2lkZWQg
Y29uc2lkZXJpbmcgdGhlIHRyYWRlb2ZmIGJldHdlZW4gc2VjdXJpdHkvcGVyZm9ybWFuY2UvaW1w
bGVtZW50YXRpb24gY29uc3RyYWludHMsIGV0Yy4gSW4gdGhlIGNhc2Ugb2YgRE5TLCBtb3N0IERO
UyBzZWN1cml0eSBwcm90b2NvbHMgKGRuc3NlYywgZXRjLikgZG8gYWxsb3cgdGhpcyBraW5kIG9m
IHJlcGxheSBzbyBJIHRoaW5rIGl0IGlzIGEgcHJldHR5IHJlYXNvbmFibGUgdHJhZGVvZmYgdG8g
Y29uc2lkZXIuDQoNCkFkZGl0aW9uYWxseSwgSSB0aGluayB0aGUgc3RhdGVsZXNzIHRlY2huaXF1
ZSBpcyBxdWl0ZSB1c2VmdWwgYXMgYSBkZWZlbnNlLWluLWRlcHRoIG1lY2hhbmlzbS4gSSBoaWdo
bHkgZG91YnQgYWxsIGRlcGxveW1lbnRzIHdpbGwgZW5kIHVwIGNvcnJlY3RseSBpbXBsZW1lbnRp
bmcgYSB0aG9yb3VnaCBhbnRpLXJlcGxheSBtZWNoYW5pc20gKHdoZXRoZXIgYWNjaWRlbnRhbGx5
IG9yIHdpbGxmdWxseSkuIFRoZSBzdGF0ZWxlc3MgbWV0aG9kIGlzIHZlcnkgY2hlYXAsIGFuZCBj
YW4gYmUgaW1wbGVtZW50ZWQgZW50aXJlbHkgd2l0aGluIGEgVExTIGxpYnJhcnkgZXZlbiBpbiBh
IGRpc3RyaWJ1dGVkIHNldHVwLCBvbmx5IHJlcXVpcmluZyBhY2Nlc3MgdG8gYW4gYWNjdXJhdGUg
Y2xvY2suIEnigJlkIG11Y2ggcmF0aGVyIGRlcGxveW1lbnRzIHdpdGhvdXQgYSByb2J1c3QgYW5k
IGNvcnJlY3QgYW50aS1yZXBsYXkgbWVjaGFuaXNtIGJyZWFrIGRvd24gdG8gYWxsb3dpbmcgcmVw
bGF5IG92ZXIgYSBudW1iZXIgb2Ygc2Vjb25kcywgcmF0aGVyIHRoYW4gZGF5cyAob3IgbG9uZ2Vy
KS4NCg0KS3lsZQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIENvbG0gTWFjQ8OhcnRoYWlnaA0KU2VudDogU3VuZGF5LCBNYXkgMjEsIDIwMTcg
MTA6MjkgUE0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+DQpDYzogdGxzQGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogW1RMU10gU2VjdXJpdHkgcmV2aWV3IG9mIFRMUzEuMyAwLVJUVA0K
DQoNCg0KT24gU3VuLCBNYXkgMjEsIDIwMTcgYXQgMzo0NyBQTSwgRXJpYyBSZXNjb3JsYSA8ZWty
QHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCi0gQ2xpZW50cyBNVVNUIE5P
VCB1c2UgdGhlIHNhbWUgdGlja2V0IG11bHRpcGxlIHRpbWVzIGZvciAwLVJUVC4NCg0KSSBkb24n
dCB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoaXMgcmVxdWlyZW1lbnQuIEFzIHlvdSBub3Rl
IGJlbG93LA0Kc2VydmVycyBhcmUgdWx0aW1hdGVseSByZXNwb25zaWJsZSBmb3IgZW5mb3JjaW5n
IGl0LCBhbmQgaXQncyBub3QgY2xlYXIgdG8NCm1lIHdoeSBjbGllbnRzIG9iZXlpbmcgaXQgbWFr
ZXMgbGlmZSBlYXNpZXIgZm9yIHRoZSBzZXJ2ZXIuDQoNCkkgdGhpbmsgY2xpZW50cyBzaG91bGQg
ZHVwbGljYXRlIHRoZW0gc29tZXRpbWVzLCBqdXN0IHRvIGtlZXAgc2VydmVycyBvbiB0aGVpciB0
b2VzIDstKSB0aGlzIGlzIHdoYXQgd2UgdGFsa2VkIGFib3V0IG1heWJlIGJlaW5nIGEgZ3JlYXNl
IHRoaW5nIC4uIGlmIGF0IGFsbC4NCg0KLSBTZXJ2ZXJzIE1VU1QgTk9UIGFjY2VwdCB0aGUgc2Ft
ZSB0aWNrZXQgd2l0aCB0aGUgc2FtZSBiaW5kZXIgbXVsdGlwbGUNCiAgdGltZXMgZm9yIDAtUlRU
IChpZiBhbnkgcGFydCBvZiBDbGllbnRIZWxsbyBjb3ZlcmVkIGJ5IGJpbmRlciBpcw0KICBkaWZm
ZXJlbnQsIG9uZSBjYW4gYXNzdW1lIGJpbmRlcnMgYXJlIGRpZmZlcmVudCkuIFRoaXMgaG9sZHMg
ZXZlbg0KICBhY3Jvc3Mgc2VydmVycyAoaS5lLiwgaWYgc2VydmVyMSBhY2NlcHRzIDAtUlRUIHdp
dGggdGlja2V0IFggYW5kDQogIGJpbmRlciBZLCB0aGVuIHNlcnZlcjIgY2FuIG5vdCBhY2NlcHQg
MC1SVFQgd2l0aCB0aWNrZXQgWCBhbmQgYmluZGVyDQogIFkpLg0KDQpJIGFzc3VtZSB0aGF0IHdo
YXQgeW91IGhhdmUgaW4gbWluZCBoZXJlIGlzIHRoYXQgdGhlIHNlcnZlciB3b3VsZCBrbm93DQp3
aGljaCB0aWNrZXRzIGl0IHdhcyBhdXRob3JpdGF0aXZlIGZvciBhbnRpLXJlcGxheSBhbmQgd291
bGQgc2ltcGx5IHJlamVjdA0KMC1SVFQgaWYgaXQgd2Fzbid0IGF1dGhvcml0YXRpdmU/IFRoaXMg
c2VlbXMgbGlrZSBpdCB3b3VsZCBzaWduaWZpY2FudGx5IGN1dA0KZG93biBvbiBtYXNzIHJlcGxh
eXMsIHRob3VnaCBpdCB3b3VsZCBvZiBjb3Vyc2Ugc3RpbGwgbWFrZSBhcHBsaWNhdGlvbi1sZXZl
bA0KcmVwbGF5IGEgcHJvYmxlbS4NCg0KSSdtIGhhcHB5IHRvIHdyaXRlIHRoaXMgdXAgYXMgcGFy
dCBvZiB0aGUgZmlyc3QgdHdvIHRlY2huaXF1ZXMuIEknZCBiZQ0KaW50ZXJlc3RlZCBpbiBoZWFy
aW5nIGZyb20gb3RoZXJzIGluIHRoZSBXRyB3aGF0IHRoZXkgdGhpbmsgYWJvdXQ6DQoNCjEuIFJl
cXVpcmluZyBpdC4NCjIuIFdoZXRoZXIgdGhleSBzdGlsbCB3YW50IHRvIHJldGFpbiB0aGUgc3Rh
dGVsZXNzIHRlY2huaXF1ZS4NCg0KSSdtIGZvciByZXF1aXJpbmcgaXQsIGFuZCBmb3IgcmVtb3Zp
bmcgdGhlIHN0YXRlbGVzcyB0ZWNobmlxdWUgLi4uIGJlY2F1c2UgaXQgcHJldmVudHMgdGhlIHNp
ZGUtY2hhbm5lbCBhbmQgRE9TIGF0dGFja3MgYW5kIHRob3NlIHNlZW0gbGlrZSB0aGUgbW9zdCBz
ZXJpb3VzIG9uZXMgKGFuZCBhbHNvLCB0aGUgbmV3IG9uZXMpLg0KDQpTbyBmYXIgZWFjaCBjYXNl
IHdoZXJlIHdlJ3ZlIHRob3VnaHQgIkFjdHVhbGx5IHN0YXRlbGVzcyBtaWdodCBiZSBvayBpbiB0
aGlzIGNhc2UiIC4uLiBsaWtlIHRoZSBleGFtcGxlIG9mIEROUyAuLi4gdHVybnMgb3V0IG5vdCB0
byBiZSBzYWZlIHdoZW4gZXhhbWluZWQgbW9yZSBjbG9zZWx5IChpbiBETlNlcyBjYXNlIGl0IHdv
dWxkIGNvbXByb21pc2UgcHJpdmFjeSBiZWNhdXNlIGNhY2hlcyBjb3VsZCBiZSBwcm9iZWQpLg0K
DQotLQ0KQ29sbQ0K

--_000_MWHPR15MB1182F59E2B60534CB20EC9C4AFF80MWHPR15MB1182namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUg
c3RhdGVsZXNzIHRlY2huaXF1ZSBjZXJ0YWlubHkgZG9lc27igJl0IHNvbHZlIGFsbCBpc3N1ZXMg
d2l0aCByZXBsYXkuIE5laXRoZXIgZG8gdGhlIG90aGVyIHRlY2huaXF1ZXMsIHVubGVzcyBhIGZh
aXJseSB1bnJlYWxpc3RpYyAoaW1vLCBpbiBtb3N0IHVzZSBjYXNlcykNCiByZXRyeSBzdHJhdGVn
eSBpcyB1c2VkLiBCdXQgdGhlIHN0YXRlbGVzcyB0ZWNobmlxdWUgaXMgZGVmaW5pdGVseSBhbiBp
bXByb3ZlbWVudCBvdmVyIG5vIGFudGktcmVwbGF5IG1lY2hhbmlzbSBhdCBhbGwgKGZvciBpbnN0
YW5jZSBpdCByZWR1Y2VzIHRoZSBwb3NzaWJsZSBudW1iZXIgb2Ygcm91bmRzIG9mIGEgY2FjaGUg
cHJvYmluZyBhdHRhY2ssIGFzc3VtaW5nIHRoZSBjYWNoZSBUVEwgJmd0OyByZXBsYXkgd2luZG93
KS4gV2hpY2ggbWVjaGFuaXNtcw0KIHRvIHVzZSwgYW5kIHdoZXRoZXIgdG8gZW5hYmxlIDAtUlRU
IGluIHRoZSBmaXJzdCBwbGFjZSAob3IgUFNLIG1vZGUgYXQgYWxsKSwgc2hvdWxkIGJlIGRlY2lk
ZWQgY29uc2lkZXJpbmcgdGhlIHRyYWRlb2ZmIGJldHdlZW4gc2VjdXJpdHkvcGVyZm9ybWFuY2Uv
aW1wbGVtZW50YXRpb24gY29uc3RyYWludHMsIGV0Yy4gSW4gdGhlIGNhc2Ugb2YgRE5TLCBtb3N0
IEROUyBzZWN1cml0eSBwcm90b2NvbHMgKGRuc3NlYywgZXRjLikgZG8gYWxsb3cgdGhpcw0KIGtp
bmQgb2YgcmVwbGF5IHNvIEkgdGhpbmsgaXQgaXMgYSBwcmV0dHkgcmVhc29uYWJsZSB0cmFkZW9m
ZiB0byBjb25zaWRlci4gPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5LCBJIHRoaW5rIHRoZSBzdGF0
ZWxlc3MgdGVjaG5pcXVlIGlzIHF1aXRlIHVzZWZ1bCBhcyBhIGRlZmVuc2UtaW4tZGVwdGggbWVj
aGFuaXNtLiBJIGhpZ2hseSBkb3VidCBhbGwgZGVwbG95bWVudHMgd2lsbCBlbmQgdXAgY29ycmVj
dGx5IGltcGxlbWVudGluZyBhIHRob3JvdWdoIGFudGktcmVwbGF5IG1lY2hhbmlzbSAod2hldGhl
ciBhY2NpZGVudGFsbHkgb3Igd2lsbGZ1bGx5KS4gVGhlIHN0YXRlbGVzcyBtZXRob2QgaXMgdmVy
eQ0KIGNoZWFwLCBhbmQgY2FuIGJlIGltcGxlbWVudGVkIGVudGlyZWx5IHdpdGhpbiBhIFRMUyBs
aWJyYXJ5IGV2ZW4gaW4gYSBkaXN0cmlidXRlZCBzZXR1cCwgb25seSByZXF1aXJpbmcgYWNjZXNz
IHRvIGFuIGFjY3VyYXRlIGNsb2NrLiBJ4oCZZCBtdWNoIHJhdGhlciBkZXBsb3ltZW50cyB3aXRo
b3V0IGEgcm9idXN0IGFuZCBjb3JyZWN0IGFudGktcmVwbGF5IG1lY2hhbmlzbSBicmVhayBkb3du
IHRvIGFsbG93aW5nIHJlcGxheSBvdmVyIGEgbnVtYmVyDQogb2Ygc2Vjb25kcywgcmF0aGVyIHRo
YW4gZGF5cyAob3IgbG9uZ2VyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPkt5bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRv
OnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Db2xtIE1hY0PDoXJ0
aGFpZ2g8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXkgMjEsIDIwMTcgMTA6MjkgUE08YnI+
DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs8YnI+DQo8Yj5D
Yzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gU2VjdXJp
dHkgcmV2aWV3IG9mIFRMUzEuMyAwLVJUVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1
biwgTWF5IDIxLCAyMDE3IGF0IDM6NDcgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1h
aWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo
dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIENsaWVu
dHMgTVVTVCBOT1QgdXNlIHRoZSBzYW1lIHRpY2tldCBtdWx0aXBsZSB0aW1lcyBmb3IgMC1SVFQu
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGRvbid0IHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhpcyByZXF1aXJlbWVudC4g
QXMgeW91IG5vdGUgYmVsb3csPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5zZXJ2ZXJzIGFyZSB1bHRpbWF0ZWx5IHJlc3BvbnNpYmxlIGZvciBlbmZv
cmNpbmcgaXQsIGFuZCBpdCdzIG5vdCBjbGVhciB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWUgd2h5IGNsaWVudHMgb2JleWluZyBpdCBtYWtl
cyBsaWZlIGVhc2llciBmb3IgdGhlIHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SSB0aGluayBjbGllbnRzIHNob3VsZCBkdXBsaWNhdGUgdGhlbSBzb21ldGltZXMs
IGp1c3QgdG8ga2VlcCBzZXJ2ZXJzIG9uIHRoZWlyIHRvZXMgOy0pIHRoaXMgaXMgd2hhdCB3ZSB0
YWxrZWQgYWJvdXQgbWF5YmUgYmVpbmcgYSBncmVhc2UgdGhpbmcgLi4gaWYgYXQgYWxsLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t
IFNlcnZlcnMgTVVTVCBOT1QgYWNjZXB0IHRoZSBzYW1lIHRpY2tldCB3aXRoIHRoZSBzYW1lIGJp
bmRlciBtdWx0aXBsZTxicj4NCiZuYnNwOyB0aW1lcyBmb3IgMC1SVFQgKGlmIGFueSBwYXJ0IG9m
IENsaWVudEhlbGxvIGNvdmVyZWQgYnkgYmluZGVyIGlzPGJyPg0KJm5ic3A7IGRpZmZlcmVudCwg
b25lIGNhbiBhc3N1bWUgYmluZGVycyBhcmUgZGlmZmVyZW50KS4gVGhpcyBob2xkcyBldmVuPGJy
Pg0KJm5ic3A7IGFjcm9zcyBzZXJ2ZXJzIChpLmUuLCBpZiBzZXJ2ZXIxIGFjY2VwdHMgMC1SVFQg
d2l0aCB0aWNrZXQgWCBhbmQ8YnI+DQombmJzcDsgYmluZGVyIFksIHRoZW4gc2VydmVyMiBjYW4g
bm90IGFjY2VwdCAwLVJUVCB3aXRoIHRpY2tldCBYIGFuZCBiaW5kZXI8YnI+DQombmJzcDsgWSku
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGFzc3VtZSB0aGF0IHdoYXQgeW91IGhhdmUgaW4gbWluZCBoZXJlIGlzIHRoYXQgdGhl
IHNlcnZlciB3b3VsZCBrbm93PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj53aGljaCB0aWNrZXRzIGl0IHdhcyBhdXRob3JpdGF0aXZlIGZvciBhbnRp
LXJlcGxheSBhbmQgd291bGQgc2ltcGx5IHJlamVjdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MC1SVFQgaWYgaXQgd2Fzbid0IGF1dGhvcml0YXRp
dmU/IFRoaXMgc2VlbXMgbGlrZSBpdCB3b3VsZCBzaWduaWZpY2FudGx5IGN1dDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZG93biBvbiBtYXNzIHJl
cGxheXMsIHRob3VnaCBpdCB3b3VsZCBvZiBjb3Vyc2Ugc3RpbGwgbWFrZSBhcHBsaWNhdGlvbi1s
ZXZlbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
cmVwbGF5IGEgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSdtIGhhcHB5IHRvIHdyaXRlIHRoaXMgdXAgYXMgcGFydCBvZiB0aGUg
Zmlyc3QgdHdvIHRlY2huaXF1ZXMuIEknZCBiZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50ZXJlc3RlZCBpbiBoZWFyaW5nIGZyb20g
b3RoZXJzIGluIHRoZSBXRyB3aGF0IHRoZXkgdGhpbmsgYWJvdXQ6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIFJlcXVpcmluZyBpdC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFdoZXRo
ZXIgdGhleSBzdGlsbCB3YW50IHRvIHJldGFpbiB0aGUgc3RhdGVsZXNzIHRlY2huaXF1ZS48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGZvciByZXF1aXJpbmcgaXQsIGFu
ZCBmb3IgcmVtb3ZpbmcgdGhlIHN0YXRlbGVzcyB0ZWNobmlxdWUgLi4uIGJlY2F1c2UgaXQgcHJl
dmVudHMgdGhlIHNpZGUtY2hhbm5lbCBhbmQgRE9TIGF0dGFja3MgYW5kIHRob3NlIHNlZW0gbGlr
ZSB0aGUgbW9zdCBzZXJpb3VzIG9uZXMgKGFuZCBhbHNvLCB0aGUgbmV3IG9uZXMpLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBm
YXIgZWFjaCBjYXNlIHdoZXJlIHdlJ3ZlIHRob3VnaHQgJnF1b3Q7QWN0dWFsbHkgc3RhdGVsZXNz
IG1pZ2h0IGJlIG9rIGluIHRoaXMgY2FzZSZxdW90OyAuLi4gbGlrZSB0aGUgZXhhbXBsZSBvZiBE
TlMgLi4uIHR1cm5zIG91dCBub3QgdG8gYmUgc2FmZSB3aGVuIGV4YW1pbmVkIG1vcmUgY2xvc2Vs
eSAoaW4gRE5TZXMgY2FzZSBpdCB3b3VsZCBjb21wcm9taXNlIHByaXZhY3kgYmVjYXVzZSBjYWNo
ZXMgY291bGQgYmUgcHJvYmVkKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkNvbG08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_MWHPR15MB1182F59E2B60534CB20EC9C4AFF80MWHPR15MB1182namp_--


From nobody Mon May 22 10:17:22 2017
Return-Path: 
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 271A8129B9E for ; Mon, 22 May 2017 10:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lckakExZJCoO for ; Mon, 22 May 2017 10:17:20 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DA2126C23 for ; Mon, 22 May 2017 10:17:19 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 145D27A32F1 for ; Mon, 22 May 2017 17:17:19 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Mon, 22 May 2017 13:17:18 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org> 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:17:21 -0000

> On May 22, 2017, at 1:06 PM, Benjamin Kaduk  wrote:
>=20
> Given the apparent strength of opinion against removing these supposed =
restrictions entirely, it seems like this text (or something similar) is =
probably the best we can do.

Perhaps so, but I saw only one strong objection from Dave Garrett.  Is =
that
sufficient for "apparent strength of opinion"?  Removal is simpler, and =
it
sure does not look like people are determined to continue to support MD5
and SHA-1 in certificates, but would be willing to relent if TLS 1.3 =
told
them not to.  Isn't the language in question tackling a non-problem?

That said, if the only way to rough consensus is a properly qualified
requirement to not rely on such certificate signatures for =
authentication,
(rather than must hang up with a fatal alert when you see these, must =
not
send these, ...) then I'll go along with a compromise.

--=20
	Viktor.


From nobody Mon May 22 10:24:18 2017
Return-Path: 
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 8216912EB34 for ; Mon, 22 May 2017 10:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 agoiehJarbpT for ; Mon, 22 May 2017 10:24:15 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B049D1200B9 for ; Mon, 22 May 2017 10:24:15 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id l74so63175108ywe.2 for ; Mon, 22 May 2017 10:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NyfbXEaP7bGFe1v7xCM99jmPmF4hs1t0zCgo8YPjuDc=; b=itDDI4fg7Zyb7rjxfbGbm3yBZhzfJVC7/IJDYks9q6BAJBXXdejKQzAbwm94f17cdJ xycHRngSictuunjftiy+Lm6M3BLY3BazvDRNTZz3ptpElp6l2lD3ESnA1U1eevVkEf74 wYLQ9UvTqKFzWp+WVALsPvzHGQjhSUDbR8uabdWqxBEQ3bH+iTJwJlt0uBPjteT0RRRp xXIixukmQlK0gVhmzeHqEkZzXeZxjW+u8/+t0V2oSeNmOSlNMSOct0QeApeqJgQlKyUH rWQIXzaIZBwVqsfARDmYXBkkDA0hQnYvzeUZIgjVVXScWtJckmvDo76IKMFiKtAIsW8V QMmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NyfbXEaP7bGFe1v7xCM99jmPmF4hs1t0zCgo8YPjuDc=; b=mVK/pOZe5aC/FYI4pDublKTsaWSlx/f1l+retZLhQ2Dc52M8oo8buUPphQ6Xi9NhP/ ozoP0GWeMcWnkW6261eD1iAdYEvVTz0NyMMVfTjG8JkfMLiUDZR05cTdSfB5wkgnMkOL i82oC7d2VPVEQ67dII/XFUdqs/XgESDONu3ZexK0YNMh4DNY+Dtz0UdOAeGmxsjRKcrE 3Lxy2GmjSVfzCyP78ARaQ++R2X3F8nygUcCA03jbuHlU6FJCN7Mrw4+pDolGoTm3Th7y 9vvkbPkYWFOBIR2Pug0UUWsYkVljekTZCvRHUoaaALt1C0qYdjqTAJLE4TXh67SWIHjy Z7dg==
X-Gm-Message-State: AODbwcDIf1J94Pap0/oqwDuo7NLZ6S92yKwvhr2cJrrm3Kh8vGcE4Twl rUmqfVv66Dhf7FwXIZzKxXdY3uoex4+c
X-Received: by 10.129.96.69 with SMTP id u66mr21656620ywb.241.1495473854833; Mon, 22 May 2017 10:24:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Mon, 22 May 2017 10:24:13 -0700 (PDT)
In-Reply-To: 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>   
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Mon, 22 May 2017 10:24:13 -0700
Message-ID: 
To: Kyle Nekritz 
Cc: Eric Rescorla , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11471c00e388320550202364"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:24:17 -0000

--001a11471c00e388320550202364
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz  wrote:

> The stateless technique certainly doesn=E2=80=99t solve all issues with r=
eplay.
> Neither do the other techniques, unless a fairly unrealistic (imo, in mos=
t
> use cases) retry strategy is used.
>


The stateless technique is insecure; plain and simple, and it is far more
easily exploited than issues that have caused us to deprecate cipher
suites. It should come out. It enables attacks that are materially
different from forced retries, such as cache probing and statistical
side-channel analysis.


> But the stateless technique is definitely an improvement over no
> anti-replay mechanism at all (for instance it reduces the possible number
> of rounds of a cache probing attack, assuming the cache TTL > replay
> window).
>

Today TLS has robust anti-replay; the comparison to "no anti-replay
mechanism at all" isn't relevant.



> Which mechanisms to use, and whether to enable 0-RTT in the first place
> (or PSK mode at all), should be decided considering the tradeoff between
> security/performance/implementation constraints, etc. In the case of DNS,
> most DNS security protocols (dnssec, etc.) do allow this kind of replay s=
o
> I think it is a pretty reasonable tradeoff to consider.
>


This same argument could be made for keeping MD5, or RC4.  DNSSEC is not
concerned with secrecy. TLS is. This exact kind of replay would compromise
the secrecy of the data being transported.


> Additionally, I think the stateless technique is quite useful as a
> defense-in-depth mechanism.
>

It's tempting because it lowers the costs for implementors, but it's
absolutely not secure.  I seriously doubt that any application can be made
side-channel free in the manner that would be required to preserve secrecy.


> I highly doubt all deployments will end up correctly implementing a
> thorough anti-replay mechanism (whether accidentally or willfully).
>

This is why I think we should GREASE this and report (to users) any sites
that show any signs of replay tolerance.


> The stateless method is very cheap, and can be implemented entirely withi=
n
> a TLS library even in a distributed setup, only requiring access to an
> accurate clock. I=E2=80=99d much rather deployments without a robust and =
correct
> anti-replay mechanism break down to allowing replay over a number of
> seconds, rather than days (or longer).
>

I'd prefer if that were possible too, but it's not possible - it's
insecure.

--=20
Colm

--001a11471c00e388320550202364
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz <knekritz@fb.com><=
/span> wrote:











The stateless technique certainly doesn=E2=
=80=99t solve all issues with replay. Neither do the other techniques, unle=
ss a fairly unrealistic (imo, in most use cases)
 retry strategy is used. 


The stateless technique is insecure; plain and simple,=
 and it is far more easily exploited than issues that have caused us to dep=
recate cipher suites. It should come out. It enables attacks that are mater=
ially different from forced retries, such as cache probing and statistical =
side-channel analysis.=C2=A0
=C2=A0
But the stateless technique is definitely an impro=
vement over no anti-replay mechanism at all (for instance it reduces the po=
ssible number of rounds of a cache probing attack, assuming the cache TTL &=
gt; replay window).

=
Today TLS has robust anti-replay; the comparison to "no anti-replay me=
chanism at all" isn't relevant. =C2=A0

=
=C2=A0
Which mech=
anisms
 to use, and whether to enable 0-RTT in the first place (or PSK mode at all=
), should be decided considering the tradeoff between security/performance/=
implementation constraints, etc. In the case of DNS, most DNS security=
 protocols (dnssec, etc.) do allow this
 kind of replay so I think it is a pretty reasonable tradeoff to consider. =



=
This same argument could be made for keeping MD5, or RC4.=C2=A0 DNSSEC is n=
ot concerned with secrecy. TLS is. This exact kind of replay would compromi=
se the secrecy of the data being transported.=C2=A0
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">

Additionally, I think the stateless technique is quite useful as a defense-=
in-depth mechanism.

=
It's tempting because it lowers the costs for implementors, but it'=
s absolutely not secure.=C2=A0 I seriously doubt that any application can b=
e made side-channel free in the manner that would be required to preserve s=
ecrecy.=C2=A0
=C2=A0
 I highly doubt all deployments will end up correctly implementin=
g a thorough anti-replay mechanism (whether accidentally or willfully). 

This is why I think we=
 should GREASE this and report (to users) any sites that show any signs of =
replay tolerance.=C2=A0
=C2=A0
The stateless method is very
 cheap, and can be implemented entirely within a TLS library even in a dist=
ributed setup, only requiring access to an accurate clock. I=E2=80=99d much=
 rather deployments without a robust and correct anti-replay mechanism brea=
k down to allowing replay over a number
 of seconds, rather than days (or longer).

I'd prefer if that were possible too, but it'=
;s not possible - it's insecure.=C2=A0

-- 
Colm




--001a11471c00e388320550202364--


From nobody Mon May 22 10:28:01 2017
Return-Path: 
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 E886612EB3F for ; Mon, 22 May 2017 10:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 UkpmuJA94A1i for ; Mon, 22 May 2017 10:27:58 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A1E12EB42 for ; Mon, 22 May 2017 10:27:58 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4MHRY75006198; Mon, 22 May 2017 18:27:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=ehDqqxUga0kKRl/Ph4TRwQISd5C+7kI17V9ZZkf60O8=; b=TP5ycv6PhHtCiFoxTACw+WQKflYHEn1pOpRs8Y9KLsnz67/YSyFnv2Bo86I9DMVNT6Ui jbA/SRM0YJA2V8lpvUkrNVWLXUelJFUZxrrY3wGgwDMTbdB87+YeBCps9oLBiLsQf32v O0MUFOzvaAtqqp89BORfGV1xWPNWQAmnBb459YzfSR4otO+VaIXiqyhojDoCw4Wz2lCi dtmhC08O8cNAW5dlkM/mnKO9UDLJS9FnC5iqDiRzYgvyVHeZujsr8UQYd78UKriiwMgu 4yhpfOftCCxk+mhE7mxYQWJsfNFKR1UFJ1ZcVUhU6t/SDBghnaW2VYrCnD6oe5wy/EJM Ug== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2akvg5tt8p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 May 2017 18:27:54 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4MHLZC2009213; Mon, 22 May 2017 13:27:53 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ajh4vbht9-1; Mon, 22 May 2017 13:27:52 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 9035520064; Mon, 22 May 2017 11:27:52 -0600 (MDT)
To: TLS WG , Viktor Dukhovni 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org>
From: Benjamin Kaduk 
Message-ID: <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
Date: Mon, 22 May 2017 12:27:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org>
Content-Type: multipart/alternative; boundary="------------D1D81A8F72EB60D9EAC726FE"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220091
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220092
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:28:00 -0000

This is a multi-part message in MIME format.
--------------D1D81A8F72EB60D9EAC726FE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/22/2017 12:17 PM, Viktor Dukhovni wrote:
>> On May 22, 2017, at 1:06 PM, Benjamin Kaduk  wrote:
>>
>> Given the apparent strength of opinion against removing these supposed restrictions entirely, it seems like this text (or something similar) is probably the best we can do.
> Perhaps so, but I saw only one strong objection from Dave Garrett.  Is that

There was also some discussion when this text was originally going in,
IIRC.  But I do not remember well enough to say who/how many people
wanted it.

> sufficient for "apparent strength of opinion"?  Removal is simpler, and it
> sure does not look like people are determined to continue to support MD5
> and SHA-1 in certificates, but would be willing to relent if TLS 1.3 told
> them not to.  Isn't the language in question tackling a non-problem?

It probably is, but I don't feel a need to spend a lot of my time
pushing for it to be removed.

-Ben

> That said, if the only way to rough consensus is a properly qualified
> requirement to not rely on such certificate signatures for authentication,
> (rather than must hang up with a fatal alert when you see these, must not
> send these, ...) then I'll go along with a compromise.
>


--------------D1D81A8F72EB60D9EAC726FE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/22/2017 12:17 PM, Viktor Dukhovni wrote:

    

      

      

        
On May 22, 2017, at 1:06 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

Given the apparent strength of opinion against removing these supposed restrictions entirely, it seems like this text (or something similar) is probably the best we can do.


      

      
Perhaps so, but I saw only one strong objection from Dave Garrett.  Is that


    

    

    There was also some discussion when this text was originally going
    in, IIRC.  But I do not remember well enough to say who/how many
    people wanted it.

    

    

      
sufficient for "apparent strength of opinion"?  Removal is simpler, and it
sure does not look like people are determined to continue to support MD5
and SHA-1 in certificates, but would be willing to relent if TLS 1.3 told
them not to.  Isn't the language in question tackling a non-problem?


    

    

    It probably is, but I don't feel a need to spend a lot of my time
    pushing for it to be removed.

    

    -Ben

    

    

      
That said, if the only way to rough consensus is a properly qualified
requirement to not rely on such certificate signatures for authentication,
(rather than must hang up with a fatal alert when you see these, must not
send these, ...) then I'll go along with a compromise.



    

    

  


--------------D1D81A8F72EB60D9EAC726FE--


From nobody Mon May 22 10:36:12 2017
Return-Path: 
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 CB0BC12EB31; Mon, 22 May 2017 10:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level: 
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 gjJkW-SRmM2z; Mon, 22 May 2017 10:35:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F54B1200ED; Mon, 22 May 2017 10:35:43 -0700 (PDT)
X-AuditID: 1209190c-07dff70000001ef4-ff-5923216d00d9
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A1.FB.07924.D6123295; Mon, 22 May 2017 13:35:42 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v4MHZei6031223; Mon, 22 May 2017 13:35:40 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4MHZZb2025266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 May 2017 13:35:38 -0400
Date: Mon, 22 May 2017 12:35:35 -0500
From: Benjamin Kaduk 
To: Daniel Migault 
Cc: tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "ietf@ietf.org" , The IESG , secdir@ietf.org
Message-ID: <20170522173534.GT39245@kduck.kaduk.org>
References: <20170519043827.GL39245@kduck.kaduk.org>  <20170519162725.GM39245@kduck.kaduk.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nopunqBxpcP8Yq8WU6XvYLN4s28Rk MePPRGaLZxvns1h8WPiQxeLT+S5GBzaPX1+vsnksWfKTKYApissmJTUnsyy1SN8ugSvj748D zAXTOSqeLLnA2sC4na2LkZNDQsBEYmXvW8YuRi4OIYHFTBKTbx9hBEkICWxklJjRVwCRuMok 8WD7dCaQBIuAqsS/W+9YQGw2ARWJhu7LzCC2iICBxMsJO9lAGpgFFjBK7GtqAysSFnCRWNG3 BKyIF2hdz45+qA1vGSU2PqiHiAtKnJz5BKyeWUBL4sa/l0DLOIBsaYnl/zhATE6BQIn76/hB KkQFlCX+Hr7HMoFRYBaS5llImmchNC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mi l5pSuokRFMyckjw7GM+88TrEKMDBqMTDq/FYKVKINbGsuDL3EKMkB5OSKO/RN0AhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrx57MqRQrwpiZVVqUX5MClpDhYlcV4JjcYIIYH0xJLU7NTUgtQi mKwMB4eSBO9kBaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGzQWp4iwsSc4sz0yHypxgVpcR5d4Ak BEASGaV5cL2gZCORvb/mFaM40CvCvGUgVTzARAXX/QpoMBPQYOtn8iCDSxIRUlINjK3n5JZk O9V/1Uyc16yopM53cm3Gju8rp1x86aW/YM6es7tXVxm6s6s+0NtTHdWen6ZwnW3R6ndZK55x GlZwLnddckukpXz6S1ed3U7M0rv33v/+TZ7plczSvV6OqRuZZrYp5J+b5dXKnbnRwEmUhana KiFD0VJ5+p5rV+PzL+7oWpqRsVg8UYmlOCPRUIu5qDgRAHMN/G0RAwAA
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:35:45 -0000

Sorry for the slow reply.

On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> Thank you,
> 
> Your comments have all been addressed. I have one remaining clarification.
> In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not
> only for the cipher suites of the draft. In your opinion do we clarify
> this, and should we use something else than SHOULD NOT ?

It's somewhat awkward, as what we really want to do is Update RFC
5489 to add this prohibition there.  But, that's more process to
jump through and this document is already at a late stage, so I do
not actually propose doing that.  I would be okay saying

  As such, all ECDHE_PSK ciphers, including those defined outside
  this document, SHOULD NOT be negotiated in TLS versions prior to
  1.2.

to match up with the MUST NOT text we have for these new ciphers.
(Taking into account Martin's text that the prohibition is on
negotiating them, but offering them in a ClientHello that also
offers the old version is okay.)

-Ben


From nobody Mon May 22 10:37:58 2017
Return-Path: 
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 40B1812EB36 for ; Mon, 22 May 2017 10:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.711
X-Spam-Level: 
X-Spam-Status: No, score=0.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 47yO6Dp_6AtX for ; Mon, 22 May 2017 10:37:54 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B8C126C2F for ; Mon, 22 May 2017 10:37:54 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4MHRWur008960; Mon, 22 May 2017 18:37:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=CjNCN8uslhbQ+Rrkyb8fVGs1LObBLseddyyPPm8+dfg=; b=LY+G2+Vk1T4AwEauw1WJ5NozMqR0xe4TQ0EuGyBrD5pviX2FJ1ctoFMyqdam5r7Z8Uy3 p+F/Z0ctL5HygBE9zehMKAk+t83JfLIe85o7CeqKb+3nb/rCPO3Djsa/Wp9O+GH9d4gn I/7MHA9mCrZ7DOyZH8dokwg3F8UQVCo7C65sY5aMSvh8HZVTwGX6ZsAMw6tMG/VSjOu+ JBjlHAR4O9VxbOWbckEz8/Xvl4pSxd9E9TGH8ADK+DH8LcKl/YMDZi99XwpVlJj4NlpF 1FIlijLySNzdg9faOmiYYUcCP7wKww/YTmeYdpLmcBsX7Lc8aka+m74O1l5Gv4sYtolj Dw== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2akw7haqvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 May 2017 18:37:51 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4MHVOoA007869; Mon, 22 May 2017 13:37:50 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ajh4ux6au-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 May 2017 13:37:50 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 22 May 2017 10:37:49 -0700
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 22 May 2017 13:37:49 -0400
From: "Salz, Rich" 
To: "Kaduk, Ben" , TLS WG , Viktor Dukhovni 
Thread-Topic: [TLS] AD Review of draft-ietf-tls-tls13
Thread-Index: AQHS0IMoCuGTydRkRUKTdQLvE3XegqH8ZV6AgABRk4CAAEJ+AIAAA9yAgAPgU4CAAALxAIAAAvMA//++0+A=
Date: Mon, 22 May 2017 17:37:49 +0000
Message-ID: 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
In-Reply-To: <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.41.160]
Content-Type: multipart/alternative; boundary="_000_ac704db142c04e7b8a836df711e9bc7fusma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220092
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220092
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:37:56 -0000

--_000_ac704db142c04e7b8a836df711e9bc7fusma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhc3NlcnQgdGhhdCBtb3N0IHVzZXMgb2YgVExTIGFyZSBzZXJ2ZXItYXV0aGVudGljYXRlZCB1
c2luZyBhIFBLSVgtY29tcGxpYW50IGNlcnRpZmljYXRlLCBubyBtYXR0ZXIgaWYgeW91IGNvdW50
IHVzZXJzL3NlcnZlcnMsIGNvbm5lY3Rpb25zLCBieXRlcyB0cmFuc2ZlcnJlZCwgb3IgZS1jb21t
ZXJjZSBkb2xsYXIgdmFsdWUuDQoNCkl0IGhhcyBiZWVuIHRoaXMgd2F5IGZvcmV2ZXIgYW5kIHRo
YXQgaXMgd2h5IHRoZSBUTFMgUkZD4oCZcyBoYXZlIGFsd2F5cyB0YWxrZWQgYWJvdXQgY2VydGlm
aWNhdGVzLCBhbHRob3VnaCBsZWZ0IHRoZSBjaGFpbiB2YWxpZGF0aW9uIHVwIHRvIHNlcGFyYXRl
IFJGQ+KAmXMuICBOb3RlIHRoYXQgdGhvc2UgUkZDcyByZWFsbHkgb25seSB0YWxrZWQgYWJvdXQg
Km5hbWluZyogbm90IGNyeXB0by4NCg0KSSBzdHJvbmdseSBiZWxpZXZlIHRoZSB0ZXh0IHNob3Vs
ZCBzdGF5IGFzIGl0IGlzLCBmb3IgdGhlIG1vc3QgZ29vZCB0byB0aGUgbW9zdCBwZW9wbGUuICBW
aWt0b3IgaXMgaW4gdGhlIHdlZWRzLCBhcmd1YWJseSBieSBoaW1zZWxmLg0KDQotLQ0KU2VuaW9y
IEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFt
DQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg==

--_000_ac704db142c04e7b8a836df711e9bc7fusma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN
Cgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo
YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv
bnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkkgYXNzZXJ0IHRoYXQgbW9zdCB1c2VzIG9mIFRM
UyBhcmUgc2VydmVyLWF1dGhlbnRpY2F0ZWQgdXNpbmcgYSBQS0lYLWNvbXBsaWFudCBjZXJ0aWZp
Y2F0ZSwgbm8gbWF0dGVyIGlmIHlvdSBjb3VudCB1c2Vycy9zZXJ2ZXJzLCBjb25uZWN0aW9ucywg
Ynl0ZXMgdHJhbnNmZXJyZWQsDQogb3IgZS1jb21tZXJjZSBkb2xsYXIgdmFsdWUuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5JdCBoYXMgYmVlbiB0aGlz
IHdheSBmb3JldmVyIGFuZCB0aGF0IGlzIHdoeSB0aGUgVExTIFJGQ+KAmXMgaGF2ZSBhbHdheXMg
dGFsa2VkIGFib3V0IGNlcnRpZmljYXRlcywgYWx0aG91Z2ggbGVmdCB0aGUgY2hhaW4gdmFsaWRh
dGlvbiB1cCB0byBzZXBhcmF0ZSBSRkPigJlzLiZuYnNwOw0KIE5vdGUgdGhhdCB0aG9zZSBSRkNz
IHJlYWxseSBvbmx5IHRhbGtlZCBhYm91dCAqPGI+bmFtaW5nPC9iPiogbm90IGNyeXB0by48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkkgc3Ryb25nbHkg
YmVsaWV2ZSB0aGUgdGV4dCBzaG91bGQgc3RheSBhcyBpdCBpcywgZm9yIHRoZSBtb3N0IGdvb2Qg
dG8gdGhlIG1vc3QgcGVvcGxlLiZuYnNwOyBWaWt0b3IgaXMgaW4gdGhlIHdlZWRzLCBhcmd1YWJs
eSBieSBoaW1zZWxmLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6d2luZG93dGV4dCI+LS0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5TZW5pb3IgQXJj
aGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPk1lbWJlciwg
T3BlblNTTCBEZXYgVGVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5JTTogcmljaHNhbHpAamFiYmVy
LmF0IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_ac704db142c04e7b8a836df711e9bc7fusma1exdag1mb1msgcorpak_--


From nobody Mon May 22 10:38:57 2017
Return-Path: 
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 0123C1200B9 for ; Mon, 22 May 2017 10:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-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 OovOHDUq72AJ for ; Mon, 22 May 2017 10:38:54 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF99124E15 for ; Mon, 22 May 2017 10:38:54 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id CEA077A32F1 for ; Mon, 22 May 2017 17:38:53 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
Date: Mon, 22 May 2017 13:38:52 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:38:56 -0000

> On May 22, 2017, at 1:27 PM, Benjamin Kaduk  wrote:
>=20
>> Isn't the language in question tackling a non-problem?
>=20
> It probably is, but I don't feel a need to spend a lot of my time =
pushing
> for it to be removed.

Well, the reason for this sub-thread is that I just to waste a bunch of =
cycles
to avoid new code in OpenSSL that would implement the spec as written =
and
needlessly break applications that don't care about PKIX certificates.

A nameless team member suggested casually that such applications can =
just
disable TLS 1.3...

And yet TLS 1.3 brings desirable improvements, and should not have =
needless
restrictions on the supported use cases.

Therefore, the language should go, or needs to be amended to make it =
clear
that TLS does not prohibit (mandate connection abort, ...) the =
appearance
of any certificate signature algorithms in the certificate message.  =
Advice
to not trust such algorithms for authentication is unnecessary, but =
acceptable.

--=20
	Viktor.


From nobody Mon May 22 10:45:50 2017
Return-Path: 
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 A3151124E15 for ; Mon, 22 May 2017 10:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 99Ks9F1IYec2 for ; Mon, 22 May 2017 10:45:47 -0700 (PDT)
Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F4912009C for ; Mon, 22 May 2017 10:45:46 -0700 (PDT)
Received: by mail-wr0-x241.google.com with SMTP id w50so7693882wrc.0 for ; Mon, 22 May 2017 10:45:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yV8Yqa1DB1oFXn5EhqAtOrQkb15qc3fysSvTk/jpeqo=; b=f/AfdiD4OX/bwGidndhR+3OUlP7bQa2nRqF/YOKaNi9URIMmcKQQ/gTY6ms9z3rZB0 6cUyNDQgDDhMoyxvRI/PldePYdh1oLCGyiLPv2cb3AMkul0Kb5oI4zOnXFcVRyd+IxRn PeHht0tmB2+KrqIPe4o2jS5NYGS4kkwQKLdwisXq9k+zYPYGyxI9m+YcicEFb3h661/f XIagiZFa7Ba4dBIaYqGbe86EIM/T8fW1/53SRTzvemDteJHehoWTVlZep7Hc67YrkdTj 3MF33tHPfqVQmuF7q1qEfxRwqH38n+BogcXGM3wQPoDHGbR/TLS/xsMaFX8G9deEhVdv RV7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yV8Yqa1DB1oFXn5EhqAtOrQkb15qc3fysSvTk/jpeqo=; b=DiDONfI/rLtuRO8r+Tw+7obUByz7+5Hu9hfj4XiIi/kskKwyZUC73EbBcjK6GD/qEo 6XGmNV7sD1aQ6eVcmDQpRJCYLKLSrSWv0nILuQS4HBFED7ql/ItHo4dOCz0fvRHsRwXl yLItDu6ke7tAMQ67nzU3+a/oXhh2TgTDP1cZHFBXUeUndHBMApbCu/tGvBAIHA4Ec/s5 zgCTMKDM+aqa8nZfb1GyoZ/tGgyWRK+ltP1RbQBrZNY3nngtWYZXNo8N5tYWF/wUWqY4 kjJYVgwZNe8xk+RLOTL1MTXvpLe/YSQJY8g9YFkaDudlPLmOHA+5iSUZf9Qc4Tu7JMfW Yb9w==
X-Gm-Message-State: AODbwcAwlcvLnNF7CpeBLfR4mFiJnhywJb6Dz+oaDFgBiJ/V1lMTwcf3 nqiF7h2DC8DWDg==
X-Received: by 10.223.179.199 with SMTP id x7mr13740153wrd.72.1495475145290; Mon, 22 May 2017 10:45:45 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 137sm19699979wmi.19.2017.05.22.10.45.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 10:45:44 -0700 (PDT)
From: Yoav Nir 
Message-Id: <2120907F-7488-46DA-B5BA-76A89A2E6236@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_97085B6D-9C66-49EE-A0DF-5A5DAE856F8E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 22 May 2017 20:45:41 +0300
In-Reply-To: <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
Cc: TLS WG , Viktor Dukhovni 
To: Benjamin Kaduk 
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:45:49 -0000

--Apple-Mail=_97085B6D-9C66-49EE-A0DF-5A5DAE856F8E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8A6D4E9D-64EC-4284-BFCE-501F83AC3229"


--Apple-Mail=_8A6D4E9D-64EC-4284-BFCE-501F83AC3229
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 22 May 2017, at 20:27, Benjamin Kaduk  wrote:
>=20
> On 05/22/2017 12:17 PM, Viktor Dukhovni wrote:
>>> On May 22, 2017, at 1:06 PM, Benjamin Kaduk  =
 wrote:
>>>=20
>>> Given the apparent strength of opinion against removing these =
supposed restrictions entirely, it seems like this text (or something =
similar) is probably the best we can do.
>> Perhaps so, but I saw only one strong objection from Dave Garrett.  =
Is that
>=20
> There was also some discussion when this text was originally going in, =
IIRC.  But I do not remember well enough to say who/how many people =
wanted it.

This came up in one of the F2F meetings. I believe I argued that we =
shouldn=E2=80=99t have PKIX policy in a TLS document, because if signing =
certificates with SHA-1 is bad, it=E2=80=99s bad for all users of =
certificates, and should be prohibited by a PKIX document, not a TLS =
document.

The room was against me then. So it may look now like it=E2=80=99s just =
Dave (and now Rich), there was more support for this at the time.

Yoav


--Apple-Mail=_8A6D4E9D-64EC-4284-BFCE-501F83AC3229
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 22 May 2017, at 20:27, Benjamin Kaduk <bkaduk@akamai.com> =
wrote:


 =20
    
 =20
  

    On 05/22/2017 12:17 PM, Viktor Dukhovni wrote:

    
=

      

      

        
On May 22, 2017, at 1:06 PM, Benjamin =
Kaduk <bkaduk@akamai.com> wrote:

Given the apparent strength of opinion against removing these supposed =
restrictions entirely, it seems like this text (or something similar) is =
probably the best we can do.


      

      
Perhaps so, but I saw only one strong =
objection from Dave Garrett.  Is that


    

    

    There was also some discussion when this text was originally going
    in, IIRC.  But I do not remember well enough to say who/how =
many
    people wanted it.

This came up in one of the F2F meetings. I =
believe I argued that we shouldn=E2=80=99t have PKIX policy in a TLS =
document, because if signing certificates with SHA-1 is bad, it=E2=80=99s =
bad for all users of certificates, and should be prohibited by a PKIX =
document, not a TLS document. 

The room was against me then. So it may =
look now like it=E2=80=99s just Dave (and now Rich), there was more =
support for this at the time.

Yoav

=

--Apple-Mail=_8A6D4E9D-64EC-4284-BFCE-501F83AC3229--

--Apple-Mail=_97085B6D-9C66-49EE-A0DF-5A5DAE856F8E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZIyPGAAoJELhJCxUKWMyZc08IAIZJn+klVHOO0OibGRWwbpBd
kPrzw8uU13IEYQk9j7Eu9eD8Q0NBhqowV8Sd5aJzCSCoY2CRSEdomXQ5jnlrvgbu
VWrJMPqzwSwb0TeJQOPi1dVe8HHZsEko+aCvDf8kEg7+zku9boF0PseIFXAdU4qZ
jzLK0B75TVcCGnYlcjAzMTQmsKEEF1SAlFPu4Gqtpv9TDAbbR7V04q0YdNzKCndp
LQEW2sK5wD2XIa54Pyc8D2m1dWxoVXqn8yT/SlzW47zE3wPW9Ue7TXcPpp+Sqhc/
PeWCGO1zN9YL6sSd15tz5RTC1RNne44eCjaN1noJcIf5lbuXCeygaF90vjR+zbU=
=PUWY
-----END PGP SIGNATURE-----

--Apple-Mail=_97085B6D-9C66-49EE-A0DF-5A5DAE856F8E--


From nobody Mon May 22 10:47:03 2017
Return-Path: 
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 550A712704B for ; Mon, 22 May 2017 10:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YWvzvUfG18in for ; Mon, 22 May 2017 10:47:00 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E857E12009C for ; Mon, 22 May 2017 10:46:59 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 011757A32F1 for ; Mon, 22 May 2017 17:46:58 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Mon, 22 May 2017 13:46:58 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com> 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:47:01 -0000

> On May 22, 2017, at 1:37 PM, Salz, Rich  wrote:
>=20
> I strongly believe the text should stay as it is, for the most good to =
the most people.  Viktor is in the weeds, arguably by himself.

Right, all by myself...  With support from Nico, Ilari, and others =
who've upthread
accepted that certificate verification is properly RFC5280 and not TLS, =
before I
suggested removal of the text in question (which solves no real problem, =
but does
create needless interoperability issues for various TLS use-cases).

The dominant use case is not the only one that needs consideration,
and text that breaks other use-cases is NOT just fine, and the TLS
WG really does need to think more broadly than the Web PKI.  This is
not the HTTPS working group.

--=20
	Viktor.


From nobody Mon May 22 10:47:15 2017
Return-Path: 
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 B767912009C for ; Mon, 22 May 2017 10:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8KAmBVy8mjAu for ; Mon, 22 May 2017 10:47:00 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67790124E15 for ; Mon, 22 May 2017 10:47:00 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dCrQ0-00083U-6S for tls@ietf.org; Mon, 22 May 2017 19:46:58 +0200
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dCrPu-0002Kr-4b for tls@ietf.org; Mon, 22 May 2017 13:46:54 -0400
Received: (qmail 21263 invoked from network); 22 May 2017 17:46:48 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.98]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 May 2017 17:46:47 -0000
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Kyle Nekritz 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>    
Cc: "tls@ietf.org" 
From: Christian Huitema 
Message-ID: 
Date: Mon, 22 May 2017 10:46:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0956D0D9515423A36D630600"
X-Originating-IP: 168.144.250.230
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.12)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49LCP7NcwZmTrFhTWonoFoqtTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoWIPlnrfEDRiyWf+KtRxCHRcOb18WfxGyg6Om6u4YYm9aWSU9YfXahEmwF qtDcd2Y5hjoyEb9Oq0NWpyO3vrfYoocEfHwV+0ePfQGXOSgIJz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB9a2LHJVD1n7GG0fP4s+aInTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0dzvzp+mG 5Y/zCY7DUzpfU7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa0NgfQDX7DQ+bDeh72B3Mio8arn2PuuzhjWm yAwjA2zXxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:47:03 -0000

This is a multi-part message in MIME format.
--------------0956D0D9515423A36D630600
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 5/22/2017 10:24 AM, Colm MacC=E1rthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz  > wrote:
> ...
>
>     Which mechanisms to use, and whether to enable 0-RTT in the first
>     place (or PSK mode at all), should be decided considering the
>     tradeoff between security/performance/implementation constraints,
>     etc. In the case of DNS, most DNS security protocols (dnssec,
>     etc.) do allow this kind of replay so I think it is a pretty
>     reasonable tradeoff to consider.
>
>
>
> This same argument could be made for keeping MD5, or RC4.  DNSSEC is
> not concerned with secrecy. TLS is. This exact kind of replay would
> compromise the secrecy of the data being transported.=20
> =20
Check DKG's analysis of 0-RTT for DNS over TLS:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html.
There is only one point of concern, a minor privacy leak if the DNS
queries in the 0-RTT data can be replayed at intervals chosen by the
attacker. The idea is to replay the data to a resolver, and then observe
the queries going out to authoritative servers in clear text. The
correlation can be used to find out what domain the client was
attempting to resolve. The attack requires "chosen time" by the
attacker, and thus will probably be mitigated by a caching system that
prevents replays after a short interval.

-- Christian Huitema


--------------0956D0D9515423A36D630600
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 5/22/2017 10:24 AM, Colm
      MacCárthaigh wrote:

    

    

      


        


          
On Mon, May 22, 2017 at 10:12 AM,
            Kyle Nekritz <knekritz@fb.com>
            wrote:

            ...
            

              

                

                  
Which
                      mechanisms to use, and whether to enable 0-RTT in
                      the first place (or PSK mode at all), should be
                      decided considering the tradeoff between
                      security/performance/implementation
                      constraints, etc. In the case of DNS, most DNS
                      security protocols (dnssec, etc.) do allow this
                      kind of replay so I think it is a pretty
                      reasonable tradeoff to consider. 

                    

                

              

            

            


            

            


            

            
This same argument could be made for keeping MD5, or
              RC4.  DNSSEC is not concerned with secrecy. TLS is. This
              exact kind of replay would compromise the secrecy of the
              data being transported. 

            
 

          

        

      

    

    Check DKG's analysis of 0-RTT for DNS over TLS:
    https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html.
    There is only one point of concern, a minor privacy leak if the DNS
    queries in the 0-RTT data can be replayed at intervals chosen by the
    attacker. The idea is to replay the data to a resolver, and then
    observe the queries going out to authoritative servers in clear
    text. The correlation can be used to find out what domain the client
    was attempting to resolve. The attack requires "chosen time" by the
    attacker, and thus will probably be mitigated by a caching system
    that prevents replays after a short interval.

    

    -- Christian Huitema

    

  


--------------0956D0D9515423A36D630600--


From nobody Mon May 22 10:47:21 2017
Return-Path: 
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 E233B12EB36 for ; Mon, 22 May 2017 10:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l8umUeaXRjS9 for ; Mon, 22 May 2017 10:47:03 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DF6127077 for ; Mon, 22 May 2017 10:47:03 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id g126so2049420ith.0 for ; Mon, 22 May 2017 10:47:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uwCuF4jKR75txpFEvip3D266YUYbUPigYzMU8saGoGk=; b=YF7Zq0RPxVv4UOkB7HXUgmMGpLL6B5b4sso3SVYIjSMjn5NRxKEHTAaVcxWaAip0xO k9/9sVbUvA1U3r+tM31UqYnZSXT9WvREhBPvLPttHUTZ0ZVtSPP6xwERE46SnQW7whqR IyWlkhMIx9nlWVtmRgGU4+vVGk90w6QS+/3Ds7bYPN+qRu/VOSnYNK8VxU22n6tc9PZX rUkelYPbQWJ/+pBUMDmO1LnNGPD+sTrjo8pDT4GG1qhtXflj4iFxOAJgU5YYHdH7PaQQ u27ZcqfXn1u6+DkIyaizkmOeyYRuPbrLUJR0jwPR+8XLB5ikkuWZFEc5e8/528hypd+2 Pf6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uwCuF4jKR75txpFEvip3D266YUYbUPigYzMU8saGoGk=; b=mmJSd+LhgtZRUfDATwuNIS4Vn69Cun12Fm8xDdaKseWU+UplnhGgiRsYIA0hNyw5ag c1/SqiEfLq5Fim1ijJe9KYasYdIGbQMSWt3Yp4Xs7ZTIj5lEfvaITvOCp+4LHaQMvOob kXfrv90nw20JcpWKHLYt5g3JYy7xGJtdFekXy5h/bSHP3+ovaEPoj8VMd+YMCcpEOajY LjmJah56q2PYONcAfZkq8rXOfMOlf5l8EXU2KIrkyppMr/qB/b+aaTmBMChwV7AfD6BC aj91dFLGqY7UtF8fT9p0oarndQbitYLq0IHYw3RLtTw68cNuP/h2SjvmC6JXbbU/Xf2B AT0Q==
X-Gm-Message-State: AODbwcByMmnSxEe/5o6RDGeJeyUVrYTeK4JgNP2bKjascGu671YypPjF 8NNl9Xzp8UPCRuomei4/1Ii176mPsw==
X-Received: by 10.36.190.133 with SMTP id i127mr41642252itf.41.1495475222766;  Mon, 22 May 2017 10:47:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.92 with HTTP; Mon, 22 May 2017 10:47:02 -0700 (PDT)
In-Reply-To: 
References:  
From: Balaji Rajendran 
Date: Mon, 22 May 2017 23:17:02 +0530
Message-ID: 
To: Martin Thomson 
Cc: Sankalp Bagaria , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c19d4e46c6a4c0550207513"
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-00.txt (internet-drafts@ietf.org)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:47:06 -0000

--94eb2c19d4e46c6a4c0550207513
Content-Type: text/plain; charset="UTF-8"

Hi,

   While trying to obtain an authenticator, the private key used for
signing the certificate is demanded.

   Is it safe to do such operations or is it the public key associated with
the Certificate?

--
Balaji R

On Mon, May 22, 2017 at 11:30 AM, Martin Thomson 
wrote:

> This defines a tool, in the same way that RFC 5705 does.  See
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
> for a use of that tool.
>
> On 22 May 2017 at 15:52, Sankalp Bagaria  wrote:
> > Hi,
> >
> > I have a couple of questions:
> > 1) How will the out-of-band request for certificate be sent by the
> server/
> > client ?
> > What format will be used ? (Only Reply's format is given in draft)
> > 2a) If certificate verification is unsuccessful, will the existing
> > connection also be
> > dropped or will it be continued ?
> > 2b) If certificate verification is successful, how will the state of the
> > connection
> > change ? Will there be a re-direction to new entity ? If yes, how will
> that
> > be
> > achieved ?
> >
> > Regards,
> > Sankalp Bagaria.
> >
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: Thu, 18 May 2017 14:04:38 -0700
> >> From: internet-drafts@ietf.org
> >> To: 
> >> Cc: tls@ietf.org
> >> Subject: [TLS] I-D Action:
> >>         draft-ietf-tls-exported-authenticator-00.txt
> >> Message-ID: <149514147857.6720.16783609697509356369@ietfa.amsl.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the Transport Layer Security of the IETF.
> >>
> >>         Title           : Exported Authenticators in TLS
> >>         Author          : Nick Sullivan
> >>         Filename        : draft-ietf-tls-exported-authenticator-00.txt
> >>         Pages           : 6
> >>         Date            : 2017-05-18
> >>
> >> Abstract:
> >>    This document describes a mechanism in Transport Layer Security (TLS)
> >>    to provide an exportable proof of ownership of a certificate that can
> >>    be transmitted out of band and verified by the other party.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-00
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-
> exported-authenticator-00
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >>
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>

--94eb2c19d4e46c6a4c0550207513
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

=C2=A0 =C2=A0While trying to =
obtain an authenticator, the private key used for signing the certificate i=
s demanded.=C2=A0

=C2=A0 =C2=A0Is it safe to do su=
ch operations or is it the public key associated with the Certificate?=C2=
=A0

--
Balaji R

On Mon, May 22, 2017 at 11:30 AM, Ma=
rtin Thomson <martin.thomson@gmail.com> wrote:
This defines a tool, in the same way that RFC 5=
705 does.=C2=A0 See

https://tools.ietf.org/html/<=
wbr>draft-bishop-httpbis-http2-additional-certs

for a use of that tool.




On 22 May 2017 at 15:52, Sankalp Bagaria <sankalp.nitt@gmail.com> wrote:

> Hi,

>

> I have a couple of questions:

> 1) How will the out-of-band request for certificate be sent by the ser=
ver/

> client ?

> What format will be used ? (Only Reply's format is given in draft)=


> 2a) If certificate verification is unsuccessful, will the existing

> connection also be

> dropped or will it be continued ?

> 2b) If certificate verification is successful, how will the state of t=
he

> connection

> change ? Will there be a re-direction to new entity ? If yes, how will=
 that

> be

> achieved ?

>

> Regards,

> Sankalp Bagaria.

>

>>

>>

>> ------------------------------

>>

>> Message: 3

>> Date: Thu, 18 May 2017 14:04:38 -0700

>> From: internet-drafts@=
ietf.org

>> To: <i-d-announce@ietf=
.org>

>> Cc: tls@ietf.org

>> Subject: [TLS] I-D Action:

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tls-exported-auth=
enticator-00.txt

>> Message-ID: <149514147857.6720.16783609697509356369@ietfa.amsl.com>

>> Content-Type: text/plain; charset=3D"utf-8"

>>

>>

>> A New Internet-Draft is available from the on-line Internet-Drafts=


>> directories.

>> This draft is a work item of the Transport Layer Security of the I=
ETF.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0: Exported Authenticators in TLS

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 : Nick Sullivan

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : draft-ietf-tls-exported-authenticator-00.txt

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0: 6

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : 2017-05-18

>>

>> Abstract:

>>=C2=A0 =C2=A0 This document describes a mechanism in Transport Laye=
r Security (TLS)

>>=C2=A0 =C2=A0 to provide an exportable proof of ownership of a cert=
ificate that can

>>=C2=A0 =C2=A0 be transmitted out of band and verified by the other =
party.

>>

>>

>> The IETF datatracker status page for this draft is:

>> https://datatracker.=
ietf.org/doc/draft-ietf-tls-exported-authenticator/

>>

>> There are also htmlized versions available at:

>> https://tools.ietf.org/=
html/draft-ietf-tls-exported-authenticator-00

>>

>> https://datat=
racker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-00=


>>

>>

>> Please note that it may take a couple of minutes from the time of<=
br>
>> submission

>> until the htmlized version and diff are available at tools.ietf.org.

>>

>> Internet-Drafts are also available by anonymous FTP at:

>> ftp://ftp.ietf.org/internet-drafts/

>>

>>

>>

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls

>










--94eb2c19d4e46c6a4c0550207513--


From nobody Mon May 22 10:56:24 2017
Return-Path: 
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 E2151127137 for ; Mon, 22 May 2017 10:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 Bb_In7mBgtsn for ; Mon, 22 May 2017 10:56:21 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312EC1270AC for ; Mon, 22 May 2017 10:56:21 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l74so63590370ywe.2 for ; Mon, 22 May 2017 10:56:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P02zQw0xL+OuVAhbU9dD8I/LJKgABfj6510XIVdwzKU=; b=0Vbn5rG1lxv/1KSOAmvwsNxQGqhk4bEaA7uMeIVh3MWy3Hv+5NzKbQP0i/b+l7H7EM dbc+VcpDd55j3TKql5w94sPIkU+nSW4H8EGQjc3b3Ct0KgZa0q2QHC/yNHuVVOYVUU8d ncPbk/fxayOe10shIkett+dQ7QU1l8xrHpo3OIhIWSVmFoqSpke0zvCtoQOeWDB/qfS1 1+wTeodds+Sl9D8gPS02DF/eC3714X7cmabJYtM2p5zlIbrVlmKCL3o9UmPiZvd5RAcM K3cUILNAkOZsAvP2Wmz/12dFRRaf4hAcPzI0BH4Ip59HQLmCBED4uPl4YN8GZAf4Uhsg LFxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P02zQw0xL+OuVAhbU9dD8I/LJKgABfj6510XIVdwzKU=; b=fZkVxguBDGQImU6+Wu87chL1xj9FHFTpQwnapdAqy+HUtC3Io/f1uOD+Wyyet8j1xR Tumn9gHO8IGl4NfkHPiXQ4+q4yguobigNyyOIEk01NQ/VPIm/ggnrAgOXU1EYKAX817R 9O8XjTQYSrbbB5BZGRUQ3hyerdle4qhmzq3RyS19Ie2OVoXXUpdaCt2pxuC4NbD+jfv5 56Qq8y6eHpmXo7zKqZ6/1SkDI0rpMO4WgPShndmGnlDy6EnDTHL72TL5zMggInDKftBx gsZ+h4iFMhYx1CiiGyNrgXHv/RDh2hmzLgJbt3Xakgai1zIXEjjb3dbUCG5+hvX1rryO GHnw==
X-Gm-Message-State: AODbwcDVI5DYcMRRBvtPqcpmRA7vS0w4T3H0+HFQCbMwTWNjC3IRClbI AzhWGYh3jabkVTy/sZGBxIrhCiVXTQ91
X-Received: by 10.129.152.68 with SMTP id p65mr19409630ywg.1.1495475780437; Mon, 22 May 2017 10:56:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Mon, 22 May 2017 10:56:19 -0700 (PDT)
In-Reply-To: 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>     
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Mon, 22 May 2017 10:56:19 -0700
Message-ID: 
To: Christian Huitema 
Cc: Kyle Nekritz , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0ba6caa9dee00550209608"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:56:23 -0000

--94eb2c0ba6caa9dee00550209608
Content-Type: text/plain; charset="UTF-8"

On Mon, May 22, 2017 at 10:46 AM, Christian Huitema 
wrote
>
> Check DKG's analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail-
> archive/web/dns-privacy/current/msg01276.html. There is only one point of
> concern, a minor privacy leak if the DNS queries in the 0-RTT data can be
> replayed at intervals chosen by the attacker. The idea is to replay the
> data to a resolver, and then observe the queries going out to authoritative
> servers in clear text. The correlation can be used to find out what domain
> the client was attempting to resolve. The attack requires "chosen time" by
> the attacker, and thus will probably be mitigated by a caching system that
> prevents replays after a short interval.
>


I have a reply to that too, linked at the bottom: there's actually a more
trivial side-channel (due to non-idempotence) that hadn't been considered
in the original analysis.

I've yet to find /any/ example application where 0-RTT replay would
actually be side-channel free.

-- 
Colm

--94eb2c0ba6caa9dee00550209608
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, May 22, 2017 at 10:46 AM, Christian Huitema &=
lt;huitema@huitema=
.net> wrote

    Check DKG's analysis of 0-RTT for DNS over TLS:
    https://www.ietf.org/mail-archive/web/dns-privacy/cur=
rent/msg01276.html.
    There is only one point of concern, a minor privacy leak if the DNS
    queries in the 0-RTT data can be replayed at intervals chosen by the
    attacker. The idea is to replay the data to a resolver, and then
    observe the queries going out to authoritative servers in clear
    text. The correlation can be used to find out what domain the client
    was attempting to resolve. The attack requires "chosen time" =
by the
    attacker, and thus will probably be mitigated by a caching system
    that prevents replays after a short interval.

I have a reply to that too, linked at the botto=
m: there's actually a more trivial side-channel (due to non-idempotence=
) that hadn't been considered in the original analysis.

<=
/div>
I've yet to find /any/ example application where 0-RTT replay=
 would actually be side-channel free.=C2=A0

-- 
Colm



--94eb2c0ba6caa9dee00550209608--


From nobody Mon May 22 10:56:42 2017
Return-Path: 
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 BBEE5127342; Mon, 22 May 2017 10:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 Ag-4NVWKpHkx; Mon, 22 May 2017 10:56:31 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED64C129B9E; Mon, 22 May 2017 10:56:30 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4MHqVmb007991; Mon, 22 May 2017 18:56:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=yhorxEs9LKFm0uuLinRGQJti/QWtgfJ6vYFUFqS8VUg=; b=UydWlUnF60qKyQybA7zMv0OFtWDrTHmcioIjwM/V5VZAPMHALJ3MR2YNw3B3hsjFksV4 uzvl/xCl1+7exlWyyERbHTD1ITblkd4s+oC0Zf7AdtdwBGD3VyPjUs0KCJ48P+97Ybsy h/twPgeHt+4bAsHg1Z2hM7ZtDy+sWbeWQsZ21a5VUq+IUm9Te9b5vSGE7O9qCCDKz/K/ 5vRQ9RGPERGTNpaXS7PiTji3ZKIFEEcnrXMLGqHevw1pZOcXzqPXyebq0XEURmxLGU24 3cruFLCQPnrKZZDo/BifKs5uv41oJzCxiU+t6D2DOk/muywqml9wYx1/3IvWxkE2VKVf IQ== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2aje78c28j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 May 2017 18:56:27 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4MHu0he011908; Mon, 22 May 2017 13:56:26 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ajh4v3mbc-1; Mon, 22 May 2017 13:56:25 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 5C2012007F; Mon, 22 May 2017 11:56:25 -0600 (MDT)
To: Daniel Migault , "tls@ietf.org" 
Cc: tls-chairs 
References: <149522417333.23956.7024977757521677892.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDBB01@eusaamb107.ericsson.se>
From: Benjamin Kaduk 
Message-ID: 
Date: Mon, 22 May 2017 12:56:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDBB01@eusaamb107.ericsson.se>
Content-Type: multipart/alternative; boundary="------------EB8215E7C99344C8092E778B"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220094
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705220094
Archived-At: 
Subject: Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 17:56:40 -0000

This is a multi-part message in MIME format.
--------------EB8215E7C99344C8092E778B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Thanks for the updates; the new revision addresses my concerns raised in
the secdir review.

However,

% In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2
% [RFC4346] splits the pre-master in two parts.

s/TL1.2/TLS 1.1/, and maybe the ending as "split the pre-master secret
into two parts".

% the PSK and pre-master are treated by
% distinct hash function with distinct properties.

s/pre-master/ECDHE shared secret/?

-Ben

On 05/19/2017 03:18 PM, Daniel Migault wrote:
> Hi, 
>
> Thank you to all reviewers for their feed backs. Please find the latest version, which as far as I know includes all comments. Comments were not controversial. In order to raise next reviews I am raising aspects that might need a bit more attention.  
>
> 1)  The current document mentions I-D.ietf-tls-rfc4492bis and I-D.ietf-tls-tls13 as normative. We can wait for these documents to become RFCs, but we can also dowref them to informational reference if we want to move that document forward. I will leave the AD to decide, and changes if needed can be done by the RFC -editor
>
> 2)  Section 4 has the following text:
>
> """In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties.  This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be  used with ECDHE_PSK. """
>
> With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher suites defined in the document.  I just want to make sure we are ok with the last sentence. 
>
> Yours, 
> Daniel
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Friday, May 19, 2017 4:03 PM
> To: John Mattsson ; Daniel Migault ; tls-chairs@ietf.org
> Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
>
>
> A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
> has been successfully submitted by Daniel Migault and posted to the IETF repository.
>
> Name:		draft-ietf-tls-ecdhe-psk-aead
> Revision:	04
> Title:		ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)
> Document date:	2017-05-18
> Group:		tls
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-04
>
> Abstract:
>    This document defines several new cipher suites for the Transport
>    Layer Security (TLS) protocol.  The cipher suites are all based on
>    the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>    (ECDHE_PSK) key exchange together with the Authenticated Encryption
>    with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>    provides light and efficient authentication, ECDHE provides forward
>    secrecy, and AES-GCM and AES-CCM provides encryption and integrity
>    protection.
>
>                                                                                   
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------EB8215E7C99344C8092E778B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Thanks for the updates; the new revision addresses my concerns
      raised in the secdir review.

      

      However,

      

      % In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2

      % [RFC4346] splits the pre-master in two parts.

      

      s/TL1.2/TLS 1.1/, and maybe the ending as "split the pre-master
      secret into two parts".

      

      % the PSK and pre-master are treated by

      % distinct hash function with distinct properties.

    

    s/pre-master/ECDHE shared secret/?

    

    -Ben

    

    
On 05/19/2017 03:18 PM, Daniel Migault
      wrote:

    

    

      
Hi, 

Thank you to all reviewers for their feed backs. Please find the latest version, which as far as I know includes all comments. Comments were not controversial. In order to raise next reviews I am raising aspects that might need a bit more attention.  

1)  The current document mentions I-D.ietf-tls-rfc4492bis and I-D.ietf-tls-tls13 as normative. We can wait for these documents to become RFCs, but we can also dowref them to informational reference if we want to move that document forward. I will leave the AD to decide, and changes if needed can be done by the RFC -editor

2)  Section 4 has the following text:

"""In the case of ECDHE_PSK authentication, the PSK and pre-master are treated by distinct hash function with distinct properties.  This may introduce vulnerabilities over the expected security provided by the constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be  used with ECDHE_PSK. """

With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher suites defined in the document.  I just want to make sure we are ok with the last sentence. 

Yours, 
Daniel

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Friday, May 19, 2017 4:03 PM
To: John Mattsson <john.mattsson@ericsson.com>; Daniel Migault <daniel.migault@ericsson.com>; tls-chairs@ietf.org
Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt


A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name:		draft-ietf-tls-ecdhe-psk-aead
Revision:	04
Title:		ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)
Document date:	2017-05-18
Group:		tls
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-04

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol.  The cipher suites are all based on
   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
   (ECDHE_PSK) key exchange together with the Authenticated Encryption
   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
   provides light and efficient authentication, ECDHE provides forward
   secrecy, and AES-GCM and AES-CCM provides encryption and integrity
   protection.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------EB8215E7C99344C8092E778B--


From nobody Mon May 22 12:17:42 2017
Return-Path: 
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 29ACB127863 for ; Mon, 22 May 2017 12:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OItAmN3kkbcJ for ; Mon, 22 May 2017 12:17:39 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1115F12773A for ; Mon, 22 May 2017 12:17:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8BECA244CF; Mon, 22 May 2017 22:17:36 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id HuyiK_IO-zWm; Mon, 22 May 2017 22:17:35 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id CCD4627B; Mon, 22 May 2017 22:17:35 +0300 (EEST)
Date: Mon, 22 May 2017 22:17:34 +0300
From: Ilari Liusvaara 
To: Balaji Rajendran 
Cc: Martin Thomson , "tls@ietf.org" ,  Sankalp Bagaria 
Message-ID: <20170522191734.GA12974@LK-Perkele-V2.elisa-laajakaista.fi>
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-00.txt (internet-drafts@ietf.org)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 19:17:41 -0000

On Mon, May 22, 2017 at 11:17:02PM +0530, Balaji Rajendran wrote:
> Hi,
> 
>    While trying to obtain an authenticator, the private key used for
> signing the certificate is demanded.
>
>    Is it safe to do such operations or is it the public key associated with
> the Certificate?

The private key needed is the private key corresponding with the public
key in end-entity SubjectPublicKeyInfo in the exported authenticator.

This is analogous with the main TLS handshake. However, the key used
might be different with what was used for the main handshake.

Specifically, if the certificate in main handshake and exported
authenticator have the same SubjectPublicKeyInfo, then the private
keys used will be the same. If the SubjectPublicKeyInfo's are
different, then the private keys will be different.



-Ilari


From nobody Mon May 22 12:43:31 2017
Return-Path: 
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 128D7120727 for ; Mon, 22 May 2017 12:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 1r23wtoiyU2I for ; Mon, 22 May 2017 12:43:27 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6E8120724 for ; Mon, 22 May 2017 12:43:27 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id b68so64919257ywe.3 for ; Mon, 22 May 2017 12:43:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/6TSy7LGh6VBSGM2RBhFc0kJajIw9FlnMNUnPvo7WZE=; b=Nlx8FfsUBAYJXv4/NIljzaVTR0CuMjFTjXY8c49EJ/H7kffuVdTQZ/CHXxzSkwZwgB PWTaEIYAmZ/h6pAi8VTLCyyGbeAAJ3AdG6pX/vx3paj5Bj9+HejWIDrAGrFKzuevNwkC w0CNVp27JnF0U+QtFmiHIRAvRg6+XSLm0cWhdCG6YEEImWD45sM4Se6ipDPTDFMPS41u 3OtaNoN0grbbrfCBaR204bbT4YghRRkMhJn245sUtee95XX2/A4B41v++ep0Y3L64eHV vfKNBwTakU1DefhKcGxhv6DM/gkzrZWzLrUTDP7rAcVLfBbALkVrbsdb99JjcUeLvtsl a2mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/6TSy7LGh6VBSGM2RBhFc0kJajIw9FlnMNUnPvo7WZE=; b=tgSzNm+WZnEdIafjaSZhr6kvaVwCRE+bc8xFJIUWbC/AX/CFujaniYmAa8k8bjL7B6 /oSSLELizuZ+wNBsopD1B70DMI6dl1Q7+gGIiYtBN72zXHOF0LdI50bU2DpL2pq8Ltge IW+cDo5qb/XmJcHn0Wv2MQF9HIdpSgzooipiNEK4dgQzfqDdLHMmeIVo3DcEHQ9NIgOP jSF7QeGIJQ2ddfLnftpF1Wy8j6oqU9CiW/HDNS/tHYZrzYjvPbb5EES27K85K51kmhvA +ig5G7xYgVqRIWe1oYga5Fq4vBwXCiEN0sWIILInqAOjYVOnRxxyigdzmXqjPNNoNITN 8yhg==
X-Gm-Message-State: AODbwcCUoqHv4zn7Zm+rLnt6JcCK6jVHK5pnKOo0oxCZL+k6WbbG5KWP 3zwJaekpuzDJGaGbuovkDRU609uQ84tKuNc=
X-Received: by 10.129.85.83 with SMTP id j80mr19902519ywb.283.1495482206329; Mon, 22 May 2017 12:43:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Mon, 22 May 2017 12:42:45 -0700 (PDT)
In-Reply-To: <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>
From: Eric Rescorla 
Date: Tue, 23 May 2017 04:42:45 +0900
Message-ID: 
To: TLS WG 
Content-Type: multipart/alternative; boundary="001a113f3cbead397205502215fc"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 19:43:29 -0000

--001a113f3cbead397205502215fc
Content-Type: text/plain; charset="UTF-8"

Well, I certainly think past the Web PKI, because one of the cases I care
about
is WebRTC, which doesn't do any PKI validation at all.

In any case, I think there are two issues:
1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
2. Require a specific failure if the peer presents such a certificate.

There was pretty strong consensus to do #1 and I don't support removing
it. That seems like a pretty modest layering violation. If people think that
the mandate for this specific alert is too onerous, I could live with
removing
that.

-Ekr


On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni 
wrote:

>
> > On May 22, 2017, at 1:37 PM, Salz, Rich  wrote:
> >
> > I strongly believe the text should stay as it is, for the most good to
> the most people.  Viktor is in the weeds, arguably by himself.
>
> Right, all by myself...  With support from Nico, Ilari, and others who've
> upthread
> accepted that certificate verification is properly RFC5280 and not TLS,
> before I
> suggested removal of the text in question (which solves no real problem,
> but does
> create needless interoperability issues for various TLS use-cases).
>
> The dominant use case is not the only one that needs consideration,
> and text that breaks other use-cases is NOT just fine, and the TLS
> WG really does need to think more broadly than the Web PKI.  This is
> not the HTTPS working group.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113f3cbead397205502215fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Well, I certainly think past the Web PKI, because one=
 of the cases I care about
is WebRTC, which doesn't do any PK=
I validation at all.

In any case, I think there ar=
e two issues:
1. Forbid TLS 1.3 implementations from accepting MD=
5 and SHA-1.
2. Require a specific failure if the peer presents s=
uch a certificate.

There was pretty strong consens=
us to do #1 and I don't support removing
it. That seems like =
a pretty modest layering violation. If people think that
the mand=
ate for this specific alert is too onerous, I could live with removing
that.=C2=A0

-Ekr


On Tue, May 23, 201=
7 at 2:46 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> =
wrote:


> On May 22, 2017, at 1:37 PM, Salz, Rich <rsalz@akamai.com> wrote:

>

> I strongly believe the text should stay as it is, for the most good to=
 the most people.=C2=A0 Viktor is in the weeds, arguably by himself.



Right, all by myself...=C2=A0 With support from Nico, Ilari, and oth=
ers who've upthread

accepted that certificate verification is properly RFC5280 and not TLS, bef=
ore I

suggested removal of the text in question (which solves no real problem, bu=
t does

create needless interoperability issues for various TLS use-cases).=C2=A0


The dominant use case is not the only one that needs consideration,

and text that breaks other use-cases is NOT just fine, and the TLS

WG really does need to think more broadly than the Web PKI.=C2=A0 This is
not the HTTPS working group.




--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113f3cbead397205502215fc--


From nobody Mon May 22 13:17:38 2017
Return-Path: 
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 E3874120727 for ; Mon, 22 May 2017 13:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 AKGPiWFv82Xu for ; Mon, 22 May 2017 13:17:35 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63658128954 for ; Mon, 22 May 2017 13:17:35 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id D726520051C27; Mon, 22 May 2017 13:17:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Rhmw/hb6EpcX41 KcF2rQpzDRSnU=; b=oDaAO1ReinDyELtCT6W39Vs7j0cHWnRy4nHPoNsPKxDi/q gqSdgnT6Avs2Ef0NxtkFbQVLVKfsj7TeoC4RNeJPhOPZOdfGg3h91sb4HW+VnJzl sOy6cKlZNoaMMZ5SrKjz9d3RUXij2/s6bBVGc8BbGYzQCauzjds9H3uAv48X4=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 9618320051C22; Mon, 22 May 2017 13:17:34 -0700 (PDT)
Date: Mon, 22 May 2017 15:17:30 -0500
From: Nico Williams 
To: Eric Rescorla 
Cc: TLS WG 
Message-ID: <20170522201729.GO10188@localhost>
References: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:17:37 -0000

On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote:
> Well, I certainly think past the Web PKI, because one of the cases I
> care about is WebRTC, which doesn't do any PKI validation at all.
> 
> In any case, I think there are two issues:
> 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> 2. Require a specific failure if the peer presents such a certificate.
> 
> There was pretty strong consensus to do #1 and I don't support removing
> it. That seems like a pretty modest layering violation. If people think that
> the mandate for this specific alert is too onerous, I could live with
> removing
> that.

I don't understand how you can have (1) and not (2).

Unlike Viktor (though I also don't like the layering violation) I'm not
proposing removing that text altogether, but tweaking it to allow
opportunistic and other TLS usage.

Instead of altogether forbidding certs with MD5 signatures, forbid them
when the application expects TLS to authenticate the server [with PKIX,
as opposed to certain DANE usage values, or with pre-shared certs,
etc.].  I.e., a server authentication security level knob is needed.

Nico

> On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni 
> wrote:
> > > On May 22, 2017, at 1:37 PM, Salz, Rich  wrote:
> > > I strongly believe the text should stay as it is, for the most good to
> > the most people.  Viktor is in the weeds, arguably by himself.
> >
> > Right, all by myself...  With support from Nico, Ilari, and others
> > who've upthread accepted that certificate verification is properly
> > RFC5280 and not TLS, before I suggested removal of the text in
> > question (which solves no real problem, but does create needless
> > interoperability issues for various TLS use-cases).
> >
> > The dominant use case is not the only one that needs consideration,
> > and text that breaks other use-cases is NOT just fine, and the TLS
> > WG really does need to think more broadly than the Web PKI.  This is
> > not the HTTPS working group.


From nobody Mon May 22 13:18:43 2017
Return-Path: 
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 766A5120454 for ; Mon, 22 May 2017 13:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=symc.onmicrosoft.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 swsXzTbYwj5o for ; Mon, 22 May 2017 13:18:39 -0700 (PDT)
Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFB5120727 for ; Mon, 22 May 2017 13:18:39 -0700 (PDT)
Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat3.net.symantec.com [10.44.130.3]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 52.C4.40682.09743295; Mon, 22 May 2017 20:18:24 +0000 (GMT)
X-AuditID: 0a2c7e31-dc6d39a000009eea-f1-59234790cf9d
Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat8.net.symantec.com [10.44.130.8]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id D5.5A.58529.E8743295; Mon, 22 May 2017 20:18:24 +0000 (GMT)
Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 22 May 2017 13:18:22 -0700
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.128.4) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 22 May 2017 13:18:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com;  s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hBhzDp2i5u8YMjKr4AId93CGxnF44B2b5QQgO8X1Fyw=; b=vLFF9CFFlGKX9YXviKggUAGCEoOvz1Au1fkTmU7MAq968pxZ7J6/VEkhBhyTqq+FDDWFK14ULggrJXK5V7roM36P3xelyiphfV6Vd9fKFffDhGLnatu7vFvhaXRtFuea3IIpn+38H3jdNLHvNhkiTwoBVnYS1En+lQesKH1ER3Y=
Received: from DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) by DM5PR16MB1836.namprd16.prod.outlook.com (10.172.45.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Mon, 22 May 2017 20:18:21 +0000
Received: from DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) by DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) with mapi id 15.01.1084.025; Mon, 22 May 2017 20:18:21 +0000
From: Roelof Du Toit 
To: TLS WG 
Thread-Topic: Which version to use in ClientKeyExchange when using supported_versions extension
Thread-Index: AQHS0ziOX/zkABdZBUaGTOeOXDMWxg==
Date: Mon, 22 May 2017 20:18:20 +0000
Message-ID: <1CA8423D-0247-42E1-9D49-1BE76C348970@symantec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=symantec.com;
x-originating-ip: [72.23.5.194]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR16MB1836; 7:4Lct8GJKO+DUU6eICSrTW9GRV9yTAUW4CKsfGt1TD4RhF96OUtjpZmB7pimCAGt5gI79Yn4LL4BpOkK5zU/FFgrc45k5eiN0oqb9qL44+ig5eGLZRraVh8Ms4g8xTevyP449oE45VSuV9Uuztvf+IgTbDthHVqYgwzDRsaU5w3T+4CG+PMDOHcEtRZlMCDv/BjVlgdR35ODBfKomQxXTuo/Yhg+VS7Bwx4B9bnS/hpCKoX4GUs+B1KIDpUKWry16gqiE8wNi3dQyGgu/T229WYEVETZAFvXH8V8fva7FMWrk7JtwdxZSYkwb07AfP0ceDHO+v1yX74Re4Wv7hJYaaQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(50986999)(81166006)(8936002)(54356999)(6506006)(6916009)(6116002)(2900100001)(6436002)(3846002)(8676002)(6512007)(7736002)(53936002)(5660300001)(54896002)(6306002)(102836003)(6486002)(10290500003)(2906002)(99286003)(86362001)(3280700002)(80792005)(38730400002)(110136004)(3660700001)(25786009)(33656002)(66066001)(82746002)(478600001)(189998001)(122556002)(72206003)(83716003)(36756003)(77096006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1836; H:DM5PR16MB1834.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-office365-filtering-correlation-id: 5c95cfb5-6958-4030-43d0-08d4a14fb10e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM5PR16MB1836; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DM5PR16MB1836; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1836; 
x-forefront-prvs: 03152A99FF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_1CA8423D024742E19D491BE76C348970symanteccom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 20:18:20.8530 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1836
X-OriginatorOrg: symantec.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXCpdPErDvBXTnS4NcaaYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8W/3N8aCG8EVz7fVNTCuD+xi5OSQEDCReHVwJnsXIxeHkMAn RomDNxuYYBJTps4Es4UEfjBKPF0FVXSUUWLG8zNQiReMEg+euYEkWAQ6mSXW729hgqiawiRx btETNgjnEKPE3cXNrCAtbAKGEj8PTAKzRQQkJT73ngGzhQViJM6u38IOEU+UmNZ4mwXC1pPo 3rifGcRmEVCVeP2hFayGV8BeYvfzuWwgNqOAmMT3U2vATmIWEJe49WQ+1A8CEkv2nGeGsEUl Xj7+xwpyEKNAN6PE1j37GSES8hL3n56GsmUlLs3vhrJ7mCWeL/QGaQCyWSU2TrgINdVX4u6E T1BFdRJ7NryHimdL7JsxlRXC9pbYfuo6C4T9iUli0+NKCFtG4vnUiSwQH0tJ3L3SyTiBUXsW ksMh7GSJCWf/MM8Ce1RQ4uTMJyyzGDmA4poS63fpQ5QoSkzpfsgOYWtItM6ZC2V7SMw+M4cZ Wc0CRo5VjAolpcXFuSX5pSWJBakGhnrFlbnJICIRmJSS9ZLzczcxghNTneEOxkcbfA4xCnAw KvHwrnZVjhRiTSwDqgTGIgezkghvHjtQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+tebcihATS E0tSs1NTC1KLYLJMHJxSDYzO6Xs/5non3RF+FNzjIOMs6Jzw60whP3ef5LGEqJeNXp4GciUM Km8+lX5a9vj91qqDQuYlewNMsk+xXtLInR6+fp1Xr57JlQMqsx0Yu3MYLrUnp6T37tyRanOk oPZhQ/jOirdNpjcm3akOvCJqsuzGpyq3KqcHBpqLU+2Xv0zRWf9/+tKCl0osxRmJhlrMRcWJ AESiUvdIAwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXCpdPEoTvBXTnS4Fsfn8Wn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+Lf7G2PBjeCK59vqGhjXB3YxcnJICJhITJk6kwnEFhL4wSjx dBV7FyMXkH2UUWLG8zNQiReMEg+euYEkWAQ6mSXW729hgqiawiRxbtETNgjnEKPE3cXNrCAt bAKGEj8PTAKzRQQkJT73ngGzhQViJM6u38IOEU+UmNZ4mwXC1pPo3rifGcRmEVCVeP2hFayG V8BeYvfzuWwgNqOAmMT3U2vATmIWEJe49WQ+E8QPAhJL9pxnhrBFJV4+/scKchCjQDejxNY9 +xkhEvIS95+ehrJlJS7N74aye5glni/0BmkAslklNk64CDXVV+LuhE9QRXUSeza8h4pnS+yb MZUVwvaW2H7qOguE/YlJYtPjSghbRuL51IksEB9LSdy90skIYctIvLizlxXig2SJCWf/ME9g VJ+F5KFZSFKzwAEgKHFy5hOWWYwcQHFNifW79CFKFCWmdD9kh7A1JFrnzIWyPSRmn5nDjKxm ASPHKkaFktLi4tyS3JLExIJMAyO94srcZBCRCExJyXrJ+bmbGMFpyVlyB+OhPz6HGAU4GJV4 eDUeK0UKsSaWAVUeYpTmYFES5zVZJRIpJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFXyuzs poLlhkHTPji9zyrlEXct+cyUU3H085vwaeXTz+amb2mzXDX7fMPKeP0O/t1v/6/7JWHXNi2g Mbng7nMDm8s3BPasOpJ9aaNpgWPRr3ivfS3/JPJztxv/vLyv1iY54quKas7Zk99z4rTsZ815 ouR8lvuD9frJT00D5pWvddGdkOIXbq7EUpyRaKjFXFScCADtyYWtLAMAAA==
X-CFilter-Loop: TUS02
Archived-At: 
Subject: [TLS] Which version to use in ClientKeyExchange when using supported_versions extension
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:18:41 -0000

--_000_1CA8423D024742E19D491BE76C348970symanteccom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UkZDIDUyNDYgaGFzIHRoZSBmb2xsb3dpbmcgaW4gc2VjdGlvbiA3LjQuNy4xIChSU0EtRW5jcnlw
dGVkIFByZW1hc3RlciBTZWNyZXQpOg0KDQogICAgY2xpZW50X3ZlcnNpb24NCiAgICAgICAgIFRo
ZSBsYXRlc3QgKG5ld2VzdCkgdmVyc2lvbiBzdXBwb3J0ZWQgYnkgdGhlIGNsaWVudC4gIFRoaXMg
aXMNCiAgICAgICAgIHVzZWQgdG8gZGV0ZWN0IHZlcnNpb24gcm9sbGJhY2sgYXR0YWNrcy4NCg0K
VGhlIFRMUyAxLjMgZHJhZnQgc3BlY2lmaWNhdGlvbiBoYXMgdGhlIGZvbGxvd2luZyBpbiBzZWN0
aW9uIDEuNCAoVXBkYXRlcyBBZmZlY3RpbmcgVExTIDEuMikNCg0KICAgIFRoZSDigJxzdXBwb3J0
ZWRfdmVyc2lvbnPigJ0gQ2xpZW50SGVsbG8gZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIHRvIG5lZ290
aWF0ZSB0aGUgdmVyc2lvbiBvZiBUTFMgdG8gdXNlLCBpbiBwcmVmZXJlbmNlIHRvIHRoZSBsZWdh
Y3lfdmVyc2lvbiBmaWVsZCBvZiB0aGUgQ2xpZW50SGVsbG8uDQoNCg0KSSB3b3VsZCBhcHByZWNp
YXRlIHNvbWUgY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgdGhlIHZhbHVlIG9mICJjbGllbnRfdmVy
c2lvbiIgaW4gYSBDbGllbnRLZXlFeGNoYW5nZSBpZjoNCi0gQ2xpZW50SGVsbG8ubGVnYWN5X3Zl
cnNpb24gPSBUTFMgMS4yLCBhbmQNCi0gQ2xpZW50SGVsbG8uc3VwcG9ydGVkX3ZlcnNpb25zIGV4
dGVuc2lvbiBoYXMgVExTIDEuMywgYW5kDQotIFRMUyAxLjIgaXMgbmVnb3RpYXRlZCAoZWl0aGVy
IGJlY2F1c2UgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IFRMUyAxLjMsIG9yIGJlY2F1c2Ug
dGhlIFRMUyAxLjMtY2FwYWJsZSBzZXJ2ZXIgaXMgY29uZmlndXJlZCB0byByZXNwb25kIHdpdGgg
VExTIDEuMiBmb3Igc29tZSByZWFzb24pDQoNCk15IGFzc3VtcHRpb24gaXMgdGhhdCBDbGllbnRI
ZWxsby5sZWdhY3lfdmVyc2lvbiBzaG91bGQgYmUgdXNlZCBiZWNhdXNlIHRoZSBjbGllbnQgd291
bGQgbm90IGtub3cgd2hldGhlciB0aGUgc2VydmVyIGlnbm9yZWQgdGhlIHN1cHBvcnRlZF92ZXJz
aW9ucyBleHRlbnNpb24gLSBpcyB0aGF0IGNvcnJlY3Q/DQoNCi0tUm9lbG9mDQoNCg==

--_000_1CA8423D024742E19D491BE76C348970symanteccom_
Content-Type: text/html; charset="utf-8"
Content-ID: <9A0A824DB2A5864DBCC77DA4D8F04CC4@namprd16.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4PSJ1
cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpleGNlbCIgeG1sbnM6bT0iaHR0cDovL3Nj
aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3
dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl
bnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9
IlRpdGxlIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iS2V5d29yZHMiIGNvbnRlbnQ9IiI+DQo8
bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJl
ZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJcGFub3NlLTE6MiA3IDMgOSAyIDIg
NSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2Ut
MTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJy
aWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93
ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4
dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LWZhbWlseTpDYWxpYnJpO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K
CXttc28tbGlzdC1pZDoxNTUzNzM3NDIxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc1OTA1
MzIwODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl
dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu
NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7
fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2
ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K
QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN
Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s
b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SRkMgNTI0NiBoYXMgdGhlIGZvbGxvd2luZyBpbiBzZWN0
aW9uIDcuNC43LjEgKFJTQS1FbmNyeXB0ZWQgUHJlbWFzdGVyIFNlY3JldCk6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgY2xp
ZW50X3ZlcnNpb248bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgbGF0ZXN0IChuZXdlc3QpIHZlcnNpb24g
c3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQuJm5ic3A7IFRoaXMgaXM8bzpwPjwvbzpwPjwvc3Bhbj48
L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1
c2VkIHRvIGRldGVjdCB2ZXJzaW9uIHJvbGxiYWNrIGF0dGFja3MuPG86cD48L286cD48L3NwYW4+
PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIFRMUyAxLjMgZHJhZnQgc3BlY2lmaWNh
dGlvbiBoYXMgdGhlIGZvbGxvd2luZyBpbiBzZWN0aW9uIDEuNCAoVXBkYXRlcyBBZmZlY3Rpbmcg
VExTIDEuMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyBUaGUg4oCcc3VwcG9ydGVkX3ZlcnNpb25z4oCdIENsaWVudEhlbGxv
IGV4dGVuc2lvbiBjYW4gYmUgdXNlZCB0byBuZWdvdGlhdGUgdGhlIHZlcnNpb24gb2YgVExTIHRv
IHVzZSwgaW4gcHJlZmVyZW5jZSB0byB0aGUgbGVnYWN5X3ZlcnNpb24gZmllbGQgb2YgdGhlIENs
aWVudEhlbGxvLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHdvdWxkIGFwcHJlY2lhdGUgc29tZSBjbGFyaWZp
Y2F0aW9uIHJlZ2FyZGluZyB0aGUgdmFsdWUgb2YgJnF1b3Q7Y2xpZW50X3ZlcnNpb24mcXVvdDsg
aW4gYSBDbGllbnRLZXlFeGNoYW5nZSBpZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBDbGllbnRIZWxs
by5sZWdhY3lfdmVyc2lvbiA9IFRMUyAxLjIsIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIENsaWVu
dEhlbGxvLnN1cHBvcnRlZF92ZXJzaW9ucyBleHRlbnNpb24gaGFzIFRMUyAxLjMsIGFuZDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij4tIFRMUyAxLjIgaXMgbmVnb3RpYXRlZCAoZWl0aGVyIGJlY2F1c2UgdGhl
IHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IFRMUyAxLjMsIG9yIGJlY2F1c2UgdGhlIFRMUyAxLjMt
Y2FwYWJsZSBzZXJ2ZXIgaXMgY29uZmlndXJlZCB0byByZXNwb25kIHdpdGggVExTIDEuMiBmb3Ig
c29tZSByZWFzb24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5N
eSBhc3N1bXB0aW9uIGlzIHRoYXQgQ2xpZW50SGVsbG8ubGVnYWN5X3ZlcnNpb24gc2hvdWxkIGJl
IHVzZWQgYmVjYXVzZSB0aGUgY2xpZW50IHdvdWxkIG5vdCBrbm93IHdoZXRoZXIgdGhlIHNlcnZl
ciBpZ25vcmVkIHRoZSBzdXBwb3J0ZWRfdmVyc2lvbnMgZXh0ZW5zaW9uIC0gaXMgdGhhdCBjb3Jy
ZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS1Sb2Vsb2Y8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_1CA8423D024742E19D491BE76C348970symanteccom_--


From nobody Mon May 22 13:27:22 2017
Return-Path: 
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 06BBB128BC8 for ; Mon, 22 May 2017 13:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Z3ei0v_yZfO8 for ; Mon, 22 May 2017 13:27:10 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2475128959 for ; Mon, 22 May 2017 13:27:09 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id p73so54669163ywp.0 for ; Mon, 22 May 2017 13:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hz4s7bthZCI0M4siVOr70jdo2IM73d2gwG3t3yo9NKQ=; b=ymbOlFjB+COUVP1hK9xcOOTEky2F1Rt0M+xlig+ZiplPG8Q0Fau+Bd/vB1i9CVuqOX qJDU/i81kD+JafBcEXpxP35RBGRS/whYaUXZ5fEpMmHyNQeYx4sGlXCuux7/TYFWGtUI L93XebReNiGw4gxCip0x5ph1l8CSi5bo4yQl/vZrFE6N6jF2i96FyAcKJCz4HFe+1Eb5 FICcixtH+LPvgbSR1f2mgZD96dKlbO4MqiSc5ZBFrQ9LNJVTogXYfQBfRD9lIcjlpv3L y3usifXyX2IrGT3r2YBJew5Q6fI2MACOBW8oDFYyGhzsc8PbFhBCkcc/Z1xQMgOvcNam +/gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hz4s7bthZCI0M4siVOr70jdo2IM73d2gwG3t3yo9NKQ=; b=A8yJz6WDB41cNCyhk2CcXUvzvaFEN8LsPcpcBndcVQQNcafClslVdsvRnCxcZIkBFi +NQfpACI+PreLKPVLKUyfbg+0PaJ4Mp2zM2D/c9DUlhOfT/nYJAfKvV6cY1N+4QO//AI 2qNGlogX+IWms8lT8g06xfm8WjqdbGXg3MKdLWvj8n9Z+R6bhchpzl4HpskMbSYc14iL OKGrIABjWu6B5V1YL3UXCwteFhqnNpImtVQSdWDp8IwWQTeVUROCKNrZDFIVpXrR1F6t 6wXCinWtPEVQXnTKZ0kljVUecMvQiM2yLdEne9XkFdbk818wOIUvXrr/dM2OTHfQ3uLp BpRw==
X-Gm-Message-State: AODbwcBTcV8opsvoN5Ih1hSA2GIefj2A7CJuNQsY+DyCpdX9kmfFKlPY i3Z7gaCshrIDmX7o+jZ2JPYdnTAWIupsEnYJwQ==
X-Received: by 10.129.5.14 with SMTP id 14mr20299784ywf.85.1495484829131; Mon, 22 May 2017 13:27:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Mon, 22 May 2017 13:26:28 -0700 (PDT)
In-Reply-To: <20170522201729.GO10188@localhost>
References: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>
From: Eric Rescorla 
Date: Tue, 23 May 2017 05:26:28 +0900
Message-ID: 
To: Nico Williams 
Cc: TLS WG 
Content-Type: multipart/alternative; boundary="001a114174680230fb055022b2a2"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:27:12 -0000

--001a114174680230fb055022b2a2
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 5:17 AM, Nico Williams 
wrote:

> On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote:
> > Well, I certainly think past the Web PKI, because one of the cases I
> > care about is WebRTC, which doesn't do any PKI validation at all.
> >
> > In any case, I think there are two issues:
> > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > 2. Require a specific failure if the peer presents such a certificate.
> >
> > There was pretty strong consensus to do #1 and I don't support removing
> > it. That seems like a pretty modest layering violation. If people think
> that
> > the mandate for this specific alert is too onerous, I could live with
> > removing
> > that.
>
> I don't understand how you can have (1) and not (2).
>

As Ilari suggests, you could just treat the algorithms as unknown.


Unlike Viktor (though I also don't like the layering violation) I'm not
> proposing removing that text altogether, but tweaking it to allow
> opportunistic and other TLS usage.
>
> Instead of altogether forbidding certs with MD5 signatures, forbid them
> when the application expects TLS to authenticate the server [with PKIX,
> as opposed to certain DANE usage values, or with pre-shared certs,
> etc.].  I.e., a server authentication security level knob is needed.
>

I don't think that the current text prohibits that, because of :

   The signatures on certificates that are self-signed or certificates
   that are trust anchors are not validated since they begin a
   certification path (see [RFC5280], Section 3.2).  A certificate that
   begins a certification path MAY use a signature algorithm that is not
   advertised as being supported in the "signature_algorithms"
   extension.

In this case, I think one can argue are treating this as a trust anchor.
Feel free to propose
new text that you think makes that clearer.

-Ekr


> Nico
>
> > On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni  >
> > wrote:
> > > > On May 22, 2017, at 1:37 PM, Salz, Rich  wrote:
> > > > I strongly believe the text should stay as it is, for the most good
> to
> > > the most people.  Viktor is in the weeds, arguably by himself.
> > >
> > > Right, all by myself...  With support from Nico, Ilari, and others
> > > who've upthread accepted that certificate verification is properly
> > > RFC5280 and not TLS, before I suggested removal of the text in
> > > question (which solves no real problem, but does create needless
> > > interoperability issues for various TLS use-cases).
> > >
> > > The dominant use case is not the only one that needs consideration,
> > > and text that breaks other use-cases is NOT just fine, and the TLS
> > > WG really does need to think more broadly than the Web PKI.  This is
> > > not the HTTPS working group.
>

--001a114174680230fb055022b2a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 23, 2017 at 5:17 AM, Nico Williams <nico@cryptonector.=
com> wrote:
On Tue, May 23, 2017 at 04:42:45AM +0900, Eric R=
escorla wrote:

> Well, I certainly think past the Web PKI, because one of the cases I
> care about is WebRTC, which doesn't do any PKI validation at all.<=
br>
>

> In any case, I think there are two issues:

> 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.

> 2. Require a specific failure if the peer presents such a certificate.=


>

> There was pretty strong consensus to do #1 and I don't support rem=
oving

> it. That seems like a pretty modest layering violation. If people thin=
k that

> the mandate for this specific alert is too onerous, I could live with<=
br>
> removing

> that.



I don't understand how you can have (1) and not (2).

As Ilari suggests, you could just treat the algori=
thms as unknown.



Unlike Viktor (though I also don't like the layering violation) I'm=
 not

proposing removing that text altogether, but tweaking it to allow

opportunistic and other TLS usage.



Instead of altogether forbidding certs with MD5 signatures, forbid them

when the application expects TLS to authenticate the server [with PKIX,

as opposed to certain DANE usage values, or with pre-shared certs,

etc.].=C2=A0 I.e., a server authentication security level knob is needed.

I don't think that the current text =
prohibits that, because of :

=C2=A0 =C2=A0The=
 signatures on certificates that are self-signed or certificates
=
=C2=A0 =C2=A0that are trust anchors are not validated since they begin a
=C2=A0 =C2=A0certification path (see [RFC5280], Section 3.2).=C2=A0=
 A certificate that
=C2=A0 =C2=A0begins a certification path MAY =
use a signature algorithm that is not
=C2=A0 =C2=A0advertised as =
being supported in the "signature_algorithms"
=C2=A0 =
=C2=A0extension.

In this case, I think one c=
an argue are treating this as a trust anchor. Feel free to propose
new text that you think makes that clearer.

-Ekr=





Nico




> On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>

> wrote:

> > > On May 22, 2017, at 1:37 PM, Salz, Rich <rsalz@akamai.com> wrote:

> > > I strongly believe the text should stay as it is, for the mo=
st good to

> > the most people.=C2=A0 Viktor is in the weeds, arguably by himsel=
f.

> >

> > Right, all by myself...=C2=A0 With support from Nico, Ilari, and =
others

> > who've upthread accepted that certificate verification is pro=
perly

> > RFC5280 and not TLS, before I suggested removal of the text in
> > question (which solves no real problem, but does create needless<=
br>
> > interoperability issues for various TLS use-cases).

> >

> > The dominant use case is not the only one that needs consideratio=
n,

> > and text that breaks other use-cases is NOT just fine, and the TL=
S

> > WG really does need to think more broadly than the Web PKI.=C2=A0=
 This is

> > not the HTTPS working group.





--001a114174680230fb055022b2a2--


From nobody Mon May 22 13:43:34 2017
Return-Path: 
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 3B4DF128A32 for ; Mon, 22 May 2017 13:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 1gnSRO7q154z for ; Mon, 22 May 2017 13:43:32 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEBF12702E for ; Mon, 22 May 2017 13:43:31 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 18C5020051C26; Mon, 22 May 2017 13:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bSyymB5orI/gsv +tbgi4mz6rt+8=; b=sUKJduDgFyWIbWYZH8uZsF2BpFokmA0ud3f8fr5y+UV/UV cgIJCsscK70Jym2fXwv+enTXJY1I6aqiotyYYRVdhjeRtH/sroKaNEZnkfWaKi+u J9KCCcSHuc/tR9v3PpJCHzL5usoXGACs3DLzOIv23mCbAgayaqs1zE44hHt9M=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id C745820051C24; Mon, 22 May 2017 13:43:30 -0700 (PDT)
Date: Mon, 22 May 2017 15:43:26 -0500
From: Nico Williams 
To: Eric Rescorla 
Cc: TLS WG 
Message-ID: <20170522204326.GP10188@localhost>
References: <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:43:33 -0000

On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> On Tue, May 23, 2017 at 5:17 AM, Nico Williams 
> wrote:
> > > In any case, I think there are two issues:
> > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > > 2. Require a specific failure if the peer presents such a certificate.
> > >
> > > There was pretty strong consensus to do #1 and I don't support removing
> > > it. That seems like a pretty modest layering violation. If people think
> > that
> > > the mandate for this specific alert is too onerous, I could live with
> > > removing
> > > that.
> >
> > I don't understand how you can have (1) and not (2).
> 
> As Ilari suggests, you could just treat the algorithms as unknown.

How does that square with (1)?

> > Instead of altogether forbidding certs with MD5 signatures, forbid them
> > when the application expects TLS to authenticate the server [with PKIX,
> > as opposed to certain DANE usage values, or with pre-shared certs,
> > etc.].  I.e., a server authentication security level knob is needed.
> 
> I don't think that the current text prohibits that, because of :

That takes care of DANE and pre-shared cert uses, but not of
opportunistic use.  And maybe not of TOFU either: since on first use the
server's cert won't be known to the client, it's not a "trust anchor"
yet and cannot fall under this safe-harbor.

>    The signatures on certificates that are self-signed or certificates
>    that are trust anchors are not validated since they begin a
>    certification path (see [RFC5280], Section 3.2).  A certificate that
>    begins a certification path MAY use a signature algorithm that is not
>    advertised as being supported in the "signature_algorithms"
>    extension.
> 
> In this case, I think one can argue are treating this as a trust
> anchor.  Feel free to propose new text that you think makes that
> clearer.

Proposal:

   Clients SHOULD/MUST NOT accept server certificates, or certificate
   validation paths, where the server certificate or intermediate
   certificates (but not trust anchors) are signed with "weak" signature
   algorithms, unless the client is not expecting TLS to strongly
   authenticate the server (e.g., for opportunistic use) or where the
   client has previously learned and cached the server's certificate.

   A "weak" signature algorithm is any of , or any that isn't on
    and was introduced prior to publication date of this
   document.

The last is a way to eliminate any old hash.  List some of them in
, list all the allowable ones that we know about today in
, and the publication date will take care of any that should have
been on  but was not listed in it, while future-proofing .

Nico
-- 


From nobody Mon May 22 13:50:49 2017
Return-Path: 
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 29969128CDC for ; Mon, 22 May 2017 13:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Zq8kDp9WKkey for ; Mon, 22 May 2017 13:50:34 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C9A128B93 for ; Mon, 22 May 2017 13:50:29 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id l14so65793759ywk.1 for ; Mon, 22 May 2017 13:50:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Ay29x0NxdgQQeRckRX2egrDKaGUB5JskJWcGdvYLVQ=; b=GrODbQ2sNHNLMWD4cp0ZNmninIOWv2vKR1dyimo5X70raw+0vBTMj6iXluD6dyBY0s vTdNnjAG3tTzZVo123PSLbrZVvBAqsxGnZzWSao0UtKDKEhzLsmaijncsIPY2tF1p+uR +vG/ST59qmtYpnQJt3s5exTcXmGzJYKMu615aNp0JR7RSXk/unfyCh0ntig4Wo/FN2xq zfGws9BKMxT21Tfe1oe8Il+EAeIph8Pdmh4x8/XSdxAHjqxbb5Ro1+E0vfAvzj9DN+n1 IjnYIzi8v/Go/R2L/pOMdWfRlQZ3yXlJit2y3nIt8LrsfjlMzD7LA3a4sIVoQFF2GsE0 bbLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Ay29x0NxdgQQeRckRX2egrDKaGUB5JskJWcGdvYLVQ=; b=nDtr7Aj/5lpzQreMIcX5UfktgDqa0hIQNQG2XBJnYWiwYbedLoSF4wkEcDzRw6Wku1 OmektapVR0V1/vCwnDLLm3gE5zX+xuPLj3LpGKhyZ5AAli47ZH3pUflo3IBUaoEw7dGF 3pcwq6oU589YigU6Gnlwzh1sORIKcnAvJYmoG6Wza2e3uRYIn7WFOhltqhR9vWDP8i6D 92c0a6t1xafVAbFN3T7NY7lhpxYwrze5FjR4InRja1H64hNgkJ9UPKPc9yyiRxYOMKDx ZrLwiHikcND1uLAHTXUVN66YUMIUDN/OKxRdmxAQNiyiw499tm+qn9ON2iXMyPzhg46V Ep7w==
X-Gm-Message-State: AODbwcCBjRPRf32294SCHvI1D8m/8c9fBE9QMNED2Fh36gZfXk71Vjpb TQLzjrBDXx4h2eEHCxpwlrSlFMoUXxnLKb4=
X-Received: by 10.129.57.138 with SMTP id g132mr19786351ywa.312.1495486228773;  Mon, 22 May 2017 13:50:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Mon, 22 May 2017 13:49:47 -0700 (PDT)
In-Reply-To: <20170522204326.GP10188@localhost>
References: <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>  <20170522204326.GP10188@localhost>
From: Eric Rescorla 
Date: Tue, 23 May 2017 05:49:47 +0900
Message-ID: 
To: Nico Williams 
Cc: TLS WG 
Content-Type: multipart/alternative; boundary="001a114c76b46ed9a3055023057f"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:50:47 -0000

--001a114c76b46ed9a3055023057f
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 5:43 AM, Nico Williams 
wrote:

> On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> > On Tue, May 23, 2017 at 5:17 AM, Nico Williams 
> > wrote:
> > > > In any case, I think there are two issues:
> > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > > > 2. Require a specific failure if the peer presents such a
> certificate.
> > > >
> > > > There was pretty strong consensus to do #1 and I don't support
> removing
> > > > it. That seems like a pretty modest layering violation. If people
> think
> > > that
> > > > the mandate for this specific alert is too onerous, I could live with
> > > > removing
> > > > that.
> > >
> > > I don't understand how you can have (1) and not (2).
> >
> > As Ilari suggests, you could just treat the algorithms as unknown.
>
> How does that square with (1)?
>

I don't understand the question. If you treat them as unknown then either
your path construction code will route around them or once you try to
verify,
it will fail.



> > Instead of altogether forbidding certs with MD5 signatures, forbid them
> > > when the application expects TLS to authenticate the server [with PKIX,
> > > as opposed to certain DANE usage values, or with pre-shared certs,
> > > etc.].  I.e., a server authentication security level knob is needed.
> >
> > I don't think that the current text prohibits that, because of :
>
> That takes care of DANE and pre-shared cert uses, but not of
> opportunistic use.  And maybe not of TOFU either: since on first use the
> server's cert won't be known to the client, it's not a "trust anchor"
> yet and cannot fall under this safe-harbor.
>

I wouldn't have any trouble interpreting it that way.


>    The signatures on certificates that are self-signed or certificates
> >    that are trust anchors are not validated since they begin a
> >    certification path (see [RFC5280], Section 3.2).  A certificate that
> >    begins a certification path MAY use a signature algorithm that is not
> >    advertised as being supported in the "signature_algorithms"
> >    extension.
> >
> > In this case, I think one can argue are treating this as a trust
> > anchor.  Feel free to propose new text that you think makes that
> > clearer.
>
> Proposal:
>
>    Clients SHOULD/MUST NOT accept server certificates, or certificate
>    validation paths, where the server certificate or intermediate
>    certificates (but not trust anchors) are signed with "weak" signature
>    algorithms, unless the client is not expecting TLS to strongly
>    authenticate the server (e.g., for opportunistic use) or where the
>    client has previously learned and cached the server's certificate.
>

I don't think "strongly authenticate" is useful here. I think the
requirement
is that the RP must not accept these algorithms in any context which would
require validating signatures made using them.

-Ekr


   A "weak" signature algorithm is any of , or any that isn't on
>     and was introduced prior to publication date of this
>    document.
>
> The last is a way to eliminate any old hash.  List some of them in
> , list all the allowable ones that we know about today in
> , and the publication date will take care of any that should have
> been on  but was not listed in it, while future-proofing .
>
> Nico
> --
>

--001a114c76b46ed9a3055023057f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 23, 2017 at 5:43 AM, Nico Williams <nico@cryptonector.=
com> wrote:
On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:

> On Tue, May 23, 2017 at 5:17 AM, Nico Williams <nico@cryptonector.com>

> wrote:

> > > In any case, I think there are two i=
ssues:

> > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA=
-1.

> > > 2. Require a specific failure if the peer presents such a ce=
rtificate.

> > >

> > > There was pretty strong consensus to do #1 and I don't s=
upport removing

> > > it. That seems like a pretty modest layering violation. If p=
eople think

> > that

> > > the mandate for this specific alert is too onerous, I could =
live with

> > > removing

> > > that.

> >

> > I don't understand how you can have (1) and not (2).

>

> As Ilari suggests, you could just treat the algorithms as unknown.



How does that square with (1)?

I=
 don't understand the question. If you treat them as unknown then eithe=
r
your path construction code will route around them or once you =
try to verify,
it will fail.


<=
div>
> > Ins=
tead of altogether forbidding certs with MD5 signatures, forbid them

> > when the application expects TLS to authenticate the server [with=
 PKIX,

> > as opposed to certain DANE usage values, or with pre-shared certs=
,

> > etc.].=C2=A0 I.e., a server authentication security level knob is=
 needed.

>

> I don't think that the current text prohibits that, because of :


That takes care of DANE and pre-shared cert uses, but not of

opportunistic use.=C2=A0 And maybe not of TOFU either: since on first use t=
he

server's cert won't be known to the client, it's not a "tr=
ust anchor"

yet and cannot fall under this safe-harbor.
=C2=A0
I wouldn't have any trouble interpreting it that way.
=



>=C2=A0 =C2=A0 The signatures on certificates that are self-signed or ce=
rtificates

>=C2=A0 =C2=A0 that are trust anchors are not validated since they begin=
 a

>=C2=A0 =C2=A0 certification path (see [RFC5280], Section 3.2).=C2=A0 A =
certificate that

>=C2=A0 =C2=A0 begins a certification path MAY use a signature algorithm=
 that is not

>=C2=A0 =C2=A0 advertised as being supported in the "signature_algo=
rithms"

>=C2=A0 =C2=A0 extension.

>

> In this case, I think one can argue are treating this as a trust

> anchor.=C2=A0 Feel free to propose new text that you think makes that<=
br>
> clearer.



Proposal:



=C2=A0 =C2=A0Clients SHOULD/MUST NOT accept server certificates, or certifi=
cate

=C2=A0 =C2=A0validation paths, where the server certificate or intermediate=


=C2=A0 =C2=A0certificates (but not trust anchors) are signed with "wea=
k" signature

=C2=A0 =C2=A0algorithms, unless the client is not expecting TLS to strongly=


=C2=A0 =C2=A0authenticate the server (e.g., for opportunistic use) or where=
 the

=C2=A0 =C2=A0client has previously learned and cached the server's cert=
ificate.

I don't think "strong=
ly authenticate" is useful here. I think the requirement
is =
that the RP must not accept these algorithms in any context which would
require validating signatures made using them.

<=
div>-Ekr



=C2=A0 =C2=A0A "weak" signature algorithm is any of <list1>=
, or any that isn't on

=C2=A0 =C2=A0<list2> and was introduced prior to publication date of =
this

=C2=A0 =C2=A0document.



The last is a way to eliminate any old hash.=C2=A0 List some of them in

<list1>, list all the allowable ones that we know about today in

<list2>, and the publication date will take care of any that should h=
ave

been on <list1> but was not listed in it, while future-proofing <l=
ist2>.



Nico

--





--001a114c76b46ed9a3055023057f--


From nobody Mon May 22 14:00:26 2017
Return-Path: 
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 192CB126C25 for ; Mon, 22 May 2017 14:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 9AqTuhnJ-Eyd for ; Mon, 22 May 2017 14:00:24 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB76126B72 for ; Mon, 22 May 2017 14:00:24 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 38F4320051C24; Mon, 22 May 2017 14:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=g28niWHQ38xE5Y 7fwjfsHEOtH0A=; b=LT5doJDTl+gWwNImumdi0QfzkBlyg6pDcSakd4DCHv8Wst GoKxN1buGRUNoyHdGWpfbrOdOZJAbqKb30rNauWuniCd1CC4gdX7CSbm5a/X85CI tVBvhm1XsmSZ/pF1f29MkYBPZdxz7cmK8tOgiNI+c0fYF02DZMVHsVgaZ2SIk=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id ED39A20051C23; Mon, 22 May 2017 14:00:23 -0700 (PDT)
Date: Mon, 22 May 2017 16:00:20 -0500
From: Nico Williams 
To: Eric Rescorla 
Cc: TLS WG 
Message-ID: <20170522210018.GQ10188@localhost>
References:  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>  <20170522204326.GP10188@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 21:00:26 -0000

On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> On Tue, May 23, 2017 at 5:43 AM, Nico Williams 
> wrote:
> > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams 
> > > wrote:
> > > > > In any case, I think there are two issues:
> > > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > > > > 2. Require a specific failure if the peer presents such a
> > certificate.
> > > > >
> > > > > There was pretty strong consensus to do #1 and I don't support
> > removing
> > > > > it. That seems like a pretty modest layering violation. If people
> > think
> > > > that
> > > > > the mandate for this specific alert is too onerous, I could live with
> > > > > removing
> > > > > that.
> > > >
> > > > I don't understand how you can have (1) and not (2).
> > >
> > > As Ilari suggests, you could just treat the algorithms as unknown.
> >
> > How does that square with (1)?
> >
> 
> I don't understand the question. If you treat them as unknown then
> either your path construction code will route around them or once you
> try to verify, it will fail.

That *really* seems like a layer violation!

> > > I don't think that the current text prohibits that, because of :
> >
> > That takes care of DANE and pre-shared cert uses, but not of
> > opportunistic use.  And maybe not of TOFU either: since on first use the
> > server's cert won't be known to the client, it's not a "trust anchor"
> > yet and cannot fall under this safe-harbor.
> 
> I wouldn't have any trouble interpreting it that way.

Why not be clear?

> > >    The signatures on certificates that are self-signed or certificates
> > >    that are trust anchors are not validated since they begin a
> > >    certification path (see [RFC5280], Section 3.2).  A certificate that
> > >    begins a certification path MAY use a signature algorithm that is not
> > >    advertised as being supported in the "signature_algorithms"
> > >    extension.
> > >
> > > In this case, I think one can argue are treating this as a trust
> > > anchor.  Feel free to propose new text that you think makes that
> > > clearer.
> >
> > Proposal:
> >
> >    Clients SHOULD/MUST NOT accept server certificates, or certificate
> >    validation paths, where the server certificate or intermediate
> >    certificates (but not trust anchors) are signed with "weak" signature
> >    algorithms, unless the client is not expecting TLS to strongly
> >    authenticate the server (e.g., for opportunistic use) or where the
> >    client has previously learned and cached the server's certificate.
> 
> I don't think "strongly authenticate" is useful here. I think the
> requirement is that the RP must not accept these algorithms in any
> context which would require validating signatures made using them.

Well, I want it to be crystal clear that the "not MD5 and such"
requirement need not apply to opportunistic TLS usage.  If you don't
like my text, maybe you can propose your own.

Nico
-- 


From nobody Mon May 22 14:02:23 2017
Return-Path: 
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 84E71128AB0 for ; Mon, 22 May 2017 14:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TYWti7hjl5jg for ; Mon, 22 May 2017 14:02:20 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B161273B1 for ; Mon, 22 May 2017 14:02:19 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2AC407A32F1 for ; Mon, 22 May 2017 21:02:19 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Mon, 22 May 2017 17:02:20 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <44D307FD-DBF7-4979-B4E0-76104F64D159@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org> 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 21:02:21 -0000

> On May 22, 2017, at 3:42 PM, Eric Rescorla  wrote:
>=20
> Well, I certainly think past the Web PKI, because one of the cases I =
care about
> is WebRTC, which doesn't do any PKI validation at all.
>=20
> In any case, I think there are two issues:
> 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> 2. Require a specific failure if the peer presents such a certificate.
>=20
> There was pretty strong consensus to do #1 and I don't support =
removing
> it.

The operative word here is *was*.  Time has passed, and things have =
changed:

	1.  The motivating problem (broad use of weak hashes in Web PKI
            certificates) has become a non-problem.  The CAs and the =
browsers
 	    have moved on.

	2.  We've since had many discussions that make it clearer still =
that
	    layer violation into RFC5280 space is suboptimal.

	3.  While did not object strongly at the time, I've since seen =
that the
 	    language in question temps TLS stack authors to implement =
checks against
	    the specific certificate algorithms at the TLS layer, =
instead of at the
	    X509 verification layer where X509 security checks belong.

Surely there are some old GOST signature algorithms that could appear in =
certificates,
that TLS 1.3 does not prohibit, but which are not much stronger than =
SHA-1, and if not
GOST then something else.  Plucking out the specific code-points in =
question is both
insufficient and counter-productive.

It is time to revisit the previous consensus, because its motivation is =
no longer
relevant, and its negative consequences are more apparent.

--=20
	Viktor.


From nobody Mon May 22 14:21:04 2017
Return-Path: 
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 7A66D127B60 for ; Mon, 22 May 2017 14:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 YXl_QiFKfzPN for ; Mon, 22 May 2017 14:21:00 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8C0126B72 for ; Mon, 22 May 2017 14:21:00 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id 130so15439520ybl.3 for ; Mon, 22 May 2017 14:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=diOVm3+OcjiDuvjFZbpXwCSNZA12U4BpIawCec9fqTs=; b=f3eThYLYHOuEDE1eYhxVq4seXQZzcrPSaemXq9al1FdXNsU9Ydqin5s57+2C3V9i5E osdC3ip6IFsBzjBLrojo3NUPkygAWLS76/ZNHbUpKlGy9nG38cCWKg2GxiPpZcALod+y Lc5g2Tokuz4Ppd3yWp5AAsLIHzGkAlRNCzrZ683F8K77RXRQvqjHWGjpmqqDLSCLATpM Y+FfJdDiJjhnB/eAJdurZnPUPeKa3bqWWMFldEfYN0DXaPwRFzTOX65lC9a1XwnGC6r3 +6b6o2mTxz/2XOyMUnamgfw+9e4NfNyXJwGQxQHYa34EQB/kuH6kvYP4ksML72yG0kNu n5Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=diOVm3+OcjiDuvjFZbpXwCSNZA12U4BpIawCec9fqTs=; b=Hui5V8KRsj1qN9uJjsOwk6vpgnQTg7OoXoY9MwP6N4yB2dxvAy3fEVMiieFx75XnhE WXwMJcMYP4Q4dfS6kUTjYmnn4HRbPpNFswbzf3chX6VoJEwIUrIjdF/IoE/DyKmyjKlf LbOp59KXGZ6ZttsTtDnIkLQjfLsg+yZ20646kXb2Y3ubiziHXU/8v3T+DXt3PQo5am0D DCrHipUbWuyX4IXVttWRNDVx8jL312HT9lsgKGQkgN/0QGyMWFtNW0E/xCMVXWO9oCxt /CLaoRMxi4fjKlV0gfbosXVYSCiqvgiiZ9R/XLNjL/gjFLjc05216gzpRgHTqLVWbG8i /W+A==
X-Gm-Message-State: AODbwcAx93A4KKRb/PPELTDYEO6ByKomgCQSMVC626Y6PqPswN/upiU5 l44YEjuGMhxmofdkM7Tovseg3Xonha7h7CQ=
X-Received: by 10.37.1.4 with SMTP id 4mr17525854ybb.24.1495488059345; Mon, 22 May 2017 14:20:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Mon, 22 May 2017 14:20:18 -0700 (PDT)
In-Reply-To: <44D307FD-DBF7-4979-B4E0-76104F64D159@dukhovni.org>
References:  <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org>  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <44D307FD-DBF7-4979-B4E0-76104F64D159@dukhovni.org>
From: Eric Rescorla 
Date: Tue, 23 May 2017 06:20:18 +0900
Message-ID: 
To: TLS WG 
Content-Type: multipart/alternative; boundary="001a113cf5228b297e05502372a5"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 21:21:02 -0000

--001a113cf5228b297e05502372a5
Content-Type: text/plain; charset="UTF-8"

This document has WGLC and so has a presumption of consensus. If you want
to re-raise that, this is a process question which is the province of the
chairs, so if you feel strongly, as it appears you do, I would encourage
you raise it with them.

-Ekr


On Tue, May 23, 2017 at 6:02 AM, Viktor Dukhovni 
wrote:

>
> > On May 22, 2017, at 3:42 PM, Eric Rescorla  wrote:
> >
> > Well, I certainly think past the Web PKI, because one of the cases I
> care about
> > is WebRTC, which doesn't do any PKI validation at all.
> >
> > In any case, I think there are two issues:
> > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > 2. Require a specific failure if the peer presents such a certificate.
> >
> > There was pretty strong consensus to do #1 and I don't support removing
> > it.
>
> The operative word here is *was*.  Time has passed, and things have
> changed:
>
>         1.  The motivating problem (broad use of weak hashes in Web PKI
>             certificates) has become a non-problem.  The CAs and the
> browsers
>             have moved on.
>
>         2.  We've since had many discussions that make it clearer still
> that
>             layer violation into RFC5280 space is suboptimal.
>
>         3.  While did not object strongly at the time, I've since seen
> that the
>             language in question temps TLS stack authors to implement
> checks against
>             the specific certificate algorithms at the TLS layer, instead
> of at the
>             X509 verification layer where X509 security checks belong.
>
> Surely there are some old GOST signature algorithms that could appear in
> certificates,
> that TLS 1.3 does not prohibit, but which are not much stronger than
> SHA-1, and if not
> GOST then something else.  Plucking out the specific code-points in
> question is both
> insufficient and counter-productive.
>
> It is time to revisit the previous consensus, because its motivation is no
> longer
> relevant, and its negative consequences are more apparent.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113cf5228b297e05502372a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This document has WGLC and so has a presumption of co=
nsensus. If you want to re-raise that, this is a process question which is =
the province of the chairs, so if you feel strongly, as it appears you do, =
I would encourage you raise it with them.

-Ekr


On Tue, May 23, 2017 at 6=
:02 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:=



> On May 22, 2017, at 3:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>

> Well, I certainly think past the Web PKI, because one of the cases I c=
are about

> is WebRTC, which doesn't do any PKI validation at all.

>

> In any case, I think there are two issues:

> 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.

> 2. Require a specific failure if the peer presents such a certificate.=


>

> There was pretty strong consensus to do #1 and I don't support rem=
oving

> it.



The operative word here is *was*.=C2=A0 Time has passed, and things =
have changed:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 1.=C2=A0 The motivating problem (broad use of w=
eak hashes in Web PKI

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certificates) has become a non-pr=
oblem.=C2=A0 The CAs and the browsers

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have moved on.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 2.=C2=A0 We've since had many discussions t=
hat make it clearer still that

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 layer violation into RFC5280 spac=
e is suboptimal.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.=C2=A0 While did not object strongly at the t=
ime, I've since seen that the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 language in question temps TLS st=
ack authors to implement checks against

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the specific certificate algorith=
ms at the TLS layer, instead of at the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X509 verification layer where X50=
9 security checks belong.



Surely there are some old GOST signature algorithms that could appear in ce=
rtificates,

that TLS 1.3 does not prohibit, but which are not much stronger than SHA-1,=
 and if not

GOST then something else.=C2=A0 Plucking out the specific code-points in qu=
estion is both

insufficient and counter-productive.



It is time to revisit the previous consensus, because its motivation is no =
longer

relevant, and its negative consequences are more apparent.




--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113cf5228b297e05502372a5--


From nobody Mon May 22 14:23:17 2017
Return-Path: 
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 AF1631292AE for ; Mon, 22 May 2017 14:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 w0IumlmNvqwk for ; Mon, 22 May 2017 14:23:12 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E26128DF2 for ; Mon, 22 May 2017 14:23:11 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id p143so33604669yba.2 for ; Mon, 22 May 2017 14:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Bk9Z9ZJhDQqWpuJiQ5Yw7YVK88+qCci51+mOE7h67M=; b=oUAjLza6kzjGB1PjlkkIVLlB/b2+Um3Wd/AbmEZdbI8JeTgvOvFns09Unzzp2NG371 sz4cd5jcNAuG+XyNoA5mghC4Uw52psn0wpNEIKghB7j9CCxBHJzbaDsUt4crkBnznCM/ JBEzWyDeHSUQaTOl9a0zsMbVrQivSFTevYxG+/acnJwIYMpmc3Mqs7NqeS8uWRpEK+ar roTc4de7e9zaoWZMpi3snRYqqwIi2fyDgfcNHYgp4TRPB/Mp6lqC+rTIlNi/8eUEvquV NE+9VCcZzXnl0MOYQDl/pJr2suCONSrx4vYSasdOG5BSFaX7i2CQBhKFTV6cWVlPYqol m0fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Bk9Z9ZJhDQqWpuJiQ5Yw7YVK88+qCci51+mOE7h67M=; b=YP/QejQIll+h4qjrUr0QscRnRaKuenGnhMD0HMF0pZx6Dt5HbMHewgCemCvRgfcNO1 teT/Uapy/wvX9FHS4EQblV8SeqJn3VgDqpOCvgEonP4MAwZoH6TaZ5whpUGqIpwUwruT Jym3ek7jSH8+5yXBxQye08nBXx47oHKcSm3LuYLyAdDxNOV1C4JySa/bvl4DA0Wlsq/7 66saW0kOnHd+vNNRrO5aT3jwq7npkfJGKWsOVb06irEHwXACMORCykTPG26Jp5aQbzkw G8XPxTP/sW3btP6svg0XtEzimSaqzMHA5X8ap+fBrgh22DHsvSOmm7x5yqC//+22EQ0F YY/w==
X-Gm-Message-State: AODbwcAto/aqcHb61Rwm3rxXaUC9aVANDSpeR9QmkTXuOG7K1RfrZoqJ PGxftMpLqYycqPwWEQjxH73XG0l4WmzD
X-Received: by 10.37.206.8 with SMTP id x8mr15443493ybe.16.1495488191192; Mon, 22 May 2017 14:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Mon, 22 May 2017 14:22:30 -0700 (PDT)
In-Reply-To: <20170522210018.GQ10188@localhost>
References:  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>  <20170522204326.GP10188@localhost>  <20170522210018.GQ10188@localhost>
From: Eric Rescorla 
Date: Tue, 23 May 2017 06:22:30 +0900
Message-ID: 
To: Nico Williams 
Cc: TLS WG 
Content-Type: multipart/alternative; boundary="94eb2c190b20672ca00550237ae0"
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 21:23:14 -0000

--94eb2c190b20672ca00550237ae0
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 6:00 AM, Nico Williams 
wrote:

> On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> > On Tue, May 23, 2017 at 5:43 AM, Nico Williams 
> > wrote:
> > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> > > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams <
> nico@cryptonector.com>
> > > > wrote:
> > > > > > In any case, I think there are two issues:
> > > > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > > > > > 2. Require a specific failure if the peer presents such a
> > > certificate.
> > > > > >
> > > > > > There was pretty strong consensus to do #1 and I don't support
> > > removing
> > > > > > it. That seems like a pretty modest layering violation. If people
> > > think
> > > > > that
> > > > > > the mandate for this specific alert is too onerous, I could live
> with
> > > > > > removing
> > > > > > that.
> > > > >
> > > > > I don't understand how you can have (1) and not (2).
> > > >
> > > > As Ilari suggests, you could just treat the algorithms as unknown.
> > >
> > > How does that square with (1)?
> > >
> >
> > I don't understand the question. If you treat them as unknown then
> > either your path construction code will route around them or once you
> > try to verify, it will fail.
>
> That *really* seems like a layer violation!
>

As I said, I don't have a problem with it. It's TLS giving instructions to
the PKI subsystem.


> >    Clients SHOULD/MUST NOT accept server certificates, or certificate
> > >    validation paths, where the server certificate or intermediate
> > >    certificates (but not trust anchors) are signed with "weak"
> signature
> > >    algorithms, unless the client is not expecting TLS to strongly
> > >    authenticate the server (e.g., for opportunistic use) or where the
> > >    client has previously learned and cached the server's certificate.
> >
> > I don't think "strongly authenticate" is useful here. I think the
> > requirement is that the RP must not accept these algorithms in any
> > context which would require validating signatures made using them.
>
> Well, I want it to be crystal clear that the "not MD5 and such"
> requirement need not apply to opportunistic TLS usage.


I don't think "opportunistic" is a clearly enough defined category to be
useful
here. Rather, I think the relevant criterion is the one I listed above. If
people
agree, I'd be happy to make that change (and can produce text) because I
think it conforms to the WG consensus.

-Ekr

--94eb2c190b20672ca00550237ae0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 23, 2017 at 6:00 AM, Nico Williams <nico@cryptonector.=
com> wrote:
On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:

> On Tue, May 23, 2017 at 5:43 AM, Nico Williams <nico@cryptonector.com>

> wrote:

> > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams <nico@cryptonector.com>

> > > wrote:

> > > > > In any case, I think there are two issues:

> > > > > 1. Forbid TLS 1.3 implementations from accepting M=
D5 and SHA-1.

> > > > > 2. Require a specific failure if the peer presents=
 such a

> > certificate.

> > > > >

> > > > > There was pretty strong consensus to do #1 and I d=
on't support

> > removing

> > > > > it. That seems like a pretty modest layering viola=
tion. If people

> > think

> > > > that

> > > > > the mandate for this specific alert is too onerous=
, I could live with

> > > > > removing

> > > > > that.

> > > >

> > > > I don't understand how you can have (1) and not (2)=
.

> > >

> > > As Ilari suggests, you could just treat the algorithms as un=
known.

> >

> > How does that square with (1)?

> >

>

> I don't understand the question. If you treat them as unknown then=


> either your path construction code will route around them or once you<=
br>
> try to verify, it will fail.



That *really* seems like a layer violation!
As I said, I don't have a problem with it. It's TLS giv=
ing instructions to the PKI subsystem.


<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
> >=C2=A0 =C2=A0 Clients SHOULD/MUST NOT accept server certificates, =
or certificate

> >=C2=A0 =C2=A0 validation paths, where the server certificate or in=
termediate

> >=C2=A0 =C2=A0 certificates (but not trust anchors) are signed with=
 "weak" signature

> >=C2=A0 =C2=A0 algorithms, unless the client is not expecting TLS t=
o strongly

> >=C2=A0 =C2=A0 authenticate the server (e.g., for opportunistic use=
) or where the

> >=C2=A0 =C2=A0 client has previously learned and cached the server&=
#39;s certificate.

>

> I don't think "strongly authenticate" is useful here. I =
think the

> requirement is that the RP must not accept these algorithms in any

> context which would require validating signatures made using them.



Well, I want it to be crystal clear that the "not MD5 and such&=
quot;

requirement need not apply to opportunistic TLS usage.
I don't think "opportunistic" is a clearly enough=
 defined category to be useful
here. Rather, I think the relevant=
 criterion is the one I listed above. If people
agree, I'd be=
 happy to make that change (and can produce text) because I
think=
 it conforms to the WG consensus.

-Ekr
<=
br>




--94eb2c190b20672ca00550237ae0--


From nobody Mon May 22 14:32:00 2017
Return-Path: 
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 1144B1292FD for ; Mon, 22 May 2017 14:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dXfK2iY5SpNg for ; Mon, 22 May 2017 14:31:57 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830F6128D3E for ; Mon, 22 May 2017 14:31:57 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9103B7A32F1 for ; Mon, 22 May 2017 21:31:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Mon, 22 May 2017 17:31:55 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: 
References:  <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>  <20170522204326.GP10188@localhost>  <20170522210018.GQ10188@localhost> 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 21:31:59 -0000

> On May 22, 2017, at 5:22 PM, Eric Rescorla  wrote:
>=20
> I don't think "opportunistic" is a clearly enough defined category to =
be useful
> here.

If you mean:

> I don't think "strongly authenticate" is useful here. I think the
> requirement is that the RP must not accept these algorithms in any
> context which would require validating signatures made using them.

That's fine.

> Rather, I think the relevant criterion is the one I listed above. If =
people
> agree, I'd be happy to make that change (and can produce text) because =
I
> think it conforms to the WG consensus.

The above formulation (where the relying party does not accept certain
signature algorithms as valid in the context of validating issuer
signatures) works for me.  All I'm looking for is not requiring the
RP to abort the handshake as soon as the algorithm is encountered,
even when the signature would never be checked!

So if putting the consensus to ban MD5/SHA-1 in its *proper context*
is consistent with the WG consensus, let's do that.

--=20
	Viktor.


From nobody Mon May 22 15:09:36 2017
Return-Path: 
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 0E2C11286CA for ; Mon, 22 May 2017 15:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level: 
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 B_Ri4X42MnVy for ; Mon, 22 May 2017 15:09:33 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [217.160.92.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B051272E1 for ; Mon, 22 May 2017 15:09:33 -0700 (PDT)
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id B078551F for ; Mon, 22 May 2017 23:09:31 +0100 (BST)
Received: by mail-it0-f47.google.com with SMTP id g126so7208293ith.0 for ; Mon, 22 May 2017 15:09:31 -0700 (PDT)
X-Gm-Message-State: AODbwcD1DbtrK03r31RSkLLGq1CsC40sBakNzmbeSm/4mxyh3F9gVTOC 8eI8jRj9hX+oipQvYpPPgdV0rfL1vg==
X-Received: by 10.36.0.23 with SMTP id 23mr24359773ita.108.1495490970251; Mon, 22 May 2017 15:09:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.127.79 with HTTP; Mon, 22 May 2017 15:09:29 -0700 (PDT)
In-Reply-To: <1CA8423D-0247-42E1-9D49-1BE76C348970@symantec.com>
References: <1CA8423D-0247-42E1-9D49-1BE76C348970@symantec.com>
From: Matt Caswell 
Date: Mon, 22 May 2017 23:09:29 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Roelof Du Toit 
Cc: TLS WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] Which version to use in ClientKeyExchange when using supported_versions extension
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 22:09:35 -0000

On 22 May 2017 at 21:18, Roelof Du Toit  wrote:
> RFC 5246 has the following in section 7.4.7.1 (RSA-Encrypted Premaster
> Secret):
>
>
>
>     client_version
>
>          The latest (newest) version supported by the client.  This is
>
>          used to detect version rollback attacks.
>
>
>
> The TLS 1.3 draft specification has the following in section 1.4 (Updates
> Affecting TLS 1.2)
>
>
>
>     The =E2=80=9Csupported_versions=E2=80=9D ClientHello extension can be=
 used to negotiate
> the version of TLS to use, in preference to the legacy_version field of t=
he
> ClientHello.
>
>
>
>
>
> I would appreciate some clarification regarding the value of
> "client_version" in a ClientKeyExchange if:
>
> - ClientHello.legacy_version =3D TLS 1.2, and
>
> - ClientHello.supported_versions extension has TLS 1.3, and
>
> - TLS 1.2 is negotiated (either because the server does not support TLS 1=
.3,
> or because the TLS 1.3-capable server is configured to respond with TLS 1=
.2
> for some reason)
>
>
>
> My assumption is that ClientHello.legacy_version should be used because t=
he
> client would not know whether the server ignored the supported_versions
> extension - is that correct?

That is the interpretation that OpenSSL takes - and I believe that is
true for other implementations as well.

Matt


From nobody Mon May 22 16:30:49 2017
Return-Path: 
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 6A53312943C for ; Mon, 22 May 2017 16:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 aI76ThZPArRH for ; Mon, 22 May 2017 16:30:46 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA621293F9 for ; Mon, 22 May 2017 16:30:46 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 1449F20051C23; Mon, 22 May 2017 16:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zBvr/t0858GRlC d67NE7xwj0IFU=; b=KaXsBRE7gu5bHeuJ72UsihJYG0eofjjgVfGL505T9Dz1jm x3TPwojFL8446Xxsm050WwNjTmXlps1sVZkMomvoZ6VUSbmuAzi3GeIGfE6DAchS 7IT2vT6MKHHyx0RGq1uxb7x3AH71VKHzz3/VJE7rTiLrYfotLrbdHtKhM2d1c=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id C063F20051C25; Mon, 22 May 2017 16:30:45 -0700 (PDT)
Date: Mon, 22 May 2017 18:30:41 -0500
From: Nico Williams 
To: Eric Rescorla 
Cc: TLS WG 
Message-ID: <20170522233040.GR10188@localhost>
References: <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>  <20170522204326.GP10188@localhost>  <20170522210018.GQ10188@localhost> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 23:30:48 -0000

On Tue, May 23, 2017 at 06:22:30AM +0900, Eric Rescorla wrote:
> On Tue, May 23, 2017 at 6:00 AM, Nico Williams 
> wrote:
> > > I don't understand the question. If you treat them as unknown then
> > > either your path construction code will route around them or once you
> > > try to verify, it will fail.
> >
> > That *really* seems like a layer violation!
> 
> As I said, I don't have a problem with it. It's TLS giving instructions to
> the PKI subsystem.

It implies more APIs.

> > Well, I want it to be crystal clear that the "not MD5 and such"
> > requirement need not apply to opportunistic TLS usage.
> 
> I don't think "opportunistic" is a clearly enough defined category to be
> useful here. Rather, I think the relevant criterion is the one I
> listed above. If people agree, I'd be happy to make that change (and
> can produce text) because I think it conforms to the WG consensus.

Opportunistic == "If the server got authenticated great, if not, that's fine too"

If the server was not authenticated, the app might use channel binding,
or learn the server's cert (TOFU), or just use the connection because
the only thing the application cares about is key agreement (defeat
eavesdropers, but not active attackers).  The last one is Viktor's use
case (SMTP).

Nico
-- 


From nobody Mon May 22 17:19:53 2017
Return-Path: 
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 B7B8E129477 for ; Mon, 22 May 2017 17:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 z9xdorOcACdh for ; Mon, 22 May 2017 17:19:50 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039C5128D3E for ; Mon, 22 May 2017 17:19:50 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id v27so115193344qtg.2 for ; Mon, 22 May 2017 17:19:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=1GLB6Vw5pPszfqun523TqXLqVVQ906g5xzrYu+JJuKM=; b=ea2wQjTOEhskreIZOA6hQ8LAW3yWFqZ8pW1a8e8o5wPCyat0+TOTZPF3OZubvmNpIt B7pFzvbiRBAu6YV5if4KuuH9275B2SpkSiZlyr2XFOywocvKrQTrm2ajht9mIDuh6JaO aBuvjEk73/BuFYtgrtSL7qI6yBV5wHwfhQuUKVF9X3xjuyqCzn6cY4Yn+uOqfLgziC+0 pjnOzhJCJUhTh/UpyfzdYTJ+j4wk85vLQoWZWv97unOy2SJk9GKVg5xJdPAonV4L9aUa fg1HFwj/v1b+sYJ3gEO87/ysISuS58Vl38Aj91JKzWmCz0P65Pvja4cyiPaGEFt4lk6B Iq+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=1GLB6Vw5pPszfqun523TqXLqVVQ906g5xzrYu+JJuKM=; b=UTzp1MM0KA5etZwtseoyh9qOcv+P1XjMMd2TaXCiaz676kgchy2NTGbd3OYXOoXXl/ LqpBRHrP3ASSV8AlDK49WA7BVeZmfcyfi6/82Cm/7jC7MVcp/DRF1PnfWdlM0b9Vy0bp 5+6IFKjDEV/xF+0BnW0s2BfjQQfppS55d+pXmnE82Z4fzWKiFbKmLM30iEAbNEdvnoWY cFHDulP88gWSkK3WUmLe46q9GWJ/E+x/L1DmXclzORp8mUNAbQzQGVTqYtyRkgjDBsKI rkUgdfyKwPVzikoOr6eH9+9hqjXjuoLfXUToOAb7M1UysBNPrcBd/IU802Wr/26lB2M7 D0Ow==
X-Gm-Message-State: AODbwcAreNw7l4fjvHXL1PTZ2dc5JeROp1FlDqiG2edfCE4B+tkjtLQR POmsTr1HRglnDMkP
X-Received: by 10.237.63.71 with SMTP id q7mr23079592qtf.49.1495498789061; Mon, 22 May 2017 17:19:49 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id q5sm12846346qtb.52.2017.05.22.17.19.47 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 22 May 2017 17:19:48 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Mon, 22 May 2017 20:19:46 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:   
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201705222019.46521.davemgarrett@gmail.com>
Archived-At: 
Subject: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 00:19:52 -0000

On Monday, May 22, 2017 05:31:55 pm Viktor Dukhovni wrote:
> So if putting the consensus to ban MD5/SHA-1 in its *proper context*
> is consistent with the WG consensus, let's do that.

Yes, please.

Citing discussion elsewhere in this thread (that probably should've all
been forked off with a different subject long before now...):

On Monday, May 22, 2017 05:00:20 pm Nico Williams wrote:
> On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> > On Tue, May 23, 2017 at 5:43 AM, Nico Williams 
> > wrote:
> > > Proposal:
> > >
> > >    Clients SHOULD/MUST NOT accept server certificates, or certificate
> > >    validation paths, where the server certificate or intermediate
> > >    certificates (but not trust anchors) are signed with "weak" signature
> > >    algorithms, unless the client is not expecting TLS to strongly
> > >    authenticate the server (e.g., for opportunistic use) or where the
> > >    client has previously learned and cached the server's certificate.
> > 
> > I don't think "strongly authenticate" is useful here. I think the
> > requirement is that the RP must not accept these algorithms in any
> > context which would require validating signatures made using them.
> 
> Well, I want it to be crystal clear that the "not MD5 and such"
> requirement need not apply to opportunistic TLS usage.  If you don't
> like my text, maybe you can propose your own.

My issue with this area is that we've got this fairly weird two tiered
problem where we're still pretending SHA-1 is vaguely acceptable in some
scenarios where certificates are being validated, and thus we need two
sets of language: one for weak hash MUST NOTs and another for weak hash
SHOULD NOT. The current text was written before SHA-1 was broken back in
February, so, while the topic of changing language we had consensus on is
up, I'd really like to make SHA-1 completely banned for standard certificate
authenticated TLS 1.3+ connections alongside MD5. To do this in a
non-messy way, we'd have to delete the SHA-1 special-casing and state
that TLS 1.3+ implementations can only use deprecated hashes
(MD5/SHA1/SHA224/etc) if explicitly doing opportunistic encryption or some
scenario where trust can be established without validating them. Again,
the trust anchor gets an exception here due to it being trusted directly
without need for validation, and they can get away with just a "NOT
RECOMMENDED". If we can agree to this, then the resulting text will end up
being far less problematic. If we can't get a consensus for this, I seriously
propose citing RFC 6919 s3.


Dave


From nobody Mon May 22 17:29:18 2017
Return-Path: 
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 4EAF4128D40 for ; Mon, 22 May 2017 17:29:16 -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] 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 JrOHvcZyJ6Xx for ; Mon, 22 May 2017 17:29:14 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20211279E5 for ; Mon, 22 May 2017 17:29:14 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 182C07A32F1 for ; Tue, 23 May 2017 00:29:14 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <201705222019.46521.davemgarrett@gmail.com>
Date: Mon, 22 May 2017 20:29:13 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: 
References:    <201705222019.46521.davemgarrett@gmail.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 00:29:16 -0000

> On May 22, 2017, at 8:19 PM, Dave Garrett  =
wrote:
>=20
> My issue with this area is that we've got this fairly weird two tiered
> problem where we're still pretending SHA-1 is vaguely acceptable in =
some
> scenarios where certificates are being validated, and thus we need two
> sets of language: one for weak hash MUST NOTs and another for weak =
hash
> SHOULD NOT. The current text was written before SHA-1 was broken back =
in
> February, so, while the topic of changing language we had consensus on =
is
> up, I'd really like to make SHA-1 completely banned for standard =
certificate
> authenticated TLS 1.3+ connections alongside MD5. To do this in a
> non-messy way, we'd have to delete the SHA-1 special-casing and state
> that TLS 1.3+ implementations can only use deprecated hashes
> (MD5/SHA1/SHA224/etc) if explicitly doing opportunistic encryption or =
some
> scenario where trust can be established without validating them.

Works for me.  In all the use-cases I care about the hash algorithm in
question is never actually used to validate any certificate signatures,
but the spec seems to require that the handshake be aborted anyway, just
because the codepoint is present in the chain.

I have no objections to banning *actual* use for making verification
decisions of all hash functions with collision resistance less than
say 120 bits (128 - modest fuzz for attacks that don't significantly
damage the algorithm).

What I am trying to avoid is having implementations just hang up
because the peer's certificate message contains "toxic" codepoints,
that will never actually get used, because verification is not
performed at all, or performed by means other than PKIX, or with
different intermediate certificates than presented.

Setting a collision-resistance floor rather than naming some list
of algorithms makes more sense to me, but if the WG really feels
that naming some "verbotten" algorithms is better, so be it.

--=20
	Viktor.


From nobody Mon May 22 17:57:37 2017
Return-Path: 
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 840D912948F for ; Mon, 22 May 2017 17:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UPTfFNimCR3o for ; Mon, 22 May 2017 17:57:34 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BF812949D for ; Mon, 22 May 2017 17:57:33 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id y201so119982940qka.0 for ; Mon, 22 May 2017 17:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=Hluhre5nP1UHEYKNnCzetya4XnM8qSBjhIl1gJlaHZ4=; b=bflIVFY9TnhpEqxteF795Uh4GuRJqsb6jNwMxwHTGPSB8yW59UtJiZsihc7RRUymzS wLeuFJakk/9Yu85+li7v/g4Vf5gc2XvJDOjtFMbCG7bAsr+iaXid05XC02+sJ+NkzVxE B5QT6HdvQMS0Y6+X6bNR36eelfUvkQn4j2mt34bsfCW/LB36r/SPjaJeDYQqBmyjlzN8 yilbPyXaB7sNqXUmcdUIR0keAOHEwRidXlSMJo/A3RS30BaX2maXJ5HBAAivqJhOuAu2 IrIl6hgNX6GE76O43DiUrAl1ASjXD6DUei6iPiWSSq9cSVkuXI6YyN3KfcBwNrIBXG6/ fRbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Hluhre5nP1UHEYKNnCzetya4XnM8qSBjhIl1gJlaHZ4=; b=qYfpXGA97SkoV/o6JzavouaaHdvA7uVJc1vN42ONQFegat0E204TWEr5dLUDsmRjG4 8plsSMum3MdJH1RPH9dvriEunkMH5XpRrhRAeNXlWg4+mLyhPd9XDaeOhPJb30k+WsSG iDxPhm9egVvLueCWpRU29bWT86ZbK8BPY+/rcNnW8g7fABmN0BiJK6pV/FHbS52mG4SR zfpKodfwGOgXtiOkFzZOGiVVapzPcklrZnBSIWKWtxXOVm54CWK++yd4naxI//mApG/O WYwTERhAZUyCp3gnM/lsIDYly55Wj9KhVIDn5kSuH6tIYzbLqHpHjfEWy6KDHU/78Vej rxBw==
X-Gm-Message-State: AODbwcC9Xc0zkZBG5LP6xw3X9OmtAYehozWoSfDtBpqeuj+fbtmy/hFm ZqVhOPgU3NxdrmG/
X-Received: by 10.233.235.12 with SMTP id b12mr23413640qkg.75.1495501052769; Mon, 22 May 2017 17:57:32 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id d200sm12932545qkg.50.2017.05.22.17.57.31 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 22 May 2017 17:57:32 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Mon, 22 May 2017 20:57:30 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:  <201705222019.46521.davemgarrett@gmail.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201705222057.30588.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 00:57:35 -0000

On Monday, May 22, 2017 08:29:13 pm Viktor Dukhovni wrote:
> Setting a collision-resistance floor rather than naming some list
> of algorithms makes more sense to me, but if the WG really feels
> that naming some "verbotten" algorithms is better, so be it.

My preference would be to do both. Call out the ones we have
codepoints for by name (MD5/SHA1/SHA224), then have a general
collision-resistance floor value for everything else.


Dave


From nobody Mon May 22 18:06:42 2017
Return-Path: 
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 0119C1294B7 for ; Mon, 22 May 2017 18:06:40 -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] 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 Zq00PxrTIRmH for ; Mon, 22 May 2017 18:06:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8711294A2 for ; Mon, 22 May 2017 18:06:38 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id ED8347A32F1 for ; Tue, 23 May 2017 01:06:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <201705222057.30588.davemgarrett@gmail.com>
Date: Mon, 22 May 2017 21:06:37 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG 
Message-Id: 
References:  <201705222019.46521.davemgarrett@gmail.com>  <201705222057.30588.davemgarrett@gmail.com>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 01:06:40 -0000

> On May 22, 2017, at 8:57 PM, Dave Garrett  wrote:
> 
> My preference would be to do both. Call out the ones we have
> codepoints for by name (MD5/SHA1/SHA224), then have a general
> collision-resistance floor value for everything else.

OK by me, with previous proviso on the appropriate context,
namely actual use by the relying party, not mere appearance
on the wire.  That is, effectively the RP behaves as though
the code points are unknown, but with "lazy evaluation"[1].

-- 
	Viktor.

[1] With "lazy evaluation" one is not forced to fail to parse
the certificate if parsing requires having known code points.
So long as no use of the underlying algorithm is made, the
intent of the prohibition is accomplished.


From nobody Mon May 22 19:12:08 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B12C3128656; Mon, 22 May 2017 19:11:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Joseph Salowey ,  tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 19:11:59 -0700
Archived-At: 
Subject: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 23 May 2017 02:12:00 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The following text appears to have been added in -04

   A server receiving a ClientHello and a client_version indicating
   (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
   this document in ClientHello.cipher_suites can safely assume that
the
   client supports TLS 1.2 and is willing to use it.  The server MUST
   NOT negotiate these cipher suites with TLS protocol versions earlier
   than TLS 1.2.  Not requiring clients to indicate their support for
   TLS 1.2 cipher suites exclusively through ClientHello.client_hello
   improves the interoperability in the installed base and use of TLS
   1.2 AEAD cipher suites without upsetting the installed base of
   version-intolerant TLS servers, results in more TLS handshakes
   succeeding and obviates fallback mechanisms.

This is a major technical change from -03, which, AFAIK, prohibited
the server from negotiating these algorithms with TLS 1.1 and below
and maintained the usual TLS version 1.2 negotiation rules.

This is a very material technical change. I don't consider it wise,
but in any case it would absolutely need WG consensus, which I
don't believe that it has given the recent introduction.

The discussion of dictionary attacks here seems inferior to that
in 4279. In particular, you only need to actively attack one
connection to capture the data you need for a brute force attack
despite the text there referring to trying "different keys".
Please correct that.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The citations to TLS 1.3 still seem pretty muddled. I think you
should just stop referencing and discussing 1.3.

S 2.
I'm not sure that the discussion of the PRF is helpful here in
mandating the non-use of these cipher suites with TLS 1.1 and
below.



From nobody Mon May 22 19:23:29 2017
Return-Path: 
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 E6842128D69 for ; Mon, 22 May 2017 19:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 afesRCeRsSdP for ; Mon, 22 May 2017 19:23:26 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17757128656 for ; Mon, 22 May 2017 19:23:26 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4N2MLD4018349; Tue, 23 May 2017 03:23:22 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=llL0gQeJZGw4hBBUSF/+DditjQzFiEQZxWavzm+VsK0=; b=WA8/b36UxZOjowyBLt4QG3kfUZUEpkSRtqUzHFWXxY3WUqKYCcvnyS+n3jxO/pZJevGu SpTvNfDn5iEJJLFGhowK+IIwhxinZD8blxm4CTiHQyJt/LBYNWBFMYQCpoBBcj0NCTY/ /nAVXkaQA9Wefp2bqlApcJKetDt72SLXjQ3hRiv1tZRFoPP++qFFTlrLfgwOg7e1kUCD 4RWtjckmJg7tqqhWBBeSeYA6HwZw7wR0ThXkS+eb/UChyUNYXmel7l9DeZrJ68rYtuwX xiioavW668+eGY3VPE86dI1kZQ7Ccyv0akuCqdxU4otPkcpLGMOkmrW3vprSfCDuT04H sg== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2am4wdhyqm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 03:23:22 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4N2Kt1n030450; Mon, 22 May 2017 22:23:21 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ajh4v4ddw-1; Mon, 22 May 2017 22:23:21 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 5E3BD20061; Mon, 22 May 2017 20:23:21 -0600 (MDT)
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
Cc: "tls@ietf.org" 
References:      <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>      
From: Benjamin Kaduk 
Message-ID: <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>
Date: Mon, 22 May 2017 21:23:19 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6BB8AF23F408F3DE3D957ED6"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230011
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230011
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 02:23:28 -0000

This is a multi-part message in MIME format.
--------------6BB8AF23F408F3DE3D957ED6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 05/22/2017 12:56 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:46 AM, Christian Huitema
> > wrote
>
>     Check DKG's analysis of 0-RTT for DNS over TLS:
>     https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html
>     .
>     There is only one point of concern, a minor privacy leak if the
>     DNS queries in the 0-RTT data can be replayed at intervals chosen
>     by the attacker. The idea is to replay the data to a resolver, and
>     then observe the queries going out to authoritative servers in
>     clear text. The correlation can be used to find out what domain
>     the client was attempting to resolve. The attack requires "chosen
>     time" by the attacker, and thus will probably be mitigated by a
>     caching system that prevents replays after a short interval.
>
>
>
> I have a reply to that too, linked at the bottom: there's actually a
> more trivial side-channel (due to non-idempotence) that hadn't been
> considered in the original analysis.
>

Sorry for being daft, but a direct link to this additional side-channel
would be helpful.

-Ben

--------------6BB8AF23F408F3DE3D957ED6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/22/2017 12:56 PM, Colm MacCárthaigh wrote:

    

      
      


        


          
On Mon, May 22, 2017 at 10:46 AM,
            Christian Huitema <huitema@huitema.net>
            wrote
            

              
 Check DKG's
                analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html.
                There is only one point of concern, a minor privacy leak
                if the DNS queries in the 0-RTT data can be replayed at
                intervals chosen by the attacker. The idea is to replay
                the data to a resolver, and then observe the queries
                going out to authoritative servers in clear text. The
                correlation can be used to find out what domain the
                client was attempting to resolve. The attack requires
                "chosen time" by the attacker, and thus will probably be
                mitigated by a caching system that prevents replays
                after a short interval.

            

            


            

            


            

            
I have a reply to that too, linked at the bottom:
              there's actually a more trivial side-channel (due to
              non-idempotence) that hadn't been considered in the
              original analysis.

            

          

        

      

    

    

    Sorry for being daft, but a direct link to this additional
    side-channel would be helpful.

    

    -Ben

  


--------------6BB8AF23F408F3DE3D957ED6--


From nobody Mon May 22 19:53:11 2017
Return-Path: 
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 685C9129503 for ; Mon, 22 May 2017 19:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 n1gGQ37fuX73 for ; Mon, 22 May 2017 19:53:07 -0700 (PDT)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DE51294DB for ; Mon, 22 May 2017 19:53:07 -0700 (PDT)
Received: by mail-yb0-x236.google.com with SMTP id 130so16720400ybl.3 for ; Mon, 22 May 2017 19:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AkiBu9GWOpjWPG5TTrqA8UwFaCR5JUnscCJ6XfIdU+g=; b=X/jpYK5tqgZFukACJw4Q8giZK0Qd1VIgU+dow4QBRwacCh33tmczKxILCLptpxH07/ MN5ucS63bVgOsItCyY9ytH7yugmC6NjXULLiU/frVo/j4iKYH0r+qdsriujh3fAy34Gc rRuQsV1BjMWp73/NrbZmeWOJPF9eRRoKB+dGt5itqLxYy/mKFUcY8IW+eVVrpkj2r2qd w11bPzPRs91YMG4qHqVVdq6hO3laSdgBHtyhF0EFUqXPsPEJuZSxmK0ziwsDEBs8pyL2 WltaZVIXqFCOBIJb1c843giHxZJl8myNrV/ebPfa+dpZcCDKydPISFWkS0GfyV3qKAMV scHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AkiBu9GWOpjWPG5TTrqA8UwFaCR5JUnscCJ6XfIdU+g=; b=p9+8f6A7c+rrALQ0WH5wg2OZCyoeRwTzBAPsBpngBNtPg+W41qKL80eoem2IuQPMtU E3U8fPmvMeQS7yeKDN1JI2E8oNn0fjRQB0ZqacsMHItAx8Jukc9BTUmgg9Km/6aX/BTg WlRtd9iV6NwucIgZCldo1B9kAzJN9NlGZ7NT94iYnu/+ZiF1pBFPkBve/bSeIC0ABiOY T7TLrLE/gZU8Ta52xD4idrL72YVvMkhsBFjrO8PLpdPVsmK3+SanXdHN1Xdvfgo9nfUy HNs8EpVWwSBhbZvRczBWSjpHHf92ZEqgrWzYHs6Y5zaesTJJKGfInC/uZrYegxv23kpU J3JQ==
X-Gm-Message-State: AODbwcCcwR2NrT3WL1TUjd7cXLeTNDVc+PGlJmKNsqTt9gcN/HNivFKc jsDQ+t1BDY4h7zALBOnvV88KzkEZ1Y1N0qk=
X-Received: by 10.37.170.97 with SMTP id s88mr14823219ybi.19.1495507987092; Mon, 22 May 2017 19:53:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Mon, 22 May 2017 19:53:06 -0700 (PDT)
In-Reply-To: <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>
References:      <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Mon, 22 May 2017 19:53:06 -0700
Message-ID: 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c19e39a547ce0055028163d"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 02:53:09 -0000

--94eb2c19e39a547ce0055028163d
Content-Type: text/plain; charset="UTF-8"

On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk  wrote:

>
> Sorry for being daft, but a direct link to this additional side-channel
> would be helpful.
>

I should have done it the first time.  Here it is:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html

-- 
Colm

--94eb2c19e39a547ce0055028163d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk <<=
a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com=
> wrote:

 =20
   =20
 =20
  


    Sorry for being daft, but a direct link to this additional
    side-channel would be helpful.

I should have done it the first time.=C2=A0 Here it is:=C2=A0htt=
ps://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html=C2=
=A0

-- 
Colm



--94eb2c19e39a547ce0055028163d--


From nobody Mon May 22 21:19:36 2017
Return-Path: 
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 BE1E6124BFA for ; Mon, 22 May 2017 21:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 QG5Ag8eSVjNO for ; Mon, 22 May 2017 21:19:32 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CC9127868 for ; Mon, 22 May 2017 21:19:32 -0700 (PDT)
Received: from [47.143.125.207] (helo=Williams-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1dD1IB-0004lf-2Z for tls@ietf.org; Tue, 23 May 2017 00:19:31 -0400
Date: Mon, 22 May 2017 21:19:30 -0700
From: Bill Frantz 
To: TLS WG 
X-Priority: 3
In-Reply-To: <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7984ef9363539b6c8596f3c22f5838e7de350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 47.143.125.207
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 04:19:35 -0000

On 5/22/17 at 10:46 AM, ietf-dane@dukhovni.org (Viktor Dukhovni) wrote:

>>On May 22, 2017, at 1:37 PM, Salz, Rich  wrote:
>>
>>I strongly believe the text should stay as it is, for the most good to th=
e most people.  Viktor is in the weeds, arguably by himself.
>
>Right, all by myself...  With support from Nico, Ilari, and others who've =
upthread
>accepted that certificate verification is properly RFC5280 and not TLS, be=
fore I
>suggested removal of the text in question (which solves no real problem, b=
ut does
>create needless interoperability issues for various TLS use-cases).

Please allow me to add my voice to Viktor's. When I wrote the E=20
language communication protocol, many people said I should use=20
SSL. Some of the reasons we did not use SSL are in a 1998=20
document .

Our protocol started with a hash of the peer's public key. With=20
that bit of information, other authentications are unnecessary.=20
If I were starting today, we could use TLS with PSKs by asking=20
the other side for it's key and then using it with a TLS library=20
(I think).

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to=20
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |


From nobody Tue May 23 02:29:44 2017
Return-Path: 
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 D19D6129A9A for ; Tue, 23 May 2017 02:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 gK13J1sN-6yZ for ; Tue, 23 May 2017 02:29:27 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id E5B51129A99 for ; Tue, 23 May 2017 02:29:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 559EA24074; Tue, 23 May 2017 12:29:24 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 1pWvHvL5QzHC; Tue, 23 May 2017 12:29:23 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E8E23C4; Tue, 23 May 2017 12:29:23 +0300 (EEST)
Date: Tue, 23 May 2017 12:29:22 +0300
From: Ilari Liusvaara 
To: Nico Williams 
Cc: Eric Rescorla , TLS WG 
Message-ID: <20170523092921.GA13966@LK-Perkele-V2.elisa-laajakaista.fi>
References: <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com>  <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org>  <20170522201729.GO10188@localhost>  <20170522204326.GP10188@localhost>  <20170522210018.GQ10188@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20170522210018.GQ10188@localhost>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 09:29:38 -0000

On Mon, May 22, 2017 at 04:00:20PM -0500, Nico Williams wrote:
> On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> > On Tue, May 23, 2017 at 5:43 AM, Nico Williams 
> > wrote:
> > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote:
> > > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams 
> > > > wrote:
> > > > > > In any case, I think there are two issues:
> > > > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> > > > > > 2. Require a specific failure if the peer presents such a
> > > certificate.
> > > > > >
> > > > > > There was pretty strong consensus to do #1 and I don't support
> > > removing
> > > > > > it. That seems like a pretty modest layering violation. If people
> > > think
> > > > > that
> > > > > > the mandate for this specific alert is too onerous, I could live with
> > > > > > removing
> > > > > > that.
> > > > >
> > > > > I don't understand how you can have (1) and not (2).
> > > >
> > > > As Ilari suggests, you could just treat the algorithms as unknown.
> > >
> > > How does that square with (1)?
> > >
> > 
> > I don't understand the question. If you treat them as unknown then
> > either your path construction code will route around them or once you
> > try to verify, it will fail.
> 
> That *really* seems like a layer violation!

The code I have tries to route around (with equivalent to exhaustive
search of all paths).

And altough the code I have has the TLS and certificate code more
tightly bound togethe than most libraries, the certificate validation
algorithm handling is wholly inside the certificate handling part.

The algorithm handling being inside certificate code is even true for
SHA-1 signatures, which have nontrivial validity rules (only allowed
for dedicated OCSP responders).

The certificate code does not concern itself about TLS version it
is running on. The exchange signature (which has differences between
TLS versions) is direct signature validation and does not involve
certificate code.


BTW:

Section 4.4.3. seemingly allows use of unadvertised exchange signature
schemes if advertised one can't be used. This should be fixed: There
is no way that can actually work (even pinning the server's key doesn't
make that work, unlike say EE certificate being signed with something
unknown).




-Ilari


From nobody Tue May 23 04:50:37 2017
Return-Path: 
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 1DC7C129AEB for ; Tue, 23 May 2017 04:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.802
X-Spam-Level: 
X-Spam-Status: No, score=-4.802 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=microsoft.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 n_-RZCEy8EMc for ; Tue, 23 May 2017 04:50:33 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00130.outbound.protection.outlook.com [40.107.0.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DB5129AFC for ; Tue, 23 May 2017 04:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M+xLu0wTzZAkx11IFitCltVZA6MMnqi845Iq8J+frao=; b=mVJkLHJ3r7Y+x+jMFsq3fDsl1U760VI9HR5RNRxR9DpLWGR14CCjjKG5Qa5MAWwcEyJPRUGdouNtjqwCgkJLfbaza2OIZwje2nW52WOfUEITtn9699mfgw/Q1VKIfAfhU0i7rVWfrk/JGbKaX1xZ0Yx0Mg9Eh69xYPCt8GuQYBw=
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com (129.75.139.20) by DB6PR8303MB0069.EURPRD83.prod.outlook.com (129.75.139.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.0; Tue, 23 May 2017 11:50:04 +0000
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com ([fe80::ac56:1e73:9b19:5ba6]) by DB6PR8303MB0069.EURPRD83.prod.outlook.com ([fe80::ac56:1e73:9b19:5ba6%18]) with mapi id 15.01.1143.000; Tue, 23 May 2017 11:50:01 +0000
From: Markulf Kohlweiss 
To: "tls@ietf.org" 
CC: Eric Rescorla , Britta Hale , Cedric Fournet , Antoine Delignat-Lavaud , Santiago Zanella-Beguelin , Samin Ishtiaq , "karthikeyan.bhargavan@inria.fr" 
Thread-Topic: [TLS] Comments on EndOfEarlyData
Thread-Index: AdLTtEU8p75Loa4ER0+xBa7xoDxY0Q==
Date: Tue, 23 May 2017 11:50:01 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [167.220.196.154]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR8303MB0069; 7:60Hix8B+siC5ouAc6G+ivNjbYjC4XqEzJ4tlJTbJkPY8E7YAvxBkyNlfRjc81fHYsRZvBdD9kNpEWuyCD3PzrcDmRUOkazIN1/5zxzPsWiJ2f8wSU9xy84/3jmxmD0lpeHG/kVlDnqTNc7po1WFBllbnNe0fg16RMkXznUh9qNPI6KDwBVZbPqX9jhdCAgCP+e2akBjaYW55FulS80ja19xj5C/IBrShPznNT15WrvrdOFBd2JYzUHxCq+XO5Xpa60JVqU9S70Uw+kUW3oL5zRF6pnN02Wgh3DQ5r+uEQoWI1Z2sK5L+9930jEUEEUrNQYUocZHYkU0e1S0q9qQYGfJ2DxSVV36L7AXhiBQDRsY=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(979002)(6029001)(6009001)(39850400002)(39840400002)(39860400002)(39450400003)(39400400002)(39410400002)(377454003)(24454002)(5640700003)(7736002)(6506006)(305945005)(6436002)(2351001)(6916009)(229853002)(86362001)(7696004)(2900100001)(86612001)(478600001)(2906002)(413944005)(3660700001)(10290500003)(25786009)(53546009)(3280700002)(33656002)(66066001)(189998001)(4326008)(2501003)(5250100002)(102836003)(6116002)(3846002)(6246003)(38730400002)(10090500001)(110136004)(5660300001)(54906002)(99286003)(55016002)(9686003)(54356999)(74316002)(50986999)(53936002)(5005710100001)(8676002)(1730700003)(81166006)(8936002)(8990500004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR8303MB0069; H:DB6PR8303MB0069.EURPRD83.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
x-ms-traffictypediagnostic: DB6PR8303MB0069:
x-ms-office365-filtering-correlation-id: 785a160f-05d2-466b-e9c7-08d4a1d1d887
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:DB6PR8303MB0069; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700043)(100105000095)(100000701043)(100105300095)(100000702043)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703043)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704043)(100105200095)(100000705043)(100105500095); SRVR:DB6PR8303MB0069; BCL:0; PCL:0; RULEID:(100000800043)(100110000095)(100000801043)(100110300095)(100000802043)(100110100095)(100000803043)(100110400095)(100000804043)(100110200095)(100000805039)(100110500095); SRVR:DB6PR8303MB0069; 
x-forefront-prvs: 0316567485
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 11:50:01.4105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR8303MB0069
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 11:50:35 -0000

Dear Eric, Britta,

I am paraphrasing a long thread on the issue that we had within
the miTLS development team, and I am primarily commenting on the
analysis aspects. I also hope that it will clarify any remaining
problems of understanding that I have on the issue.

If we see EOED as a stream termination signal, then there seems
to be a difference in performance for conservative servers that
want to wait until receiving all 0RTT data before responding to
the client's request in 0.5RTT communication.

Said otherwise, we want servers to be able to respond with application=20
data based on application data from the client and know that that=20
that data was not truncated.

=3D=3DScenario with EOED as Handshake message=3D=3D

After the Client sends 0RTT data the Server gets=20

CH, APP_C1, APP_C2

and typically responds with=20

SH, ... SFIN, APP_S1

But wait, the server doesn't actually know that early data is
terminated. A conservative server would instead send only

SH,... SFIN and wait of EOED

The Client receives SH,... SFIN

Only now the Client knows that the server accepts 0RTT and he can
send and hash the EOED into the transcript hash.

The server receives EOED, CFIN

Only now such a conservative Server can send APP_S1.=20

This results in an additional round trip for conservative
servers, and thus discourages the use of EOED as a stream
termination signal.  ---


=3D=3DScenario with EOED as Alert=3D=3D

With an Alert based design for EOED we can instead have the
following flow, where the client immediately sends the EOED after
his request without waiting for the SFIN. Here the client makes the=20
conscious choice not to send any additional early data.

The server gets=20

CH, APP_C1, APP_C2,=20
respond with SH,...SFIN

The server continues reading EOED and is notified about termination=20
of 0RTT traffic .

The server can now immediately sends  APP_S1, ....

It is important that the server would send SH regardless of
receiving EOED to avoid deadlock due to clients that wait until
receiving SFIN before sending EOED.  ---


Maybe the implicit assumption is that applications, e.g., HTTP/2
have to do their own termination of requests, and that EED serves
a different purpose? What would be the justification for
providing such a mechanism for 1RTT traffic but not for 0RTT
traffic. And why not enable different usage profiles?

Overall, I find the design based on Alert messages cleaner and
more consistent. From colleagues I heard folklore that it would
also ease verification and reduce the implementation complexity
for modular implementations that want to separate Record Layer
and Handshake Layer concerns.

This is related to verifying the handshake without relying on=20
encryption at all but I will let them comment on this if they deem=20
it necessary.

--markulf


> On 16. mai 2017 23:28, Eric Rescorla wrote:
>
>> On Tue, May 16, 2017 at 2:41 PM, Britta Hale  wrote=
:
>>
>> EOED signals the end of data encrypted with early traffic keys, yes,=20
>> and the next message is the Finished message encrypted with the=20
>> handshake traffic key.
>> However,
>> the Finished message is not *data*, and use of the application traffic=20
>> key is signaled by the Finished message, not EOED. The Finished=20
>> message, like a KeyUpdate message, are handshake messages, and both=20
>> signal the start of a new key use for application data.
>>
>> In comparison, EOED signals the end of key use for application data - wh=
ich
>> correlates
>> to alert behavior.
>
> This seems like a point where reasonable people can differ, especially as=
 ultimately the motivation for this change=20
> was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some=
 analytic difficulty, or do you just find it > > unaesthetic?
>
> -Ekr


From nobody Tue May 23 06:35:11 2017
Return-Path: 
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 B83DC129B41; Tue, 23 May 2017 06:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 Zy4jW_sCTfRX; Tue, 23 May 2017 06:35:06 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1E31200FC; Tue, 23 May 2017 06:34:43 -0700 (PDT)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wXGjG38WLz26c0; Tue, 23 May 2017 15:34:42 +0200 (CEST)
X-purgate-ID: 152705::1495546482-0000088C-41283E31/0/0
X-purgate-size: 1782
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3wXGjF2kvBz30TR; Tue, 23 May 2017 15:34:41 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 54A901A6A6; Tue, 23 May 2017 15:34:41 +0200 (CEST)
In-Reply-To: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>
To: Eric Rescorla 
Date: Tue, 23 May 2017 15:34:41 +0200 (CEST)
CC: The IESG , tls@ietf.org, tls-chairs@ietf.org,  draft-ietf-tls-ecdhe-psk-aead@ietf.org
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170523133441.54A901A6A6@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 13:35:09 -0000

Eric Rescorla wrote:
> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The following text appears to have been added in -04
> 
>    A server receiving a ClientHello and a client_version indicating
>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>    this document in ClientHello.cipher_suites can safely assume that
> the
>    client supports TLS 1.2 and is willing to use it.  The server MUST
>    NOT negotiate these cipher suites with TLS protocol versions earlier
>    than TLS 1.2.  Not requiring clients to indicate their support for
>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>    improves the interoperability in the installed base and use of TLS
>    1.2 AEAD cipher suites without upsetting the installed base of
>    version-intolerant TLS servers, results in more TLS handshakes
>    succeeding and obviates fallback mechanisms.
> 
> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.

This change _still_ prohibits the server from negotiating these algorithms
with TLSv1.1 and below.

Could you elaborate a little on where and why you see a problem with this?

As this changes tries to explain, had such a text been used for all
TLSv1.2 AEAD cipher suite code points, then browsers would have never
needed any "downgrade dance" fallbacks, POODLE would have never
existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
would not been needed, either.

-Martin


From nobody Tue May 23 07:02:20 2017
Return-Path: 
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 AE85D129B5C; Tue, 23 May 2017 07:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iVOsHT9zo80Z; Tue, 23 May 2017 07:02:16 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217E4129B51; Tue, 23 May 2017 07:02:16 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id m18so49601444lfj.0; Tue, 23 May 2017 07:02:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EY/Oa89lWWKQKK5tKTI1x2fCFQseLb7Wowx8rmAtCjU=; b=SJkhJQJiZWdBcne03sNxzDftMtxRx7PoDYpNzIRn9FMPD7JsVZmVTZcg4P7YtqiR2s MHJEcr8linpmrxfiUpUIE8DlMHiv7oE4HhjQscr2vqgLwtVIK+iErdWIkctLsvxy/W5g QZL5sL3UlmdrDrhJFdPE9DQH6aeEIXlB8Z+d0/fYwmoCt4WBSKMa2slTVV8aG4W1YEyc 6avcBn0X9ObobzJ9E+4uITeigfM2Zy0g+rLXifoCLrBMes2jtQNMKQ7BtKSzwURdQ/67 sT6Wj4t35o9FmZ859AioXhxyZ9oScen1lNC8in/EqVEHC9JU2W1QXPGOO2gGpj8aNH0B i+2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EY/Oa89lWWKQKK5tKTI1x2fCFQseLb7Wowx8rmAtCjU=; b=Qi1S2P9/VkYfp5oad+UBn3H3VXg9uuMy62ERGTaRAfy6FLB+p2YxriDjZ612vllK16 TlVEwQlAqNUClAjSmrS974yh3JM7q6YQNHe2ZwFkfSUKCmwy9O/wIiJ9C2+1AE0cYgsy ia33tHIY9ajUSBOYEJ52y2AHqbblchr72hi+xCjLwkVYfPNMS7ttu2+xhGGGkmhno77d eddLiomSYrRn7dkWjFCEsyQypLEElMgd40dfxE9QqaW+P9Lx/oeeGozurMXL8t0R1pVD ClgMwqNrdZCPMrOEIuLF4guRV+FILJ0OtSX+iXHfhoevcu3u4NXRQKKfgkK2Z/BnoDqi N0Wg==
X-Gm-Message-State: AODbwcB+ayUBRTDHKbujjxjxb8lcaL4S8DckICREApE94+qX/2bvEklO qZid3oLGvIWigLbvDsZqn4bF/dl+ug==
X-Received: by 10.25.193.145 with SMTP id r139mr7414547lff.111.1495548134375;  Tue, 23 May 2017 07:02:14 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 07:02:13 -0700 (PDT)
In-Reply-To: 
References: <149522417333.23956.7024977757521677892.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BDBB01@eusaamb107.ericsson.se> 
From: Daniel Migault 
Date: Tue, 23 May 2017 10:02:13 -0400
X-Google-Sender-Auth: Ze0zJf-h5K8R0bOIeEpnsEK93aY
Message-ID: 
To: Benjamin Kaduk 
Cc: "tls@ietf.org" , tls-chairs 
Content-Type: multipart/alternative; boundary="94eb2c1a08784b48220550316f58"
Archived-At: 
Subject: Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 14:02:19 -0000

--94eb2c1a08784b48220550316f58
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks I will add these by the end of the day.
Yours,
Daniel

On Mon, May 22, 2017 at 1:56 PM, Benjamin Kaduk  wrote:

> Thanks for the updates; the new revision addresses my concerns raised in
> the secdir review.
>
> However,
>
> % In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2
> % [RFC4346] splits the pre-master in two parts.
>
> s/TL1.2/TLS 1.1/, and maybe the ending as "split the pre-master secret
> into two parts".
>
> % the PSK and pre-master are treated by
> % distinct hash function with distinct properties.
>
> s/pre-master/ECDHE shared secret/?
>
> -Ben
>
>
> On 05/19/2017 03:18 PM, Daniel Migault wrote:
>
> Hi,
>
> Thank you to all reviewers for their feed backs. Please find the latest v=
ersion, which as far as I know includes all comments. Comments were not con=
troversial. In order to raise next reviews I am raising aspects that might =
need a bit more attention.
>
> 1)  The current document mentions I-D.ietf-tls-rfc4492bis and I-D.ietf-tl=
s-tls13 as normative. We can wait for these documents to become RFCs, but w=
e can also dowref them to informational reference if we want to move that d=
ocument forward. I will leave the AD to decide, and changes if needed can b=
e done by the RFC -editor
>
> 2)  Section 4 has the following text:
>
> """In the case of ECDHE_PSK authentication, the PSK and pre-master are tr=
eated by distinct hash function with distinct properties.  This may introdu=
ce vulnerabilities over the expected security provided by the constructed p=
re-master. As such TLS 1.0 and TLS 1.1 should not be  used with ECDHE_PSK. =
"""
>
> With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher su=
ites defined in the document.  I just want to make sure we are ok with the =
last sentence.
>
> Yours,
> Daniel
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org ]
> Sent: Friday, May 19, 2017 4:03 PM
> To: John Mattsson  ; Daniel Migault  ; tls-chairs@ietf.org
> Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.tx=
t
>
>
> A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
> has been successfully submitted by Daniel Migault and posted to the IETF =
repository.
>
> Name:		draft-ietf-tls-ecdhe-psk-aead
> Revision:	04
> Title:		ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport La=
yer Security (TLS)
> Document date:	2017-05-18
> Group:		tls
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe=
-psk-aead-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk=
-aead/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead=
-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdh=
e-psk-aead-04
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-ecdhe-=
psk-aead-04
>
> Abstract:
>    This document defines several new cipher suites for the Transport
>    Layer Security (TLS) protocol.  The cipher suites are all based on
>    the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>    (ECDHE_PSK) key exchange together with the Authenticated Encryption
>    with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>    provides light and efficient authentication, ECDHE provides forward
>    secrecy, and AES-GCM and AES-CCM provides encryption and integrity
>    protection.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submiss=
ion until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c1a08784b48220550316f58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks I will add these by the end of the day. <=
br>
Yours, 
Daniel

On Mon, May 22, 2017 at 1:56 PM, Benjamin Kaduk <=
bkaduk@akamai.com> wrote:

 =20
   =20
 =20
  

    Thanks for the updates; the new revision addresses my concerns
      raised in the secdir review.

      

      However,

      

      % In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2
      % [RFC4346] splits the pre-master in two parts.

      

      s/TL1.2/TLS 1.1/, and maybe the ending as "split the pre-master
      secret into two parts".

      

      % the PSK and pre-master are treated by

      % distinct hash function with distinct properties.

    

    s/pre-master/ECDHE shared secret/?

    

    -Ben


    

    
On 05/19/2017 03:1=
8 PM, Daniel Migault
      wrote:

    

    

      
Hi,=20

Thank you to all reviewers for their feed backs. Please find the latest ver=
sion, which as far as I know includes all comments. Comments were not contr=
oversial. In order to raise next reviews I am raising aspects that might ne=
ed a bit more attention. =20

1)  The current document mentions I-D.ietf-tls-rfc4492bis and I-D.ietf-tls-=
tls13 as normative. We can wait for these documents to become RFCs, but we =
can also dowref them to informational reference if we want to move that doc=
ument forward. I will leave the AD to decide, and changes if needed can be =
done by the RFC -editor

2)  Section 4 has the following text:

"""In the case of ECDHE_PSK authentication, the PSK and pre-=
master are treated by distinct hash function with distinct properties.  Thi=
s may introduce vulnerabilities over the expected security provided by the =
constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be  used wit=
h ECDHE_PSK. """

With EDCHE_PSK being the ECDHE PSK method not restricted to the cipher suit=
es defined in the document.  I just want to make sure we are ok with the la=
st sentence.=20

Yours,=20
Daniel

-----Original Message-----
From: internet-drafts@ietf.org<=
/a> [mailto:internet-drafts@ietf.<=
wbr>org]=20
Sent: Friday, May 19, 2017 4:03 PM
To: John Mattsson <john.matts=
son@ericsson.com>; Daniel Migault <daniel.migault@ericsson.com>; tls-chairs@ietf.org
Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04=
.txt


A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF re=
pository.

Name:		draft-ietf-tls-ecdhe-psk-aead
Revision:	04
Title:		ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Laye=
r Security (TLS)
Document date:	2017-05-18
Group:		tls
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-iet=
f-tls-ecdhe-psk-aead-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-ps=
k-aead/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-=
04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-=
tls-ecdhe-psk-aead-04
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-=
ecdhe-psk-aead-04

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol.  The cipher suites are all based on
   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
   (ECDHE_PSK) key exchange together with the Authenticated Encryption
   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
   provides light and efficient authentication, ECDHE provides forward
   secrecy, and AES-GCM and AES-CCM provides encryption and integrity
   protection.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mai=
lman/listinfo/tls


    

    

  



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c1a08784b48220550316f58--


From nobody Tue May 23 09:53:19 2017
Return-Path: 
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 42F29129BB6 for ; Tue, 23 May 2017 09:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8tDsfvnWEEtU for ; Tue, 23 May 2017 09:53:15 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30449129BB7 for ; Tue, 23 May 2017 09:53:13 -0700 (PDT)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1dDD3V-00083U-Gz for tls@ietf.org; Tue, 23 May 2017 18:53:11 +0200
Received: from internal.xmail09.myhosting.com ([10.5.2.31] helo=xmail09.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dDD3O-0003xQ-Of for tls@ietf.org; Tue, 23 May 2017 12:53:06 -0400
Received: (qmail 17296 invoked from network); 23 May 2017 16:53:00 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.98]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 May 2017 16:52:59 -0000
To: tls@ietf.org
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com> 
From: Christian Huitema 
Message-ID: <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net>
Date: Tue, 23 May 2017 09:52:57 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------959FFB88B12028CAC953A15E"
X-Originating-IP: 168.144.250.177
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrx020Zi//u8HtKCQmu2avRRcOb18WfxGyg6Om6u4YYmz3HWtx6ULqZPKO4 CxOGNv05hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0ma9ESR2T lyxgm/asCsGmwrbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oaw3SZdCEEykPbW5B2y73KchnOoRs9Tq8+LVB +WakvuJMxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+6JGvz6FazW2uq9LM3++XT4UhuDAoR32cV4eNY9hrm4n
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 16:53:17 -0000

This is a multi-part message in MIME format.
--------------959FFB88B12028CAC953A15E
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 5/22/2017 7:53 PM, Colm MacC=E1rthaigh wrote:
>
>
> On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk  > wrote:
>
>
>     Sorry for being daft, but a direct link to this additional
>     side-channel would be helpful.
>
>
> I should have done it the first time.  Here it
> is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.=
html
>

Colm's point is that for many DNS servers, queries are not truly
stateless. The answer to a query for AAAA records for example.net might
vary over time, or even query to query, for example to manage load
balancing. Adversaries can predict these variations. They can observe
the state of the server before and after replaying 0-RTT data. If they
observed that the 0-RTT data caused the answer to change, they can
confirm that the 0-RTT data contained a request to that server.

I take that as an example of the more generic statement, that it is
really difficult to guarantee that transactions are really stateless.
Some transactions are apparently stateless, because the operation in
theory only reads data from the server. But even these transactions can
change the state of the server in subtle ways, such as servers managing
load balancing. Another example would be web servers rotating
advertisements on the page, which also can be observed. If I get Colm's
point correctly, he asserts that this is a fairly general pattern, and
that only fools can assume that a given transaction is "stateless".

I take that as a strong argument for requiring "at most once"
functionality for 0-RTT data.

-- Christian Huitema


--------------959FFB88B12028CAC953A15E
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 5/22/2017 7:53 PM, Colm MacCárthaigh
      wrote:

    

    

      


        


          
On Mon, May 22, 2017 at 7:23 PM,
            Benjamin Kaduk <bkaduk@akamai.com> wrote:

            

              


                 Sorry for being daft, but a direct link to this
                additional side-channel would be helpful.

              

            

            


            

            
I should have done it the first time.  Here it is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html
              

            

          

        

      

    

    

    Colm's point is that for many DNS servers, queries are not truly
    stateless. The answer to a query for AAAA records for example.net
    might vary over time, or even query to query, for example to manage
    load balancing. Adversaries can predict these variations. They can
    observe the state of the server before and after replaying 0-RTT
    data. If they observed that the 0-RTT data caused the answer to
    change, they can confirm that the 0-RTT data contained a request to
    that server.

    

    I take that as an example of the more generic statement, that it is
    really difficult to guarantee that transactions are really
    stateless. Some transactions are apparently stateless, because the
    operation in theory only reads data from the server. But even these
    transactions can change the state of the server in subtle ways, such
    as servers managing load balancing. Another example would be web
    servers rotating advertisements on the page, which also can be
    observed. If I get Colm's point correctly, he asserts that this is a
    fairly general pattern, and that only fools can assume that a given
    transaction is "stateless".

    

    I take that as a strong argument for requiring "at most once"
    functionality for 0-RTT data.

    
-- Christian Huitema

  


--------------959FFB88B12028CAC953A15E--


From nobody Tue May 23 10:34:53 2017
Return-Path: 
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 5759C129C34 for ; Tue, 23 May 2017 10:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 R2rPgUynEn7G for ; Tue, 23 May 2017 10:34:49 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0430E129BC7 for ; Tue, 23 May 2017 10:34:48 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NHN14m003768; Tue, 23 May 2017 18:34:47 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=3h5jKruB+YWZ2rtcJOokrm92pGylb/BN/0QvdeOgpgY=; b=eqaFLzeSviV3jhBRtLl1zB52SYeUsrRk9DeHk7H2jMsi5LCtk0Wd5pe5LP1moSh7QIbm tkJo9ddk6fYH0oJ2PhlZ8VL27CHySHfM00o4ti73Z4mu988T/RI+MLS5HS1l7WcHl65M AVgjFjl1z5uN/N1JTjujY2FjixRdAmJesmJ9Rza72ey32H72IlA2wJXP1gk3J1Fh49PW OAWolmotUrZ0GFUxLneHO6d4rxdwfH7xYUTVVIkOXZvAYtzN/PQ50AiCufdOoQGhVWEx K1ECbHIkwNUqi502if0mMDlQ04rRsctBD0JK8XZUzDaBHzVXhnNAVg8Ex0+R5wjmrCpS wg== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2am4nrxrjx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 18:34:46 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NHPdk0018185; Tue, 23 May 2017 13:34:45 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ajh4v1jgu-1; Tue, 23 May 2017 13:34:45 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 345741FC72; Tue, 23 May 2017 17:34:45 +0000 (GMT)
To: Markulf Kohlweiss , "tls@ietf.org" 
Cc: Samin Ishtiaq , Antoine Delignat-Lavaud , Britta Hale 
References: 
From: Benjamin Kaduk 
Message-ID: <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
Date: Tue, 23 May 2017 12:34:44 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------79349C73AE74F3013C967953"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230088
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230088
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:34:50 -0000

This is a multi-part message in MIME format.
--------------79349C73AE74F3013C967953
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

My initial thoughts...

On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also hope that it will clarify any remaining
> problems of understanding that I have on the issue.
>
> If we see EOED as a stream termination signal, then there seems
> to be a difference in performance for conservative servers that
> want to wait until receiving all 0RTT data before responding to
> the client's request in 0.5RTT communication.
>
> Said otherwise, we want servers to be able to respond with application 
> data based on application data from the client and know that that 
> that data was not truncated.

Thanks, the keyword of "truncated" caused me to understand the intended
point.

I think this question ends up tying into the more philosophical one of
whether early data and 1-rtt data are considered "separate streams" or
not -- if they are separate streams with distinct end/start, then of
course one wants to detect possible truncation as it happens.  But, if
they are conceptually the same stream and the boundary between them is
"just" a bookkeeping operation of key change, then there is no need to
be concerned about detecting truncation; the application just continues
reading in data and replying when complete application protocol requests
are received.

-Ben

--------------79349C73AE74F3013C967953
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    My initial thoughts...

    

    On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:

    

      
I am paraphrasing a long thread on the issue that we had within
the miTLS development team, and I am primarily commenting on the
analysis aspects. I also hope that it will clarify any remaining
problems of understanding that I have on the issue.

If we see EOED as a stream termination signal, then there seems
to be a difference in performance for conservative servers that
want to wait until receiving all 0RTT data before responding to
the client's request in 0.5RTT communication.

Said otherwise, we want servers to be able to respond with application 
data based on application data from the client and know that that 
that data was not truncated.


    

    

    Thanks, the keyword of "truncated" caused me to understand the
    intended point.

    

    I think this question ends up tying into the more philosophical one
    of whether early data and 1-rtt data are considered "separate
    streams" or not -- if they are separate streams with distinct
    end/start, then of course one wants to detect possible truncation as
    it happens.  But, if they are conceptually the same stream and the
    boundary between them is "just" a bookkeeping operation of key
    change, then there is no need to be concerned about detecting
    truncation; the application just continues reading in data and
    replying when complete application protocol requests are received.

    

    -Ben

  


--------------79349C73AE74F3013C967953--


From nobody Tue May 23 10:46:39 2017
Return-Path: 
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 208B8129C52; Tue, 23 May 2017 10:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level: 
X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 P5uPHT1F9x4y; Tue, 23 May 2017 10:46:29 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B843127137; Tue, 23 May 2017 10:46:29 -0700 (PDT)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wXNHl3GMxz274x; Tue, 23 May 2017 19:46:27 +0200 (CEST)
X-purgate-ID: 152705::1495561587-0000088C-8540E222/0/0
X-purgate-size: 1987
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3wXNHl1gKgz2y6R; Tue, 23 May 2017 19:46:27 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2EDA81A6A6; Tue, 23 May 2017 19:46:27 +0200 (CEST)
In-Reply-To: <20170523133441.54A901A6A6@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Tue, 23 May 2017 19:46:27 +0200 (CEST)
CC: Eric Rescorla , tls-chairs@ietf.org,  draft-ietf-tls-ecdhe-psk-aead@ietf.org, The IESG ,  tls@ietf.org
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170523174627.2EDA81A6A6@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:46:31 -0000

It seems I had a typo in the new text.

Martin Rex wrote:
> Eric Rescorla wrote:
>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> The following text appears to have been added in -04
>> 
>>    A server receiving a ClientHello and a client_version indicating
>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>    this document in ClientHello.cipher_suites can safely assume that
>> the
>>    client supports TLS 1.2 and is willing to use it.  The server MUST
>>    NOT negotiate these cipher suites with TLS protocol versions earlier
>>    than TLS 1.2.  Not requiring clients to indicate their support for
>>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello

That line should say
                                         through ClientHello.client_version

>>    improves the interoperability in the installed base and use of TLS
>>    1.2 AEAD cipher suites without upsetting the installed base of
>>    version-intolerant TLS servers, results in more TLS handshakes
>>    succeeding and obviates fallback mechanisms.
>> 
>> This is a major technical change from -03, which, AFAIK, prohibited
>> the server from negotiating these algorithms with TLS 1.1 and below
>> and maintained the usual TLS version 1.2 negotiation rules.
> 
> This change _still_ prohibits the server from negotiating these algorithms
> with TLSv1.1 and below.
> 
> Could you elaborate a little on where and why you see a problem with this?
> 
> As this change tries to explain, had such a text been used for all
> TLSv1.2 AEAD cipher suite code points, then browsers would have never
> needed any "downgrade dance" fallbacks, POODLE would have never
> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
> would not have been needed, either.


From nobody Tue May 23 10:50:57 2017
Return-Path: 
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 2519B129C53 for ; Tue, 23 May 2017 10:50:56 -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] 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 uEFnIwlxnl83 for ; Tue, 23 May 2017 10:50:54 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86ACA129AB3 for ; Tue, 23 May 2017 10:50:54 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C244D7A32F1 for ; Tue, 23 May 2017 17:50:53 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net>
Date: Tue, 23 May 2017 13:50:52 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org>
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net>
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:50:56 -0000

> On May 23, 2017, at 12:52 PM, Christian Huitema  =
wrote:
>=20
> Colm's point is that for many DNS servers, queries are not truly =
stateless. The answer to a query for AAAA records for example.net might =
vary over time, or even query to query, for example to manage load =
balancing. Adversaries can predict these variations. They can observe =
the state of the server before and after replaying 0-RTT data. If they =
observed that the 0-RTT data caused the answer to change, they can =
confirm that the 0-RTT data contained a request to that server.

The fix is to amend DNSpriv to require stateless (random rather
than say round-robit) RRset rotation.  With random rotation, the
next RRset order is independent of previous queries.

Secondly, even with the 0-RTT leak, while privacy against an active
attacker might not be assured for all users, there is fact privacy
for most users, especially against a purely passive adversary.

DNS privacy is always an imperfect security mechanism because
the DNS query will often at in the provider request to the
authoritative servers leak the user's "subnet" in the clear,
typically in the form of the containing /20 CIDR block to aid
load-balacing CDNs.  Then after the response is received, the
client will send IP datagrams that further narrow the set of
potential domains.  Then in visiting a website there'll be
unencrypted SNI, or predictable patter of response sizes and
consequent retrieval of CSS/javascript/image resources that
fingerprint the request.

Cryptography and 0-RTT are far from the weakest link in the
chain here.  DNSpriv is necessarily imperfect incremental
security, and defeating traffic analysis is exceedingly
difficult.

To the extent that DNSpriv over TLS happens at all, 0-RTT
will be used for DNS, and will be used statelessly (allowing
replays).  If there are sufficiently cheap ways to improve
security (e.g. random RRset rotation) without sacrifing
performance, increasing latency or adding complexity, then
by all means promote their adoption.

--=20
	Viktor.


From nobody Tue May 23 10:52:01 2017
Return-Path: 
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 BFCA5129C5C for ; Tue, 23 May 2017 10:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 pdhen3xZugGw for ; Tue, 23 May 2017 10:51:58 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CB7129C59 for ; Tue, 23 May 2017 10:51:58 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 087B420051C23; Tue, 23 May 2017 10:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XAcQKrAS10Hy8z eeT60q2TFosgA=; b=tS98rKszLEhvBb8cUjYJVfHhsCNNmBHM2CT0lc0B9FQR4u msRgvlI0PW5f8+mFAVcycFOFGC08Wmoa39W2ZQ6yTRQ4gkedUWKSa/eh3P6LJqAz kaNgp9FSrHAGIvYHy+DA7/nTmPtOpsc434OlCSibGbMAf5yYAcHKWcuVz9Ezw=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 8F4E520051C22; Tue, 23 May 2017 10:51:57 -0700 (PDT)
Date: Tue, 23 May 2017 12:51:55 -0500
From: Nico Williams 
To: Dave Garrett 
Cc: tls@ietf.org, Viktor Dukhovni , Eric Rescorla 
Message-ID: <20170523175154.GT10188@localhost>
References:    <201705222019.46521.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201705222019.46521.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:52:00 -0000

On Mon, May 22, 2017 at 08:19:46PM -0400, Dave Garrett wrote:
> On Monday, May 22, 2017 05:31:55 pm Viktor Dukhovni wrote:
> > So if putting the consensus to ban MD5/SHA-1 in its *proper context*
> > is consistent with the WG consensus, let's do that.
> 
> Yes, please.

+1

> On Monday, May 22, 2017 05:00:20 pm Nico Williams wrote:
> > Well, I want it to be crystal clear that the "not MD5 and such"
> > requirement need not apply to opportunistic TLS usage.  If you don't
> > like my text, maybe you can propose your own.
> 
> My issue with this area is [...]
>                                            [...]. To do this in a
> non-messy way, we'd have to delete the SHA-1 special-casing and state
> that TLS 1.3+ implementations can only use deprecated hashes
> (MD5/SHA1/SHA224/etc) if explicitly doing opportunistic encryption or some
> scenario where trust can be established without validating them. Again,

Works for me!

> the trust anchor gets an exception here due to it being trusted directly
> without need for validation, and they can get away with just a "NOT
> RECOMMENDED". If we can agree to this, then the resulting text will end up
> being far less problematic. If we can't get a consensus for this, I seriously
> propose citing RFC 6919 s3.

Yes, trust anchors are and should always be excepted (and need not be in
the form of certificates anyways).

Nico
-- 


From nobody Tue May 23 11:07:16 2017
Return-Path: 
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 87469129C5D for ; Tue, 23 May 2017 11:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 QuDFn0onBceq for ; Tue, 23 May 2017 11:07:14 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FCB129C56 for ; Tue, 23 May 2017 11:07:14 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id A3D7C20051C25; Tue, 23 May 2017 11:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=elFBisDrwNt9kq V76SbMQhsa/20=; b=keF/j76LPN8+5kgeL6yQRAClM/QOfXrn+7wybUEoUaTW+t l5+9yVyIZtBNYKXGke2bzrGRFcH8fPwLdrRBEJ9D5clBJdveIb+mS0+TeanXZhAl upUMcYdmCdWN9cyn9Wgt0YOSPUSWvJZQ+HboB/04AVw/RjaVE0UEVppbHz+wo=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 58FBA20051C24; Tue, 23 May 2017 11:07:13 -0700 (PDT)
Date: Tue, 23 May 2017 13:07:11 -0500
From: Nico Williams 
To: Dave Garrett 
Cc: tls@ietf.org
Message-ID: <20170523180710.GU10188@localhost>
References:  <201705222019.46521.davemgarrett@gmail.com>  <201705222057.30588.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201705222057.30588.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: [TLS] Standard security levels (was Re: Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13))
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:07:15 -0000

On Mon, May 22, 2017 at 08:57:30PM -0400, Dave Garrett wrote:
> On Monday, May 22, 2017 08:29:13 pm Viktor Dukhovni wrote:
> > Setting a collision-resistance floor rather than naming some list
> > of algorithms makes more sense to me, but if the WG really feels
> > that naming some "verbotten" algorithms is better, so be it.
> 
> My preference would be to do both. Call out the ones we have
> codepoints for by name (MD5/SHA1/SHA224), then have a general
> collision-resistance floor value for everything else.

Sure.

In general I prefer setting floors, as Viktor says.  That's because
listing all forbidden algorithms is easy to flub up, and because it's
much easier from an API point of view to specify security levels than to
go listing things that are allowed/forbidden.

I think we should have standard algorithm security profile names that
can be used in multiple protocols.  E.g.,

 - weak         (obsolete weak algorithms allowed)
 - interim      (certain obsolete weak algorithms allowed during migrations)
 - default      (default security floors, no obsolete weak algorithms allowed)
 - stronger     (like standard but with higher security floors)

 -        (local/custom security level, perhaps specified
                 additively from standard security levels)

The meaning of each of these would be updated over time by updating the
RFCs for the relevant protocols.  Thus configurations would not have to
change.

Specifying such a security level to TLS would have it apply that level
to its ciphersuite, PRF, key agreement, PSK, and signature algorithms,
and pass it to PKIX when using PKIX.

Specifying such a security level to PKIX would have it apply that level
to certificate public key and certificate signature algorithms, as well
as to path construction and validation.

Specifying such a security level to Kerberos, SSHv2, ... would ...
And so on.

This would make security level configuration much easier in the common
case.  And would avoid periodically having to update configurations to
adjust for recent cryptanalysis advances: just update the meanings of
these standard security levels and update software.

Nico
-- 


From nobody Tue May 23 11:07:49 2017
Return-Path: 
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 7ED0F129C70 for ; Tue, 23 May 2017 11:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 DJtuKYS1SpdU for ; Tue, 23 May 2017 11:07:46 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB43E129C6F for ; Tue, 23 May 2017 11:07:45 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id p143so39908378yba.2 for ; Tue, 23 May 2017 11:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EAgjVa5yoq+K0qPOFyGd3/Lv5g/7d1wX7nsgCFu90yE=; b=VmiA5m8KyC5pVcVNVlcjCfQSZkTiYTtPLl+RKJgOx6eCpf2g4fvS9iUqVH+vJmJGqO txmDeeFtQKhtejMVvG6e0V8Ezknl065PvMkcdhBH6AowsJ05wrowrWKiLSV9zO+fEtj5 kFmBLXkXkRRCXGbk9j5aJrltHDSYF28oh/XgxaJGpLBq1p3YOiog3KBPqg9nDLnoXwdg LnDeL9ikLD27xDSYgnuv2tvrKhR2PFsE/JOSiSmwm29nAzI7LBpZ1Ck5MilJyF/5H4WV dgB61+11oUbW5rD2GGWvRNsa5KivCCn+MV89rJz2fYEsCyEcHXLiomGW0FlgmSIO7mQi XuaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EAgjVa5yoq+K0qPOFyGd3/Lv5g/7d1wX7nsgCFu90yE=; b=I3B7gxzj4c9N8ohRwQEuYKrjE77dO2xs6eeZu/ANir3BZP4krCRUl/5yhSpzVRyeel CvCe89gylcYikk0qaZcxgMMj7PyAJWcomaSCsJ5t9Lze0+bibNGTCDdswI/H5Y+ICXGq 7kq1LaQ8B8wCwuSfCdl8XNfnkTuEvT9W//FaeYO1ltOGna02a9OOXAys2WLq4ZiddTiF 54+yXjQPFt1a69KEeNxSWmcUeaUWQ2s2SqQwUGciPUBK7FpbR1ruITzTl8IqcLC8JQzt QsYlIy2qOB3QFWGU/SW/gEDdxSuPmbDtc8NDcyS3+GVTJ32bFA6ZshsIMbRbXOB96/iE mhGw==
X-Gm-Message-State: AODbwcD1/kTF0kCSKYM4zYK5BrlTynR/5RLe5D8sip0qc2ZHbFh/+vve 7OASRKVKfBJNATdu7qx75+iRGabWlzbG3zc=
X-Received: by 10.37.180.18 with SMTP id n18mr23321166ybj.116.1495562864717; Tue, 23 May 2017 11:07:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Tue, 23 May 2017 11:07:43 -0700 (PDT)
In-Reply-To: <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org>
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Tue, 23 May 2017 11:07:43 -0700
Message-ID: 
To: TLS WG 
Content-Type: multipart/alternative; boundary="f403045e6aa24ae4ef055034dda4"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:07:47 -0000

--f403045e6aa24ae4ef055034dda4
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 10:50 AM, Viktor Dukhovni 
wrote:

> The fix is to amend DNSpriv to require stateless (random rather
> than say round-robit) RRset rotation.  With random rotation, the
> next RRset order is independent of previous queries.
>

That's a good fix for that specific local problem. But next, consider a
different one; what if a DNS provider has q-tuple rate-limiting for DOS
attacks? That's not an unusual measure for large providers - even bind9 has
support for it. Well with stateless 0RTT I can replay the clients query
over and over until the rate-limiting trips; now I have a DOS attack *and*
a privacy-defeating attack; because the rate limit exposes what the query
was for.


> Secondly, even with the 0-RTT leak, while privacy against an active
> attacker might not be assured for all users, there is fact privacy
> for most users, especially against a purely passive adversary.
>

My reference here isn't really meant as a criticism of DNSPriv - we should
make DNS private and secure, that's awesome, and it's a small attack in the
overall context of DNS. It's meant like Christian said; it is really really
hard to make an application protocol idempotent and side-effect free and
very smart people are often wrong about assuming that they are. I see
at-most-once 0-RTT mitigation as essential to avoiding a lot of real world
security issues here, because of that difficulty.


> To the extent that DNSpriv over TLS happens at all, 0-RTT
> will be used for DNS, and will be used statelessly (allowing
> replays).


That's not good for users, and seems like another very strong reason to
make it clear in the TLS draft that that it is not secure. FWIW; DNSCurve
includes nonces to avoid attacks like this:
https://dnscurve.org/replays.html (which means keeping state).

Stateless mechanisms simply aren't secure. We wish they were; because it is
so attractive operationally - just as it would be nice if my MD5
accelerators were still useful. But they don't hold up. We've even seen
this before with DTLS; where replay tolerance opened up the window to
several cryptographic attacks. It's an all-round bad idea.

I've seen a number of arguments here that essentially boil down to "We'd
like to keep it anyway, because it is so operationally convenient". Is that
really how this process works? Don't demonstrable real-world attacks
deserve deference?

-- 
Colm

--f403045e6aa24ae4ef055034dda4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 23, 2017 at 10:50 AM, Viktor Dukhovni <=
;ietf-dane@dukh=
ovni.org> wrote:
The fix is to amend DN=
Spriv to require stateless (random rather

than say round-robit) RRset rotation.=C2=A0 With random rotation, the

next RRset order is independent of previous queries.
<=
br>
That's a good fix for that specific local problem. But ne=
xt, consider a different one; what if a DNS provider has q-tuple rate-limit=
ing for DOS attacks? That's not an unusual measure for large providers =
- even bind9 has support for it. Well with stateless 0RTT I can replay the =
clients query over and over until the rate-limiting trips; now I have a DOS=
 attack *and* a privacy-defeating attack; because the rate limit exposes wh=
at the query was for.=C2=A0
=C2=A0

Secondly, even with the 0-RTT leak, while privacy against an active

attacker might not be assured for all users, there is fact privacy

for most users, especially against a purely passive adversary.

My reference here isn't really meant as a criti=
cism of DNSPriv - we should make DNS private and secure, that's awesome=
, and it's a small attack in the overall context of DNS. It's meant=
 like Christian said; it is really really hard to make an application proto=
col idempotent and side-effect free and very smart people are often wrong a=
bout assuming that they are. I see at-most-once 0-RTT mitigation as essenti=
al to avoiding a lot of real world security issues here, because of that di=
fficulty.=C2=A0
=C2=A0
To the extent that D=
NSpriv over TLS happens at all, 0-RTT

will be used for DNS, and will be used statelessly (allowing

replays).=C2=A0 

That's not good for us=
ers, and seems like another very strong reason to make it clear in the TLS =
draft that that it is not secure. FWIW; DNSCurve includes nonces to avoid a=
ttacks like this:=C2=A0https:=
//dnscurve.org/replays.html (which means keeping state).=C2=A0
=C2=A0
Stateless mechanisms simply aren't secure. We wish t=
hey were; because it is so attractive operationally - just as it would be n=
ice if my MD5 accelerators were still useful. But they don't hold up. W=
e've even seen this before with DTLS; where replay tolerance opened up =
the window to several cryptographic attacks. It's an all-round bad idea=
.=C2=A0

I've seen a number of arguments here t=
hat essentially boil down to "We'd like to keep it anyway, because=
 it is so operationally convenient". Is that really how this process w=
orks? Don't demonstrable real-world attacks deserve deference?

-- 
Colm




--f403045e6aa24ae4ef055034dda4--


From nobody Tue May 23 11:17:57 2017
Return-Path: 
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 5557E12E03B for ; Tue, 23 May 2017 11:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.391
X-Spam-Level: 
X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 xPcw_0S_oQ7d for ; Tue, 23 May 2017 11:17:48 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A112DDD2 for ; Tue, 23 May 2017 11:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LYHL/T+8M5XPwbrlsG4q8peQwd3ctwVyM54MAus1UEQ=; b=e0fh0voOUWRGzoin3VrEBmIgPf2oDTdkQ8yNuULDi4BxBxRA03gX4YGkeiJwTf5J98F9Ui4SByOCFIb0RsTZGbaQU2j0/RITV+0uqzYw/XhiaHBF+zoNXIkmTT+tQHjHtWxLCQrMFhiq4IELsZPIO45hHUBvYeKsz62S/7N9Vdg=
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com (129.75.139.20) by DB5PR83MB0038.EURPRD83.prod.outlook.com (129.75.21.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.0; Tue, 23 May 2017 18:17:42 +0000
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com ([fe80::ac56:1e73:9b19:5ba6]) by DB6PR8303MB0069.EURPRD83.prod.outlook.com ([fe80::ac56:1e73:9b19:5ba6%18]) with mapi id 15.01.1143.000; Tue, 23 May 2017 18:17:41 +0000
From: Markulf Kohlweiss 
To: Benjamin Kaduk , "tls@ietf.org" 
CC: Samin Ishtiaq , Antoine Delignat-Lavaud , Britta Hale 
Thread-Topic: [TLS] Comments on EndOfEarlyData
Thread-Index: AdLTtEU8p75Loa4ER0+xBa7xoDxY0QANphQAAAFEp8A=
Date: Tue, 23 May 2017 18:17:40 +0000
Message-ID: 
References:  <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
In-Reply-To: <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2a01:110:8012:1010::35d]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR83MB0038; 7:JxKwrYAecOI1ktXeS3P4MiEVSTrMF4AMglsJdI6w7OA5SBop42nCTiiaH30SSkrptgiBukI3fmi3Yzzm4gxAiBU//w/90umBk0HyvesP/vshhwLe5MfVnVGSuCnpz9Py27oRfvme7l+Vl84LbUjieEmrmd0HycvFBGAHYdCM8NvlJM7hpMlOoGyFiNfaolQXfpStcNzXd4O764/dXzZfg0BOXRGnxqVws17DWatEb8gQTnEIeKFizPt4Hq/gC+rrJCf1tqq3TzKyJKxbmcEJvrhT1yA4CpzJFEsRHo9URYaRDDgMog0ArEHfzhBFFWhitLeXL+pJYkuXpN5k39viCC+/4E9oAT5eNiuYS3RNmLo=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6029001)(6009001)(39450400003)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(24454002)(377454003)(6436002)(6506006)(7736002)(2900100001)(229853002)(86362001)(7696004)(86612001)(2906002)(3660700001)(478600001)(10290500003)(25786009)(53546009)(3280700002)(33656002)(189998001)(2501003)(2950100002)(4326008)(5250100002)(6116002)(790700001)(10090500001)(53936002)(38730400002)(5660300001)(74316002)(54906002)(9686003)(76176999)(54356999)(6246003)(99286003)(55016002)(81166006)(5005710100001)(8936002)(8676002)(6306002)(54896002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR83MB0038; H:DB6PR8303MB0069.EURPRD83.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-traffictypediagnostic: DB5PR83MB0038:
x-ms-office365-filtering-correlation-id: a41a29e7-2d81-4a51-a122-08d4a208002b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DB5PR83MB0038; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700043)(100105000095)(100000701043)(100105300095)(100000702043)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703043)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704043)(100105200095)(100000705043)(100105500095); SRVR:DB5PR83MB0038; BCL:0; PCL:0; RULEID:(100000800043)(100110000095)(100000801043)(100110300095)(100000802043)(100110100095)(100000803043)(100110400095)(100000804043)(100110200095)(100000805039)(100110500095); SRVR:DB5PR83MB0038; 
x-forefront-prvs: 0316567485
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR8303MB00697808B11F2DB538106038ABF90DB6PR8303MB0069_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 18:17:40.9723 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR83MB0038
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:17:51 -0000

--_000_DB6PR8303MB00697808B11F2DB538106038ABF90DB6PR8303MB0069_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

R2l2ZW4gdGhhdCAwLVJUVCBhbmQgMS1SVFQgZ3VhcmFudGVlcyBhcmUgdmVyeSBkaWZmZXJlbnQs
IGl0IHNlZW0gaW1wb3J0YW50IHRvIGRpc3Rpbmd1aXNoIHRoZSB0d28gc3RyZWFtcyBhbmQgbW9k
ZWwgdGhlbSBzZXBhcmF0ZWx5Lg0KDQpPZiBjb3Vyc2UgdGhhdCBkb2VzIG5vdCBwcmV2ZW50IGFw
cGxpY2F0aW9ucyB0aGF0IHdhbnQgdG8gdHJlYXQgdGhlbSBhcyBhIHNpbmdsZSBzdHJlYW0sIGJ1
dCBpdCBpcyBoYXJkZXIgdG8gdW5kZXJzdGFuZCB0aGUgc2VjdXJpdHkgb25lIGdldHMgZnJvbSBz
dWNoIGEgbWl4ZWQgY2hhbm5lbCwgZS5nLiBzb21lIHJlcXVlc3RzIG1heSBoYXZlIHN0cm9uZyBy
ZXBsYXkgcHJvdGVjdGlvbiwgb3RoZXJzIHdvbuKAmXQuDQoNCi0tbWFya3VsZg0KDQpGcm9tOiBC
ZW5qYW1pbiBLYWR1ayBbbWFpbHRvOmJrYWR1a0Bha2FtYWkuY29tXQ0KU2VudDogMjMgTWF5IDIw
MTcgMTg6MzUNClRvOiBNYXJrdWxmIEtvaGx3ZWlzcyA8bWFya3VsZkBtaWNyb3NvZnQuY29tPjsg
dGxzQGlldGYub3JnDQpDYzogU2FtaW4gSXNodGlhcSA8U2FtaW4uSXNodGlhcUBtaWNyb3NvZnQu
Y29tPjsgQW50b2luZSBEZWxpZ25hdC1MYXZhdWQgPGFudGRsQG1pY3Jvc29mdC5jb20+OyBCcml0
dGEgSGFsZSA8YnJpdHRhLmhhbGVAaXRlbS5udG51Lm5vPg0KU3ViamVjdDogUmU6IFtUTFNdIENv
bW1lbnRzIG9uIEVuZE9mRWFybHlEYXRhDQoNCk15IGluaXRpYWwgdGhvdWdodHMuLi4NCg0KT24g
MDUvMjMvMjAxNyAwNjo1MCBBTSwgTWFya3VsZiBLb2hsd2Vpc3Mgd3JvdGU6DQoNCg0KSSBhbSBw
YXJhcGhyYXNpbmcgYSBsb25nIHRocmVhZCBvbiB0aGUgaXNzdWUgdGhhdCB3ZSBoYWQgd2l0aGlu
DQoNCnRoZSBtaVRMUyBkZXZlbG9wbWVudCB0ZWFtLCBhbmQgSSBhbSBwcmltYXJpbHkgY29tbWVu
dGluZyBvbiB0aGUNCg0KYW5hbHlzaXMgYXNwZWN0cy4gSSBhbHNvIGhvcGUgdGhhdCBpdCB3aWxs
IGNsYXJpZnkgYW55IHJlbWFpbmluZw0KDQpwcm9ibGVtcyBvZiB1bmRlcnN0YW5kaW5nIHRoYXQg
SSBoYXZlIG9uIHRoZSBpc3N1ZS4NCg0KDQoNCklmIHdlIHNlZSBFT0VEIGFzIGEgc3RyZWFtIHRl
cm1pbmF0aW9uIHNpZ25hbCwgdGhlbiB0aGVyZSBzZWVtcw0KDQp0byBiZSBhIGRpZmZlcmVuY2Ug
aW4gcGVyZm9ybWFuY2UgZm9yIGNvbnNlcnZhdGl2ZSBzZXJ2ZXJzIHRoYXQNCg0Kd2FudCB0byB3
YWl0IHVudGlsIHJlY2VpdmluZyBhbGwgMFJUVCBkYXRhIGJlZm9yZSByZXNwb25kaW5nIHRvDQoN
CnRoZSBjbGllbnQncyByZXF1ZXN0IGluIDAuNVJUVCBjb21tdW5pY2F0aW9uLg0KDQoNCg0KU2Fp
ZCBvdGhlcndpc2UsIHdlIHdhbnQgc2VydmVycyB0byBiZSBhYmxlIHRvIHJlc3BvbmQgd2l0aCBh
cHBsaWNhdGlvbg0KDQpkYXRhIGJhc2VkIG9uIGFwcGxpY2F0aW9uIGRhdGEgZnJvbSB0aGUgY2xp
ZW50IGFuZCBrbm93IHRoYXQgdGhhdA0KDQp0aGF0IGRhdGEgd2FzIG5vdCB0cnVuY2F0ZWQuDQoN
ClRoYW5rcywgdGhlIGtleXdvcmQgb2YgInRydW5jYXRlZCIgY2F1c2VkIG1lIHRvIHVuZGVyc3Rh
bmQgdGhlIGludGVuZGVkIHBvaW50Lg0KDQpJIHRoaW5rIHRoaXMgcXVlc3Rpb24gZW5kcyB1cCB0
eWluZyBpbnRvIHRoZSBtb3JlIHBoaWxvc29waGljYWwgb25lIG9mIHdoZXRoZXIgZWFybHkgZGF0
YSBhbmQgMS1ydHQgZGF0YSBhcmUgY29uc2lkZXJlZCAic2VwYXJhdGUgc3RyZWFtcyIgb3Igbm90
IC0tIGlmIHRoZXkgYXJlIHNlcGFyYXRlIHN0cmVhbXMgd2l0aCBkaXN0aW5jdCBlbmQvc3RhcnQs
IHRoZW4gb2YgY291cnNlIG9uZSB3YW50cyB0byBkZXRlY3QgcG9zc2libGUgdHJ1bmNhdGlvbiBh
cyBpdCBoYXBwZW5zLiAgQnV0LCBpZiB0aGV5IGFyZSBjb25jZXB0dWFsbHkgdGhlIHNhbWUgc3Ry
ZWFtIGFuZCB0aGUgYm91bmRhcnkgYmV0d2VlbiB0aGVtIGlzICJqdXN0IiBhIGJvb2trZWVwaW5n
IG9wZXJhdGlvbiBvZiBrZXkgY2hhbmdlLCB0aGVuIHRoZXJlIGlzIG5vIG5lZWQgdG8gYmUgY29u
Y2VybmVkIGFib3V0IGRldGVjdGluZyB0cnVuY2F0aW9uOyB0aGUgYXBwbGljYXRpb24ganVzdCBj
b250aW51ZXMgcmVhZGluZyBpbiBkYXRhIGFuZCByZXBseWluZyB3aGVuIGNvbXBsZXRlIGFwcGxp
Y2F0aW9uIHByb3RvY29sIHJlcXVlc3RzIGFyZSByZWNlaXZlZC4NCg0KLUJlbg0K

--_000_DB6PR8303MB00697808B11F2DB538106038ABF90DB6PR8303MB0069_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv
bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0
ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN
Cglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw
dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIg
bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5HaXZlbiB0aGF0IDAtUlRUIGFuZCAxLVJUVCBn
dWFyYW50ZWVzIGFyZSB2ZXJ5IGRpZmZlcmVudCwgaXQgc2VlbSBpbXBvcnRhbnQgdG8gZGlzdGlu
Z3Vpc2ggdGhlIHR3byBzdHJlYW1zIGFuZCBtb2RlbCB0aGVtIHNlcGFyYXRlbHkuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3
aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5PZiBjb3Vyc2UgdGhhdCBkb2Vz
IG5vdCBwcmV2ZW50IGFwcGxpY2F0aW9ucyB0aGF0IHdhbnQgdG8gdHJlYXQgdGhlbSBhcyBhIHNp
bmdsZSBzdHJlYW0sIGJ1dCBpdCBpcyBoYXJkZXIgdG8gdW5kZXJzdGFuZCB0aGUgc2VjdXJpdHkN
CiBvbmUgZ2V0cyBmcm9tIHN1Y2ggYSBtaXhlZCBjaGFubmVsLCBlLmcuIHNvbWUgcmVxdWVzdHMg
bWF5IGhhdmUgc3Ryb25nIHJlcGxheSBwcm90ZWN0aW9uLCBvdGhlcnMgd29u4oCZdC4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS1tYXJrdWxmPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD
b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQmVuamFtaW4gS2FkdWsgW21h
aWx0bzpia2FkdWtAYWthbWFpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMyBNYXkgMjAxNyAx
ODozNTxicj4NCjxiPlRvOjwvYj4gTWFya3VsZiBLb2hsd2Vpc3MgJmx0O21hcmt1bGZAbWljcm9z
b2Z0LmNvbSZndDs7IHRsc0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gU2FtaW4gSXNodGlhcSAm
bHQ7U2FtaW4uSXNodGlhcUBtaWNyb3NvZnQuY29tJmd0OzsgQW50b2luZSBEZWxpZ25hdC1MYXZh
dWQgJmx0O2FudGRsQG1pY3Jvc29mdC5jb20mZ3Q7OyBCcml0dGEgSGFsZSAmbHQ7YnJpdHRhLmhh
bGVAaXRlbS5udG51Lm5vJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gQ29tbWVu
dHMgb24gRW5kT2ZFYXJseURhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5NeSBpbml0aWFsIHRob3VnaHRzLi4uPGJyPg0KPGJyPg0KT24gMDUvMjMvMjAx
NyAwNjo1MCBBTSwgTWFya3VsZiBLb2hsd2Vpc3Mgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+SSBhbSBwYXJhcGhyYXNpbmcgYSBsb25nIHRocmVhZCBvbiB0aGUgaXNz
dWUgdGhhdCB3ZSBoYWQgd2l0aGluPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIG1pVExTIGRl
dmVsb3BtZW50IHRlYW0sIGFuZCBJIGFtIHByaW1hcmlseSBjb21tZW50aW5nIG9uIHRoZTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPmFuYWx5c2lzIGFzcGVjdHMuIEkgYWxzbyBob3BlIHRoYXQgaXQg
d2lsbCBjbGFyaWZ5IGFueSByZW1haW5pbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcm9ibGVt
cyBvZiB1bmRlcnN0YW5kaW5nIHRoYXQgSSBoYXZlIG9uIHRoZSBpc3N1ZS48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JZiB3ZSBzZWUgRU9FRCBh
cyBhIHN0cmVhbSB0ZXJtaW5hdGlvbiBzaWduYWwsIHRoZW4gdGhlcmUgc2VlbXM8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT50byBiZSBhIGRpZmZlcmVuY2UgaW4gcGVyZm9ybWFuY2UgZm9yIGNvbnNl
cnZhdGl2ZSBzZXJ2ZXJzIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53YW50IHRvIHdhaXQg
dW50aWwgcmVjZWl2aW5nIGFsbCAwUlRUIGRhdGEgYmVmb3JlIHJlc3BvbmRpbmcgdG88bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT50aGUgY2xpZW50J3MgcmVxdWVzdCBpbiAwLjVSVFQgY29tbXVuaWNh
dGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5TYWlkIG90aGVyd2lzZSwgd2Ugd2FudCBzZXJ2ZXJzIHRvIGJlIGFibGUgdG8gcmVzcG9uZCB3
aXRoIGFwcGxpY2F0aW9uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRhdGEgYmFzZWQgb24gYXBw
bGljYXRpb24gZGF0YSBmcm9tIHRoZSBjbGllbnQgYW5kIGtub3cgdGhhdCB0aGF0IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPnRoYXQgZGF0YSB3YXMgbm90IHRydW5jYXRlZC48bzpwPjwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhbmtzLCB0
aGUga2V5d29yZCBvZiAmcXVvdDt0cnVuY2F0ZWQmcXVvdDsgY2F1c2VkIG1lIHRvIHVuZGVyc3Rh
bmQgdGhlIGludGVuZGVkIHBvaW50Ljxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBxdWVzdGlvbiBl
bmRzIHVwIHR5aW5nIGludG8gdGhlIG1vcmUgcGhpbG9zb3BoaWNhbCBvbmUgb2Ygd2hldGhlciBl
YXJseSBkYXRhIGFuZCAxLXJ0dCBkYXRhIGFyZSBjb25zaWRlcmVkICZxdW90O3NlcGFyYXRlIHN0
cmVhbXMmcXVvdDsgb3Igbm90IC0tIGlmIHRoZXkgYXJlIHNlcGFyYXRlIHN0cmVhbXMgd2l0aCBk
aXN0aW5jdCBlbmQvc3RhcnQsIHRoZW4gb2YgY291cnNlIG9uZSB3YW50cyB0byBkZXRlY3QgcG9z
c2libGUgdHJ1bmNhdGlvbg0KIGFzIGl0IGhhcHBlbnMuJm5ic3A7IEJ1dCwgaWYgdGhleSBhcmUg
Y29uY2VwdHVhbGx5IHRoZSBzYW1lIHN0cmVhbSBhbmQgdGhlIGJvdW5kYXJ5IGJldHdlZW4gdGhl
bSBpcyAmcXVvdDtqdXN0JnF1b3Q7IGEgYm9va2tlZXBpbmcgb3BlcmF0aW9uIG9mIGtleSBjaGFu
Z2UsIHRoZW4gdGhlcmUgaXMgbm8gbmVlZCB0byBiZSBjb25jZXJuZWQgYWJvdXQgZGV0ZWN0aW5n
IHRydW5jYXRpb247IHRoZSBhcHBsaWNhdGlvbiBqdXN0IGNvbnRpbnVlcyByZWFkaW5nIGluIGRh
dGEgYW5kDQogcmVwbHlpbmcgd2hlbiBjb21wbGV0ZSBhcHBsaWNhdGlvbiBwcm90b2NvbCByZXF1
ZXN0cyBhcmUgcmVjZWl2ZWQuPGJyPg0KPGJyPg0KLUJlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DB6PR8303MB00697808B11F2DB538106038ABF90DB6PR8303MB0069_--


From nobody Tue May 23 11:27:50 2017
Return-Path: 
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 A537312E042 for ; Tue, 23 May 2017 11:27:48 -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] 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 Y8LGxQmcrHzI for ; Tue, 23 May 2017 11:27:47 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AAE12E03E for ; Tue, 23 May 2017 11:27:46 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2ED647A32F1 for ; Tue, 23 May 2017 18:27:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Tue, 23 May 2017 14:27:45 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG 
Message-Id: <9112D389-2D1B-4966-90A1-0DD4756EFF31@dukhovni.org>
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org> 
To: TLS WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:27:49 -0000

> On May 23, 2017, at 2:07 PM, Colm MacC=C3=A1rthaigh =
 wrote:
>=20
> That's not good for users, and seems like another very strong reason =
to make it clear in the TLS draft that that it is not secure. FWIW; =
DNSCurve includes nonces to avoid attacks like this: =
https://dnscurve.org/replays.html (which means keeping state).

Actually, nonces in DNScurve protect clients from replayed server =
responses (clients
are stateful).  I see no explicit guidance to detect or refuse replays =
of client
queries in DNScurve.  While servers could keep a nonce cache, in =
practice there
are multiple servers and they don't share state (no "strike registers").

The replays discussed in the URL you provide are replays of stale, but =
still
within signature validity DNSSEC server responses.  Not replays of =
requests.

--=20
	Viktor.


From nobody Tue May 23 11:36:50 2017
Return-Path: 
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 9DF0112E04F for ; Tue, 23 May 2017 11:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=chromium.org
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 oO6QW-ZNW6Xc for ; Tue, 23 May 2017 11:36:45 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51A112E049 for ; Tue, 23 May 2017 11:36:45 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id 9so122555564pfj.1 for ; Tue, 23 May 2017 11:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/iClSoiWg+TCXPNhPsJbOAA7A2cXHaNghv+vIWl+sXU=; b=hsFyvupQwFiwxr1Kynb2kqA9wARueAs+Y8PIFmeulq9y3NzVDX64aW1G7h3tgRoqvx Ck1HGlLZdC5eurlgxNtQL0qfMtGYeeN0jh3gPQ27r6H6fcIrlt0/J6ejDZ6cApfKAFhP O7Bag71eD7FztEXSnuNMTmJiGBxamKoNE6NJY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/iClSoiWg+TCXPNhPsJbOAA7A2cXHaNghv+vIWl+sXU=; b=SAbo8nhOOwuJHq9Wu0Uei2PmxrtHB9kzaLOLCbrh2F5ctNTZw7YYmr3+fFs64lU2pC LR3qqOrRs/kawq45E/+rZqG1JaL6f02Damv/7PVq/pB6km43gCRIJs/w2ZMcZzjbTjVd hp4TNCFw0Ji/uzGyS6iXGLXyiLERT/L1l+Ak3z/xYJemN6P0hmeqxB47ZpC5xERCAI3B KXRFKgE1uq0kDRR0Xh/XS8N6q6u/sqGmZdGRWrABroM2XrE6AId+InvCJeBzueRWJdp3 zfTWW2LyvTglX2ACMD8BnWR2XCwg++dClbveXSGyw7enYXs/jnhCPANNAuSTuSmjcNlM 7Zjw==
X-Gm-Message-State: AODbwcCo3IkXY6EelpdCwEkLe3ya8ew+nqpDgCcUXIGvdqTT+JrozVO1 XYH2gWXGbLycjN/H+heRpPdqBhZDyIrHWd0=
X-Received: by 10.99.125.2 with SMTP id y2mr9541491pgc.10.1495564605286; Tue, 23 May 2017 11:36:45 -0700 (PDT)
MIME-Version: 1.0
References:  <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
In-Reply-To: <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
From: David Benjamin 
Date: Tue, 23 May 2017 18:36:33 +0000
Message-ID: 
To: Benjamin Kaduk , Markulf Kohlweiss , "tls@ietf.org" 
Cc: Antoine Delignat-Lavaud , Samin Ishtiaq ,  Britta Hale 
Content-Type: multipart/alternative; boundary="f403045db81009fd5805503545e7"
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:36:48 -0000

--f403045db81009fd5805503545e7
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk  wrote:

> My initial thoughts...
>
>
> On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
>
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also hope that it will clarify any remaining
> problems of understanding that I have on the issue.
>
> If we see EOED as a stream termination signal, then there seems
> to be a difference in performance for conservative servers that
> want to wait until receiving all 0RTT data before responding to
> the client's request in 0.5RTT communication.
>
> Said otherwise, we want servers to be able to respond with application
> data based on application data from the client and know that that
> that data was not truncated.
>
>
> Thanks, the keyword of "truncated" caused me to understand the intended
> point.
>
> I think this question ends up tying into the more philosophical one of
> whether early data and 1-rtt data are considered "separate streams" or not
> -- if they are separate streams with distinct end/start, then of course one
> wants to detect possible truncation as it happens.  But, if they are
> conceptually the same stream and the boundary between them is "just" a
> bookkeeping operation of key change, then there is no need to be concerned
> about detecting truncation; the application just continues reading in data
> and replying when complete application protocol requests are received.
>

Truncation detection is meaningful in both cases. We rely on KeyUpdate
being protected and tied to the immediately preceding record (by way of
sequence number). Otherwise an attacker could toss out chunks in the middle
of the stream immediately before a KeyUpdate.

David

--f403045db81009fd5805503545e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Tue, May 23=
, 2017 at 1:34 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:

 =20
   =20
 =20
  

    My initial thoughts...
<=
br>
    

    On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:

    

      
I am paraphrasing a long thread on the issue that we had within
the miTLS development team, and I am primarily commenting on the
analysis aspects. I also hope that it will clarify any remaining
problems of understanding that I have on the issue.

If we see EOED as a stream termination signal, then there seems
to be a difference in performance for conservative servers that
want to wait until receiving all 0RTT data before responding to
the client's request in 0.5RTT communication.

Said otherwise, we want servers to be able to respond with application=20
data based on application data from the client and know that that=20
that data was not truncated.


    

    

    Thanks, the keyword of "truncated" caused me to understand th=
e
    intended point.

    

    I think this question ends up tying into the more philosophical one
    of whether early data and 1-rtt data are considered "separate
    streams" or not -- if they are separate streams with distinct
    end/start, then of course one wants to detect possible truncation as
    it happens.=C2=A0 But, if they are conceptually the same stream and the
    boundary between them is "just" a bookkeeping operation of ke=
y
    change, then there is no need to be concerned about detecting
    truncation; the application just continues reading in data and
    replying when complete application protocol requests are received.
<=
/div>

Truncation detection is meaningful in both cases. We rely on K=
eyUpdate being protected and tied to the immediately preceding record (by w=
ay of sequence number). Otherwise an attacker could toss out chunks in the =
middle of the stream immediately before a KeyUpdate.

David


--f403045db81009fd5805503545e7--


From nobody Tue May 23 11:38:52 2017
Return-Path: 
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 2C70612DDD2 for ; Tue, 23 May 2017 11:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 liOHTw3H9Ps0 for ; Tue, 23 May 2017 11:38:49 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DB012940C for ; Tue, 23 May 2017 11:38:49 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id b68so78857930ywe.3 for ; Tue, 23 May 2017 11:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FAMujmr33fmyKkmz/t/zVghynI8/++eCyKUEtal8N+U=; b=ni2V33Za4XAoSThljlZmfy7G8xQbWG/97PTdhhgwpos+nYHOvTvUetv9s+S1YuRC9h x9Ow3gxHhKPP/Y7DwM+yzUgvKVSAODs/zJ0au+zZGpQnca7MR5kRjyEKWSelnkHTDWFZ NONYgLbSHyoLgyGJyLLpzYU8Voe8ElofEyDrvDF6SUAzynuj0Sc8XWV/NfVlqvrP4+Kl C9f74V1po4EFA7lDlxp83ZwwX7k5wSMAhG1JmzEsBQZUjaQ4ZwLx5obOy6+/g74bsh7X /5IO29wWzr3MlH4b+XvFilFtJNFfp43XJ0el8JS/WoR7Tdimu5LGqVk80LlZhCkeEUlP VC/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FAMujmr33fmyKkmz/t/zVghynI8/++eCyKUEtal8N+U=; b=q1CSf6XMWGuSiV3pL/90BgE8S7jZeN2HtJ8sORabsdJ2nc/zy5bgquJFBxKNTOOxul PpTZ2dy/kq2aWUtQRehzl9Usy3shgGj8elfFQwuSruQs5XjyqufX1lShm2txi/+52psH lwl2wr/QiKEtfcJicnCqwmRHQR5XWUTMW/dVnqF3eCgAnF0lxJAJVHXtO5ezBSpjuaQN kDmUTKmRQ2YNKDzraFpbR9Gxk/XFFZ4zBCly5rOKJXIyieoTzkR/RGEkV2LmR0a4K3hl STuzz7jDNLEnKHG3qHImkdwnOGp4vMb7jjtM3yxTirB4+fkVvbD5UCxLGqwxWghb+iUJ Qmjw==
X-Gm-Message-State: AODbwcAtFD35HZnlo//qYUQGuJo8aXG8ZUfFPFbFy3mHnRuL8f+rnock dR2v6Hj1HQxkwskzY+p6CgUcFLOyD7Y4MyQ=
X-Received: by 10.13.236.206 with SMTP id v197mr24076351ywe.296.1495564728570;  Tue, 23 May 2017 11:38:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Tue, 23 May 2017 11:38:47 -0700 (PDT)
In-Reply-To: <9112D389-2D1B-4966-90A1-0DD4756EFF31@dukhovni.org>
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org>  <9112D389-2D1B-4966-90A1-0DD4756EFF31@dukhovni.org>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Tue, 23 May 2017 11:38:47 -0700
Message-ID: 
To: TLS WG 
Content-Type: multipart/alternative; boundary="94eb2c0870f262bd8b0550354cff"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:38:51 -0000

--94eb2c0870f262bd8b0550354cff
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni 
wrote:

> Actually, nonces in DNScurve protect clients from replayed server
> responses (clients
> are stateful).  I see no explicit guidance to detect or refuse replays of
> client
> queries in DNScurve.  While servers could keep a nonce cache, in practice
> there
> are multiple servers and they don't share state (no "strike registers").
>

My apologies, you're right! I'll make sure to tease djb now. That's still
an insecure design (or at least a privacy defeating design) for the same
reasons as earlier. Though tinydns doesn't do RRL or Cyclic answers, so in
that coupled implementation it may be ok.

At one time we didn't think the kinds of side-channels present in TLS were
a big deal; the "it is not believed to be large enough to be exploitable" note
in section 6.2.3.2 of RFC5246 comes to mind. Here we risk repeating history.

-- 
Colm

--94eb2c0870f262bd8b0550354cff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni <=
;ietf-dane@dukh=
ovni.org> wrote:
Actually, nonces in DN=
Scurve protect clients from replayed server responses (clients

are stateful).=C2=A0 I see no explicit guidance to detect or refuse replays=
 of client

queries in DNScurve.=C2=A0 While servers could keep a nonce cache, in pract=
ice there

are multiple servers and they don't share state (no "strike regist=
ers").

My apologies, you're ri=
ght! I'll make sure to tease djb now. That's still an insecure desi=
gn (or at least a privacy defeating design) for the same reasons as earlier=
. Though tinydns doesn't do RRL or Cyclic answers, so in that coupled i=
mplementation it may be ok.=C2=A0

At one time we d=
idn't think the kinds of side-channels present in TLS were a big deal; =
the "i=
t is not believed to be large enough to be exploitable"=C2=A0no=
te in section 6.2.3.2 of RFC5246 comes to mind. Here we risk repeating hist=
ory.

-- 
Colm



--94eb2c0870f262bd8b0550354cff--


From nobody Tue May 23 11:44:59 2017
Return-Path: 
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 233B612E043 for ; Tue, 23 May 2017 11:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 TPpa-HKiyfiY for ; Tue, 23 May 2017 11:44:56 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B9112D574 for ; Tue, 23 May 2017 11:44:56 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NIarpK021790; Tue, 23 May 2017 19:44:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=s+OiJ5nKszslK2NA87sFOp/FI9uJKD7ko8bInbTkS/4=; b=I6/XZp3OH76BzknjWlgOyC/E6a4d/+5bWoTDcmXmdBrFQmdEhSbbm4gUmkte88XotjWP z4UCDAkk48UC3h3PBKZFVAwwlhovqFw2ilgPEjzdflqyGOmOBuWq0k5qeXHToIwn5cPZ DnP/5L4MkTjkqX8luBufq4atQUMLWcxOT/jeVd5CD7qdHG/nBdOJ1JxT48/nvUT7fTgs fxZNnJFUIld7OTj2VU8zQVFid7Mam/50Nk9VkWISaRZn0MVbtNSVqM1Fe/ibdbl1AS+4 H/pD2bHt5TQQ4CWhVU6H9Z9zZUPoqF7feJLHBZRKJLuKS+3kO4KJAerbLn7s+1tlN7l0 lw== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2amf6j48ry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 19:44:54 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NIaDK7031819; Tue, 23 May 2017 14:44:53 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ajh4v65dy-1; Tue, 23 May 2017 14:44:53 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 69CCF20061; Tue, 23 May 2017 12:44:52 -0600 (MDT)
To: David Benjamin , Markulf Kohlweiss , "tls@ietf.org" 
Cc: Antoine Delignat-Lavaud , Samin Ishtiaq , Britta Hale 
References:  <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com> 
From: Benjamin Kaduk 
Message-ID: 
Date: Tue, 23 May 2017 13:44:51 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------08539753F61B5185E24D6539"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230094
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230094
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:44:58 -0000

This is a multi-part message in MIME format.
--------------08539753F61B5185E24D6539
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/23/2017 01:36 PM, David Benjamin wrote:
> On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk  > wrote:
>
>
>     I think this question ends up tying into the more philosophical
>     one of whether early data and 1-rtt data are considered "separate
>     streams" or not -- if they are separate streams with distinct
>     end/start, then of course one wants to detect possible truncation
>     as it happens.  But, if they are conceptually the same stream and
>     the boundary between them is "just" a bookkeeping operation of key
>     change, then there is no need to be concerned about detecting
>     truncation; the application just continues reading in data and
>     replying when complete application protocol requests are received.
>
>
> Truncation detection is meaningful in both cases. We rely on KeyUpdate
> being protected and tied to the immediately preceding record (by way
> of sequence number). Otherwise an attacker could toss out chunks in
> the middle of the stream immediately before a KeyUpdate.
>

Right, but that's also provided for all TLS records by the same
mechanism.  The counterproposal here seems to be for the server
application to consider all the 0-RTT data as a coherent chunk and
provide a single reply to the self-contained application message
contained therein.  That is, it would not expect an application message
to span the 0-RTT/1-RTT boundary.

-Ben

--------------08539753F61B5185E24D6539
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/23/2017 01:36 PM, David Benjamin wrote:

    

      
      

        

          
On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk
            <bkaduk@akamai.com> wrote:

          

          


            
 I think this question
              ends up tying into the more philosophical one of whether
              early data and 1-rtt data are considered "separate
              streams" or not -- if they are separate streams with
              distinct end/start, then of course one wants to detect
              possible truncation as it happens.  But, if they are
              conceptually the same stream and the boundary between them
              is "just" a bookkeeping operation of key change, then
              there is no need to be concerned about detecting
              truncation; the application just continues reading in data
              and replying when complete application protocol requests
              are received.

            

          

          


          

        

        

          

            
Truncation detection is meaningful in both cases. We
              rely on KeyUpdate being protected and tied to the
              immediately preceding record (by way of sequence number).
              Otherwise an attacker could toss out chunks in the middle
              of the stream immediately before a KeyUpdate.

          

        

        

      

    

    

    Right, but that's also provided for all TLS records by the same
    mechanism.  The counterproposal here seems to be for the server
    application to consider all the 0-RTT data as a coherent chunk and
    provide a single reply to the self-contained application message
    contained therein.  That is, it would not expect an application
    message to span the 0-RTT/1-RTT boundary.

    

    -Ben

  


--------------08539753F61B5185E24D6539--


From nobody Tue May 23 11:48:33 2017
Return-Path: 
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 57491126DEE for ; Tue, 23 May 2017 11:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 QZVtzDiBmxnO for ; Tue, 23 May 2017 11:48:30 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5B7126B7F for ; Tue, 23 May 2017 11:48:30 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NIlim9011434; Tue, 23 May 2017 19:48:28 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=CaKqDD3JHUzdnVb0Zt2JS6y0p8VN7vzOJVahUrFLz8w=; b=H7Xzko+1ZTt2TIrN8+y/3qGG23zCIUDeoI3eC15LSsi2r2S6kLKIMyJoiGRToVjOujsB HsJnqFG2TtDK7M29aRZw1WZtcbnPw/a6nV47Gdeh19fLlzO0RCRtEUJUZM6na1gHK1Ur V1SVcU54Rel9jHZHFXvEYnaUHkKAgKaZ8SE3ohggYXN60TwCDmy38vffgT17MZtw48Ma 9zwzvktOrWMTOOxIOt37KpHlnCRDqE47/BeL5PPkam28dV9J2Px5R1lugQoukPW9aYxH QaYtfAT32R2dkEajc3x13y2v1hScYZO32GzTwJIMu5yC+3pww0irpRxhipmeKJEgGAD7 3w== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2amg7fv30k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 19:48:28 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NIaQuV016126; Tue, 23 May 2017 14:48:27 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ajh4ve4d0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 14:48:27 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 14:48:26 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 23 May 2017 14:48:26 -0400
From: "Salz, Rich" 
To: Markulf Kohlweiss , "Kaduk, Ben" , "tls@ietf.org" 
CC: Antoine Delignat-Lavaud , Samin Ishtiaq , Britta Hale 
Thread-Topic: [TLS] Comments on EndOfEarlyData
Thread-Index: AdLTtEU8p75Loa4ER0+xBa7xoDxY0QAWB9gAAAF/2wAAB1Pg0A==
Date: Tue, 23 May 2017 18:48:25 +0000
Message-ID: 
References:  <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230094
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230095
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 18:48:31 -0000

PiBHaXZlbiB0aGF0IDAtUlRUIGFuZCAxLVJUVCBndWFyYW50ZWVzIGFyZSB2ZXJ5IGRpZmZlcmVu
dCwgaXQgc2VlbSBpbXBvcnRhbnQgdG8gZGlzdGluZ3Vpc2ggdGhlIHR3byBzdHJlYW1zIGFuZCBt
b2RlbCB0aGVtIHNlcGFyYXRlbHkuDQoNCkNvb2w7IGlzIFNDaGFubmVsIGdvaW5nIHRvIGRvIHRo
YXQ/DQoNCk9wZW5TU0wgZG9lcy4NCg==


From nobody Tue May 23 12:21:57 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA2E12EA96; Tue, 23 May 2017 12:21:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Joseph Salowey ,  tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com>
Date: Tue, 23 May 2017 12:21:48 -0700
Archived-At: 
Subject: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 23 May 2017 19:21:48 -0000

Adam Roach has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with EKR's discuss -- specifying semantics for these ciphersuites
with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
which servers are encouraged to infer 1.2 support even in the absence of
explicit indication) is a bit baffling.

Given the scope this document covers, I recommend adding "1.2" to the
title of the document. (e.g.: "ECDHE_PSK with AES-GCM and AES-CCM Cipher
Suites for Transport Layer Security Version 1.2 (TLS 1.2)")



From nobody Tue May 23 12:22:37 2017
Return-Path: 
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 E6AD712EAAA for ; Tue, 23 May 2017 12:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 INx3n1e4ouhK for ; Tue, 23 May 2017 12:22:35 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D5512EAA6 for ; Tue, 23 May 2017 12:22:34 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NJH6x5021544; Tue, 23 May 2017 20:22:31 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=JyFXG3CjxU13eewe9MbgYa02bPqpzdrqNoOaGrvfKEc=; b=OoJJ+4SmiNqDxOHvOgZ4YH3xWVOwS9di9FAK4mYyaImePZihcP9dzpIXYD4EpmeP0zj3 gE97reiRzU7+ksgzstPdUPgu5NXUWNpu5dxajlSK18y3R3lfPO8ix32FecIPiFeyDpl8 7NJnOKORqJe1xfUUKvw0IF+QCakV6hSkFIcZ1xzL+bHr5dMgXiEWQuPavuaOHUrWU/M8 hEMmeNUKsoY8tjowoZ00uwtyZMhShN05xUbivVP6sM9w1C4kWeGmp6A3VESbfiwQtzq+ EAIluPW6xKuDdaMB/68Dff3v6vD23bvcvKdPt5rnjqQIGhmGHEbkyUb8vQ1O1b9VCYRH eQ== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2amtyk02pe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 20:22:30 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NJLUcd000442; Tue, 23 May 2017 15:22:30 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ajh4uswb6-1; Tue, 23 May 2017 15:22:30 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B35EA1FC73; Tue, 23 May 2017 19:22:29 +0000 (GMT)
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , TLS WG 
References:  <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org> 
From: Benjamin Kaduk 
Message-ID: 
Date: Tue, 23 May 2017 14:22:29 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------AA2573D6DC1541079F27D2DE"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230098
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230098
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:22:36 -0000

This is a multi-part message in MIME format.
--------------AA2573D6DC1541079F27D2DE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 05/23/2017 01:07 PM, Colm MacCárthaigh wrote:
>
> I've seen a number of arguments here that essentially boil down to
> "We'd like to keep it anyway, because it is so operationally
> convenient". Is that really how this process works? Don't demonstrable
> real-world attacks deserve deference?

The process is more like "once the participants have gotten used to an
idea, it takes some time to digest countervailing reasoning when
potentially subtle issues are involved".  Without yet taking a position
myself, it seems like at least some folks are coming around to see your
position, and the dialogue should continue.

-Ben

--------------AA2573D6DC1541079F27D2DE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/23/2017 01:07 PM, Colm MacCárthaigh wrote:

    

      


      

      
I've seen a number of arguments here that essentially boil
        down to "We'd like to keep it anyway, because it is so
        operationally convenient". Is that really how this process
        works? Don't demonstrable real-world attacks deserve deference?

    

    

    The process is more like "once the participants have gotten used to
    an idea, it takes some time to digest countervailing reasoning when
    potentially subtle issues are involved".  Without yet taking a
    position myself, it seems like at least some folks are coming around
    to see your position, and the dialogue should continue.

    

    -Ben

  


--------------AA2573D6DC1541079F27D2DE--


From nobody Tue May 23 12:33:04 2017
Return-Path: 
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 5965412EAB3 for ; Tue, 23 May 2017 12:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 btnB4c1_rzRn for ; Tue, 23 May 2017 12:33:00 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD2612EAC2 for ; Tue, 23 May 2017 12:33:00 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NJRR5F031402; Tue, 23 May 2017 20:32:57 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=rtj4rVv1l2SYBT2vxgd3fMPC5Hn7AsFSioZ6fJU4VKo=; b=d/YAFkBWWIiOOuw6bGt/7pBRvnnLnmF6Vtr/jZavG843fmZW060TMhPlzQ07Q1NzCs+a QXs/xvfSP42DyJ9iPE4VeXh3+ZuT83tqxJwpEckt7OkEMYybt4U3TS4JiaWQlJDpSdxV f69e7MLWgEobbs9Azc3W4wFOLJT+dC2dcoPsFCYIoM/uAopfpG7PhW5luBHPK5HZ957E WAHfZ6hqxaN1cYWexrgUzz0wI75lHez1oRdeAD6fT4TM6umECL7IxqPrE7yDWdu1fNyR tNSVxGRjJtT6eNJmusRNJCW9kLj7CeOu3lwm30aBdNIxEGFWbByyh5mjr6VpF4l28P0k Jw== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2amtyk04bd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 20:32:56 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NJVsZm007231; Tue, 23 May 2017 15:32:55 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ajh4usx60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 15:32:55 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 15:32:55 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 23 May 2017 15:32:55 -0400
From: "Salz, Rich" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , TLS WG 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NICDv1l4S8FUWU9Zh5nPuktKHj1e4AgAAB3wCAAABtgIABK3KAgBME8ICAA79FgIAAdzaAgAEhiwCAAmQwAIAAPdqAgAD23oCAAANTgIAABkmAgAACr4CAAI2ogIAACFIAgADqp4CAABAuAIAABLWA///UHHA=
Date: Tue, 23 May 2017 19:32:54 +0000
Message-ID: <8ae0e20c58494e0cb7e48d70dc42a9c4@usma1ex-dag1mb1.msg.corp.akamai.com>
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230099
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230099
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:33:03 -0000

PkkndmUgc2VlbiBhIG51bWJlciBvZiBhcmd1bWVudHMgaGVyZSB0aGF0IGVzc2VudGlhbGx5IGJv
aWwgZG93biB0byAiV2UnZCBsaWtlIHRvIGtlZXAgaXQgYW55d2F5LCBiZWNhdXNlIGl0IGlzIHNv
IG9wZXJhdGlvbmFsbHkgY29udmVuaWVudCIuIElzIHRoYXQgcmVhbGx5IGhvdyB0aGlzIHByb2Nl
c3Mgd29ya3M/IERvbid0IGRlbW9uc3RyYWJsZSByZWFsLXdvcmxkIGF0dGFja3MgZGVzZXJ2ZSBk
ZWZlcmVuY2U/DQoNCldlbGwgaXQncyBhIGxpdHRsZSBtb3JlIHN1YnRsZSB0aGVuIHRoYXQ7IGZv
bGtzIHNlZW0gdG8gYWNrbm93bGVkZ2UgdGhlIGF0dGFja3MgYnV0IGZlZWwgdGhhdCB0aGVpciB1
c2UtY2FzZXMgd29uJ3QgYmUgYWZmZWN0ZWQuICBJJ20gbG9va2luZyBhdCB5b3UsIENocm9tZSwg
Ym9yaW5nLCBGaXJlZm94IDopDQoNCkRvbid0IGdldCBkaXNjb3VyYWdlZC4gDQo=


From nobody Tue May 23 12:35:03 2017
Return-Path: 
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 7130C12EA8C; Tue, 23 May 2017 12:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level: 
X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 FzGkzYRHfVYc; Tue, 23 May 2017 12:34:56 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0380D12EAB1; Tue, 23 May 2017 12:34:56 -0700 (PDT)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wXQht4dS6z26hC; Tue, 23 May 2017 21:34:54 +0200 (CEST)
X-purgate-ID: 152705::1495568094-0000521C-AB7F7FC5/0/0
X-purgate-size: 1374
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3wXQhs6CGwz2y8X; Tue, 23 May 2017 21:34:53 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CF9761A6A6; Tue, 23 May 2017 21:34:53 +0200 (CEST)
In-Reply-To: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com>
To: Adam Roach 
Date: Tue, 23 May 2017 21:34:53 +0200 (CEST)
CC: The IESG , tls@ietf.org, tls-chairs@ietf.org,  draft-ietf-tls-ecdhe-psk-aead@ietf.org
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:34:57 -0000

Adam Roach wrote:
> draft-ietf-tls-ecdhe-psk-aead-04: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with EKR's discuss -- specifying semantics for these ciphersuites
> with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
> which servers are encouraged to infer 1.2 support even in the absence of
> explicit indication) is a bit baffling.

It encourages (but does not require) servers to infer 1.2 support
from _very_explicit_ information: the offering of TLSv1.2-only TLS
ciphersuites is the very same TLS ClientHello handshake message.

We know since rfc5746 that the most reliable scheme to indicate support
for certain TLS protocol features is a cipher suite value.  It is far
from rocket science to infer support for 1.2 from 1.2-only cipher
suite codepoints in ClientHello.cipher_suites.



I just realized that I suggested removal of a description of client
behaviour that can, and should remain in the document (I'm sorry):

                    A client MUST treat the selection of these cipher
  suites in combination with a version of TLS that does not support
  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
  'illegal_parameter' TLS alert.


-Martin


From nobody Tue May 23 12:40:21 2017
Return-Path: 
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 E25FD12EA95 for ; Tue, 23 May 2017 12:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 qc2M4UsPAe7H for ; Tue, 23 May 2017 12:40:18 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB17129B60 for ; Tue, 23 May 2017 12:40:18 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id e127so44029796wmg.1 for ; Tue, 23 May 2017 12:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=FLHu4IzJBckQjzTAhbVZFS5y+v6YVO2sZUfian1LTNg=; b=QMAIZVOcnnVq6c4tIfYmMYO7idGJskIc/dibac5zBlhbZy96uAoDKEVXTYhVGIFoo/ hluX0zQfxgtEYAOObusUWojHGiOft+EV4plTVKcE6RCulDYU9cr3keYeiUu4OyE8ZXs4 mxSiP4EIQ+szn+9ADs+B2MGkRTvDaYSVOHxTQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FLHu4IzJBckQjzTAhbVZFS5y+v6YVO2sZUfian1LTNg=; b=cu2pkzCZjONEt97Eq8u/k0iJLiMzSM2I9/hVPVzEpDDg4Kc7T6Gk/Myvj8ujszqZrr AuEDvFxhpgxXSYspmOb6CB1Fq9UB8WAcTM2RPmcgd4Mde0krflh0BC7bSd/EhVdWmNvF uJ2q3IYUXCMLkHp34Uy6+Naf3uLjmUf0cmbm/reo9+muOnMgXAoOkIhbet35vTiKNDoB nE89E62B1XAr2+EtdmAqEWjWDgpRtX/jfwr3MicuIyUYMqoB7wCV8QXqfPv5LGpPfXQw UWsbQ6aGL7IgX8JhiuOKQAAnrUsLQ9pKdm8YNGVJHLj6MLFPQ6C7CP+pOvyuVo6e5SaX 90cQ==
X-Gm-Message-State: AODbwcDYgsumDZGdUPkfuOzaIEv2YRWFkKpkmUlePvn5fchyOduMdZjT dihS5F2vOUB+zf8Of74I+pAdz2YRu8K6bYM=
X-Received: by 10.28.156.197 with SMTP id f188mr3579280wme.76.1495568416588; Tue, 23 May 2017 12:40:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.152.148 with HTTP; Tue, 23 May 2017 12:40:16 -0700 (PDT)
From: Watson Ladd 
Date: Tue, 23 May 2017 12:40:16 -0700
Message-ID: 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a114b316835635d0550362810"
Archived-At: 
Subject: [TLS] Comments on draft-ietf-tls-exported-authenticator-00
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:40:20 -0000

--001a114b316835635d0550362810
Content-Type: text/plain; charset="UTF-8"

Dear all,

I don't think this design needs to be as complex as it is. Why isn't
signing a party-dependent (server or client) exporter with the key of the
certificate, and then appending the certificate chain, enough? I am fairly
certain this gets the properties we need.  Further, the language around
jointly authoritative remains very opaque to me.

My other (much more minor) comment is that exporters labels should start
with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do
it.

Sincerely,
Watson Ladd

--001a114b316835635d0550362810
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear all,

I don't think this design needs=
 to be as complex as it is. Why isn't signing a party-dependent (server=
 or client) exporter with the key of the certificate, and then appending th=
e certificate chain, enough? I am fairly certain this gets the properties w=
e need.=C2=A0 Further, the language around jointly authoritative remains ve=
ry opaque to me.

My other (much more minor) commen=
t is that exporters labels should start with "EXPORTER" in RFC 57=
05, and I don't see why this draft shouldn't do it.=C2=A0

Sincerely,
Watson Ladd


--001a114b316835635d0550362810--


From nobody Tue May 23 13:01:07 2017
Return-Path: 
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 EC24912EA95 for ; Tue, 23 May 2017 13:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 O13MLFuDeAb0 for ; Tue, 23 May 2017 13:01:02 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76EE12EAA8 for ; Tue, 23 May 2017 13:01:02 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NJpZtM022813; Tue, 23 May 2017 21:01:00 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MOO6wkoYZ4P76qZ8yn+/5ict/IwiW2oN6UbNLkJpDnI=; b=R0nzbtq1p+sL3b7BWUyojTUeNzshf2zVLf3PkSqgEHqaTKBCCPemej7kkmpvM1IThper Bkx1U2cX75sILMEgUqq8E2V8JN+cZPnG7V2PIjGP9FY3Tzz2MqXZLBhsi4ugDcRVkCNx S3P+oYr4C2ADCiXx28a2iU87jF/+YKXhRtu2C1vncmRLI+tSJdGhvNd7ndticzFTkcT5 CkDoDaXINVUeCPJNDPGWHPvL5ELLiylnQOXz4/sHKSgF1fWikOuyLHQT1UUR4Pd4zj0e n5aXiRF1eCYNfOm6vwsAB8XvvlXQQrMmKj/hec73knulMww5fsNiHkzjnQmX4cpZpUI9 Uw== 
Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2amtyk08cd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 21:01:00 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NJpLqT014667; Tue, 23 May 2017 16:00:59 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ajh4v1y3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 16:00:59 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 16:00:58 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 23 May 2017 16:00:58 -0400
From: "Salz, Rich" 
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , TLS WG 
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NICDv1l4S8FUWU9Zh5nPuktKHj1e4AgAAB3wCAAABtgIABK3KAgBME8ICAA79FgIAAdzaAgAEhiwCAAmQwAIAAPdqAgAD23oCAAANTgIAABkmAgAACr4CAAI2ogIAACFIAgADqp4CAABAuAIAABLWA///UHHCAAAfHMA==
Date: Tue, 23 May 2017 20:00:58 +0000
Message-ID: 
References:    <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>       <1c188f36-c197-20f7-48e4-5d75ac4a2211@akamai.com>  <55096b5d-dc74-fae4-57e3-83d4355d6050@huitema.net> <86A85A1E-A0A2-4692-ADB1-D5126E421B70@dukhovni.org>  <8ae0e20c58494e0cb7e48d70dc42a9c4@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <8ae0e20c58494e0cb7e48d70dc42a9c4@usma1ex-dag1mb1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230101
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230101
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 20:01:04 -0000

PiBXZWxsIGl0J3MgYSBsaXR0bGUgbW9yZSBzdWJ0bGUgdGhlbiB0aGF0OyBmb2xrcyBzZWVtIHRv
IGFja25vd2xlZGdlIHRoZSBhdHRhY2tzDQo+IGJ1dCBmZWVsIHRoYXQgdGhlaXIgdXNlLWNhc2Vz
IHdvbid0IGJlIGFmZmVjdGVkLiAgSSdtIGxvb2tpbmcgYXQgeW91LCBDaHJvbWUsDQo+IGJvcmlu
ZywgRmlyZWZveCA6KQ0KDQpJJ3ZlIGhlYXJkIGZyb20gdHdvIHBlb3BsZSB0aGF0IHRoZSAibG9v
a2luZyBhdCB5b3UiIHBocmFzZSB3YXMgbm90IHdlbGwtcmVjZWl2ZWQuICBJIGFwb2xvZ2l6ZSB0
byB0aGUgbGlzdCwgYW5kIHRob3NlIHdob3NlIGZlZWxpbmdzIEkgaHVydC4gIEkgbG9vayBmb3J3
YXJkIHRvIHNlZWluZyBtb3JlIGRldGFpbGVkIHJlc3BvbnNlcyB0byBDb2xtJ3MgcG9zdHMgc29v
bi4gDQoNCi0tICANClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJl
ciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNo
U2Fseg0KDQo=


From nobody Tue May 23 13:07:15 2017
Return-Path: 
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 0516712EAFA for ; Tue, 23 May 2017 13:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lriW1WGYDIyH for ; Tue, 23 May 2017 13:07:12 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB78412EAC4 for ; Tue, 23 May 2017 13:07:11 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id u10so85070098uaf.1 for ; Tue, 23 May 2017 13:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=spCIE85vSBkHOsJHerAlox1neYlZC9DcB2H4PB/9GsM=; b=e82NbcX3iyA26hPirSVMTw+0Yp2RFal5V3rniM64Aaup7voiUD/trdykvrtgHaB6b4 jpZBU6j/B+AXQTGwjVdR9K9jwG4wi/qMHlBu3pANo7F3bRkp6usXoaUMPrUzfIMgfzhR JTVJx2wOcPUdn38F3hCvF1STSE5Zx4Yib54OEvZzksSHnrvOFp0Q3qbhW0stv+5uzwPD zJSKmdYzxwroQqJIZpipKO9JCPHSjBSxSi398vFGM7/qqdW6SNmk6D/9EtAKNo6Ou053 IL25L9UrDKGaMcnnet3NCSSOGv/243SjeMFsfaApDrRQD5FGMiG0fHrayxYrBULyJWKp AeEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=spCIE85vSBkHOsJHerAlox1neYlZC9DcB2H4PB/9GsM=; b=gsB391il0c3nSOcQ7njrXbpIlC94NfiEsHM3Z/EfUXaTQ6AVMjB9y/I24gkXNziL0l D3umM6dNn4dTNSdH/tTSJvXbiRLx9dKyH9AR0REUvnFS1R1vqCmEFr4oRNrjSUHSiL8G z8Kb9eLhGOfLfxaJu2Fuks8dC6voukBqkC4dZvN61tEv5r/NcbAHNFdQQdp4sS0YGj7b E+ZjCnN/gQ/XZmHQFgWMWi51kS1xaASgwDKLvbYoBQItOmujVMaPFEg7uKf8G6GudsWz U38XcrnPSXQGgpfbZgyohx4ewSHktpttfPNhggfM9uAxUAaNBQxnu6PP4oggSu/oBV+P F20Q==
X-Gm-Message-State: AODbwcDRsmWBrOiV2+aFwwZYNNh5c0WHb+zn9r1FyVIKxmxtjJ4Xwswc aAfVmTPDxR3fB5p321k7JNwRL5OiQQ==
X-Received: by 10.176.7.198 with SMTP id d6mr15737066uaf.61.1495570030920; Tue, 23 May 2017 13:07:10 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Nick Sullivan 
Date: Tue, 23 May 2017 20:07:00 +0000
Message-ID: 
To: Watson Ladd , tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045f7fe86e0ae305503688ec"
Archived-At: 
Subject: Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 20:07:14 -0000

--f403045f7fe86e0ae305503688ec
Content-Type: text/plain; charset="UTF-8"

Hi Watson,

Some points that should help clarify your questions:
1) The certificate used in the construction is no the plain certificate
chain, it's the TLS 1.3 certificate message which could contain extensions.
2) The finished message is used to bind the certificate+certificateverify
to the connection state. It mirrors TLS 1.3 post-handshake authentication.
3) In TLS 1.3 post-handshake authentication, each successive certificate
added to the connection is incorporated into the handshake state. The last
certificate in a sequence of authentications would result in a connection
in which the party could say they were jointly authoritative a over
multiple identities. In exported authenticators, the only state that is
signed comes from the original handshake, so there's no way to order them.
Each exported authenticator is tied to the connection, but not tied
directly to another authenticator, and therefore there is no proof that the
party is "jointly authoritative". I welcome text changes to make this more
clear.
4) We can add the prefix in the next draft, thanks for the note.

On Tue, May 23, 2017 at 12:40 PM Watson Ladd  wrote:

> Dear all,
>
> I don't think this design needs to be as complex as it is. Why isn't
> signing a party-dependent (server or client) exporter with the key of the
> certificate, and then appending the certificate chain, enough? I am fairly
> certain this gets the properties we need.  Further, the language around
> jointly authoritative remains very opaque to me.
>
> My other (much more minor) comment is that exporters labels should start
> with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do
> it.
>
> Sincerely,
> Watson Ladd
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045f7fe86e0ae305503688ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Watson,

Some points th=
at should help clarify your questions:
1) The certificate used in =
the construction is no the plain certificate chain, it's the TLS 1.3 ce=
rtificate message which could contain extensions.
2) The finished =
message is used to bind the certificate+certificateverify to the connection=
 state. It mirrors TLS 1.3 post-handshake authentication.
3) =
In TLS 1.3 post-handshake authentication, each successive certificate added=
 to the connection is incorporated into the handshake state. The last certi=
ficate in a sequence of authentications would result in a connection in whi=
ch the party could say they were jointly authoritative a over multiple iden=
tities. In exported authenticators, the only state that is signed comes fro=
m the original handshake, so there's no way to order them. Each exporte=
d authenticator is tied to the connection, but not tied directly to another=
 authenticator, and therefore there is no proof that the party is "joi=
ntly authoritative". I welcome text changes to make this more clear.
4) We can add the prefix in the next draft, thanks for the note.

On Tue, May 23, 2017=
 at 12:40 PM Watson Ladd <watso=
n@cloudflare.com> wrote:
Dear all,

I don't think this design needs to=
 be as complex as it is. Why isn't signing a party-dependent (server or=
 client) exporter with the key of the certificate, and then appending the c=
ertificate chain, enough? I am fairly certain this gets the properties we n=
eed.=C2=A0 Further, the language around jointly authoritative remains very =
opaque to me.

My other (much more minor) comment i=
s that exporters labels should start with "EXPORTER" in RFC 5705,=
 and I don't see why this draft shouldn't do it.=C2=A0
Sincerely,
Watson Ladd

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--f403045f7fe86e0ae305503688ec--


From nobody Tue May 23 13:12:03 2017
Return-Path: 
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 E0F3C12EAB1 for ; Tue, 23 May 2017 13:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 BFDBL6F7xmEu for ; Tue, 23 May 2017 13:12:01 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB082126DEE for ; Tue, 23 May 2017 13:12:01 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NK1uIA026582; Tue, 23 May 2017 21:11:59 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=sppVDbxDzOsI9NLxggBD1TXk13UDuktfQ5DpqeNzpNo=; b=lDn78AvDBzzp26hv+PrxXRmo3WZyRdUVb3pA68GA8UMv0pHUBWYTb61WP07u7waqwCJ0 D637QmAfh0M0LyXdU08ambfmnBeCo9jumiZYSFD4J0/ZN+AwZd7Fkvb2Wg5Z1GqttC2I 49Ph2nc1clOyxbukms/ivjfhc7nNRWaAUFPNZnxnW9iIHioymF5uODe26yaVek0ewINn h2339Io5ieFqwRNXx/1irtip0DeKRd1GBzL4Xs5kEv8xiKBEMlepkuJtRts9bKx/fpJ3 Bk8FyCzX4zdbHIPLrLRnktnWfDPP2iu/Xw3mibhh7kYyUcMLmAq0lxkYmsCMG9wNkGu7 bQ== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2amg7fvk3t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 May 2017 21:11:59 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NKAofb032067; Tue, 23 May 2017 16:11:57 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ajh4ut1f7-1; Tue, 23 May 2017 16:11:57 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 4BD331FC72; Tue, 23 May 2017 20:11:57 +0000 (GMT)
To: Nick Sullivan , tls@ietf.org
References:  
From: Benjamin Kaduk 
Message-ID: <70b37362-d036-3a34-b616-58f4da10a384@akamai.com>
Date: Tue, 23 May 2017 15:11:56 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E356E0B7EC5CB1FB6EBB0724"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230103
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230102
Archived-At: 
Subject: Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 20:12:03 -0000

This is a multi-part message in MIME format.
--------------E356E0B7EC5CB1FB6EBB0724
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/23/2017 03:07 PM, Nick Sullivan wrote:
> 3) In TLS 1.3 post-handshake authentication, each successive
> certificate added to the connection is incorporated into the handshake
> state. The last certificate in a sequence of authentications would
> result in a connection in which the party could say they were jointly
> authoritative a over multiple identities. In exported authenticators,
> the only state that is signed comes from the original handshake, so
> there's no way to order them. Each exported authenticator is tied to
> the connection, but not tied directly to another authenticator, and
> therefore there is no proof that the party is "jointly authoritative".
> I welcome text changes to make this more clear.

I thought at least for "normal" post-handshake auth, the handshake hash
used was always just the initial handshake, and did not include
intermediate certificates that had been transmitted.

-Ben

--------------E356E0B7EC5CB1FB6EBB0724
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 05/23/2017 03:07 PM, Nick Sullivan wrote:

    
3)
      In TLS 1.3 post-handshake authentication, each successive
      certificate added to the connection is incorporated into the
      handshake state. The last certificate in a sequence of
      authentications would result in a connection in which the party
      could say they were jointly authoritative a over multiple
      identities. In exported authenticators, the only state that is
      signed comes from the original handshake, so there's no way to
      order them. Each exported authenticator is tied to the connection,
      but not tied directly to another authenticator, and therefore
      there is no proof that the party is "jointly authoritative". I
      welcome text changes to make this more clear.

    

    I thought at least for "normal" post-handshake auth, the handshake
    hash used was always just the initial handshake, and did not include
    intermediate certificates that had been transmitted.

    

    -Ben

  


--------------E356E0B7EC5CB1FB6EBB0724--


From nobody Tue May 23 13:25:54 2017
Return-Path: 
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 3D95E12EB17 for ; Tue, 23 May 2017 13:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=microsoft.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 vwJlKAk48Y-E for ; Tue, 23 May 2017 13:25:50 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0136.outbound.protection.outlook.com [104.47.37.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A64112EB13 for ; Tue, 23 May 2017 13:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fdwbZz1aD6gbr8LI/GKElDYK9oKR4R6vLE+sqdoVwW0=; b=ZCNrLf43koLB4++n43ZXsy32VzJc5tM/Oa1CXrrgrlw2W/4SkectQpHiP21XPCRb6N4DYODYqknont8M0wM6dfYgJgbCgSxTn95iFBdwOtO8kWGO+cHz2RjStcCyMZCc/ia4/vqTBcTvL2hsLXrg4abvlPfyPPYBrKEbJEiggJg=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0027.namprd21.prod.outlook.com (10.161.140.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.0; Tue, 23 May 2017 20:25:48 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2993:3849:f0fd:2a92]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2993:3849:f0fd:2a92%16]) with mapi id 15.01.1124.009; Tue, 23 May 2017 20:25:47 +0000
From: Andrei Popov 
To: "Salz, Rich" , Markulf Kohlweiss , "Kaduk, Ben" , "tls@ietf.org" 
CC: Antoine Delignat-Lavaud , Samin Ishtiaq , Britta Hale 
Thread-Topic: [TLS] Comments on EndOfEarlyData
Thread-Index: AdLTtEU8p75Loa4ER0+xBa7xoDxY0QANphQAAAFEp8AAAU4hgAADMD2g
Date: Tue, 23 May 2017 20:25:46 +0000
Message-ID: 
References:  <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:4::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0027; 7:uZfn6CM/bmein4yqFIQVI8im576yXwXhd01RTX/xhrDXCtPEEDoPqc6/P/1yavkrPTsJt9MQ4KIjorwAh6+XbfID2a7onPIJ/fr/Gkb6YpTYL22EmRvzSHfJVhpbmzvcGi+OWjV1NoniOtPsZLrFkWnqiMWaE8CHMpdUpce97JQvxwMsGyCZ/9w78ggiUHgpg+U48ugJ+LX1xJXjYoD5YGo7+fzo4T5e4yRalm8+ulSrO4lmC63UY99RELO0IUPf0oFmeRBaLWcIv9FxKAjKN+CF8MeXlT0MGvY9+649+l/Jxr6lcH6mboUb9WoWXSvlnmdeSNkZKkH80TVbPLMkEryEHCWbSehWKw9VcvlbNBI=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6029001)(6009001)(39450400003)(39400400002)(39410400002)(39850400002)(39860400002)(39840400002)(13464003)(377454003)(966005)(2900100001)(72206003)(4326008)(33656002)(38730400002)(55016002)(9686003)(5005710100001)(8990500004)(6306002)(1511001)(6246003)(54906002)(6436002)(25786009)(229853002)(10090500001)(53546009)(99286003)(53936002)(7696004)(3660700001)(81166006)(86362001)(575784001)(74316002)(5660300001)(2561002)(6506006)(189998001)(8676002)(86612001)(50986999)(2950100002)(2501003)(76176999)(3280700002)(10290500003)(2906002)(6116002)(305945005)(7736002)(478600001)(8936002)(5250100002)(54356999)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0027; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-traffictypediagnostic: DM2PR21MB0027:
x-ms-office365-filtering-correlation-id: 57fbea4f-41f1-4cd1-7f20-08d4a219e541
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:DM2PR21MB0027; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700043)(100105000095)(100000701043)(100105300095)(100000702043)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703043)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704043)(100105200095)(100000705043)(100105500095); SRVR:DM2PR21MB0027; BCL:0; PCL:0; RULEID:(100000800043)(100110000095)(100000801043)(100110300095)(100000802043)(100110100095)(100000803043)(100110400095)(100000804043)(100110200095)(100000805039)(100110500095); SRVR:DM2PR21MB0027; 
x-forefront-prvs: 0316567485
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 20:25:46.7895 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0027
Archived-At: 
Subject: Re: [TLS] Comments on EndOfEarlyData
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 20:25:52 -0000

Yes, it is my plan to make 0-RTT data opt-in only in the Windows TLS stack,=
 with a clear distinction in the API.
It is possible, however, that certain middleware components above the TLS s=
tack might choose to blur this distinction (which would be bad design, in m=
y opinion).

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich
Sent: Tuesday, May 23, 2017 11:48 AM
To: Markulf Kohlweiss ; Kaduk, Ben ; tls@ietf.org
Cc: Antoine Delignat-Lavaud ; Samin Ishtiaq ; Britta Hale 
Subject: Re: [TLS] Comments on EndOfEarlyData

> Given that 0-RTT and 1-RTT guarantees are very different, it seem importa=
nt to distinguish the two streams and model them separately.

Cool; is SChannel going to do that?

OpenSSL does.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf=
.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7CAndrei.Popov%40microsoft.c=
om%7Cdd3c1a8132a34d29c46908d4a20c5706%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C636311621300870812&sdata=3DMXINz0jr8SWWW9GWOt3Ayrojidu3RdiK%2FkBffE=
ZZ0Eo%3D&reserved=3D0


From nobody Tue May 23 13:58:08 2017
Return-Path: 
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 08817127B31 for ; Tue, 23 May 2017 13:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 9OFnpNWThWnY for ; Tue, 23 May 2017 13:57:58 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB112EB33 for ; Tue, 23 May 2017 13:57:57 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id p143so40991881yba.2 for ; Tue, 23 May 2017 13:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RSmxrL52Q4J+4Z/2S7eNjxrsfYWmI9PHQLoTW9QoOqM=; b=nazyEL/meHUV9ZcqOFUI+Zj3VHxdUqZkANA0ND5CQeyE8FbE7IVp4mkjrxwWNQ9TMM bXgqqGioWcwTc8yuFaSZH3LjMZXLseEC1diZAqcH8D/1BRFfqcBfT/hF5WA97GcNvR5n kbDIACHu5l3LpesnJNuy4B4t+f6/UDKtbugx87vLIE3QhEPxconHMoV027Hmk6NArWzA 9yM89voICsO/Uj/yI9/yY3p6NqKpc2wDL++uTSlY1dhlS3bP80AH3LbwMyPPrcNDlpkT SsXjGUecCpCMJOMIjryzrqijGrONL/PHQrpDK5cuzSFTs2Obgfi7zH8iUYk1zV4rDpIU kJ/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RSmxrL52Q4J+4Z/2S7eNjxrsfYWmI9PHQLoTW9QoOqM=; b=igGJko/wvhEqo6x5u4BXU+lrhIJW5Z8US+fy9YozYYyYtc5sMwP5ohRg6TGHHs8EK9 oCzJU2VjdLzATB9Yfhtlq98L7aKKGwYUEn4sednQZEP+vUULHxxJBPTf/jLKp1wX5tS8 W7sJ8NFEccGrPpUdNf64PHWIyrGi01OX6ww0laFrJaelUVYEh4lJi0Q0MCOG0/gCB8Ow Jqz6+jSzrR5c410vSva3eds2q8vU9Y70HTB62tRgdnrZsISuUtmFJTua5yb2UlFOm/rs JJUwny7a1CnetWOQWTCajlbRh+guHWElyzZMR1tdp9MpWdvPnhLCuRvrkCGLEloMwAdh 12JQ==
X-Gm-Message-State: AODbwcCsAw05vsro58k/GDTcV9JJYO5nahmAmoGIiCFy7ZUr1sxhODNQ RoeM5oKYlRkNd/D9F2BcrX7ar2uhCfJu
X-Received: by 10.37.206.8 with SMTP id x8mr19462239ybe.16.1495573076305; Tue, 23 May 2017 13:57:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 23 May 2017 13:57:15 -0700 (PDT)
In-Reply-To: <20170523133441.54A901A6A6@ld9781.wdf.sap.corp>
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com> <20170523133441.54A901A6A6@ld9781.wdf.sap.corp>
From: Eric Rescorla 
Date: Wed, 24 May 2017 04:57:15 +0800
Message-ID: 
To: "mrex@sap.com" 
Cc: The IESG , "tls@ietf.org" , tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c190b20f32bae0550373dbc"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 20:57:59 -0000

--94eb2c190b20f32bae0550373dbc
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 9:34 PM, Martin Rex  wrote:

> Eric Rescorla wrote:
> > draft-ietf-tls-ecdhe-psk-aead-04: Discuss
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The following text appears to have been added in -04
> >
> >    A server receiving a ClientHello and a client_version indicating
> >    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
> >    this document in ClientHello.cipher_suites can safely assume that
> > the
> >    client supports TLS 1.2 and is willing to use it.  The server MUST
> >    NOT negotiate these cipher suites with TLS protocol versions earlier
> >    than TLS 1.2.  Not requiring clients to indicate their support for
> >    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
> >    improves the interoperability in the installed base and use of TLS
> >    1.2 AEAD cipher suites without upsetting the installed base of
> >    version-intolerant TLS servers, results in more TLS handshakes
> >    succeeding and obviates fallback mechanisms.
> >
> > This is a major technical change from -03, which, AFAIK, prohibited
> > the server from negotiating these algorithms with TLS 1.1 and below
> > and maintained the usual TLS version 1.2 negotiation rules.
>
> This change _still_ prohibits the server from negotiating these algorithms
> with TLSv1.1 and below.



> Could you elaborate a little on where and why you see a problem with this?
>

For starters, TLS 1.3 has already designed a completely independent
mechanism for doing version negotiation outside of ClientHello.version,
so doing another seems pretty odd. In any case, it's not something you
do between IETF-LC and IESG approval.


As this changes tries to explain, had such a text been used for all
> TLSv1.2 AEAD cipher suite code points, then browsers would have never
> needed any "downgrade dance" fallbacks, POODLE would have never
> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
> would not been needed, either.
>

I'm not sure this is true, because there were also servers which did
not understand extensions.

-Ekr


> -Martin
>

--94eb2c190b20f32bae0550373dbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 23, 2017 at 9:34 PM, Martin Rex <mrex@sap.com> wr=
ote:
Eric Rescorla wrote:

> draft-ietf-tls-ecdhe-psk-aead-04: Discuss

>

> ------------------------------------------------------------=
----------

> DISCUSS:

> ------------------------------------------------------------=
----------

>

> The following text appears to have been added in -04

>

>=C2=A0 =C2=A0 A server receiving a ClientHello and a client_version ind=
icating

>=C2=A0 =C2=A0 (3,1) "TLS 1.0" or (3,2) "TLS 1.1" an=
d any of the cipher suites from

>=C2=A0 =C2=A0 this document in ClientHello.cipher_suites can safely ass=
ume that

> the

>=C2=A0 =C2=A0 client supports TLS 1.2 and is willing to use it.=C2=A0 T=
he server MUST

>=C2=A0 =C2=A0 NOT negotiate these cipher suites with TLS protocol versi=
ons earlier

>=C2=A0 =C2=A0 than TLS 1.2.=C2=A0 Not requiring clients to indicate the=
ir support for

>=C2=A0 =C2=A0 TLS 1.2 cipher suites exclusively through ClientHello.cli=
ent_hello

>=C2=A0 =C2=A0 improves the interoperability in the installed base and u=
se of TLS

>=C2=A0 =C2=A0 1.2 AEAD cipher suites without upsetting the installed ba=
se of

>=C2=A0 =C2=A0 version-intolerant TLS servers, results in more TLS hands=
hakes

>=C2=A0 =C2=A0 succeeding and obviates fallback mechanisms.

>

> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.



This change _still_ prohibits the server from negotiating these algo=
rithms

with TLSv1.1 and below.
=C2=A0

Could you elaborate a little on where and why you see a problem with this?<=
br>

For starters, TLS 1.3 has already desig=
ned a completely independent
mechanism for doing version negotiat=
ion outside of ClientHello.version,
so doing another seems pretty=
 odd. In any case, it's not something you
do between IETF-LC =
and IESG approval.



As this changes tries to explain, had such a text been used for all

TLSv1.2 AEAD cipher suite code points, then browsers would have never

needed any "downgrade dance" fallbacks, POODLE would have never
existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid

would not been needed, either.

I'm =
not sure this is true, because there were also servers which did
=
not understand extensions.

-Ekr




-Martin





--94eb2c190b20f32bae0550373dbc--


From nobody Tue May 23 14:06:49 2017
Return-Path: 
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 38A8E12EB30 for ; Tue, 23 May 2017 14:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oQMEA52Facns for ; Tue, 23 May 2017 14:06:47 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15F21289B0 for ; Tue, 23 May 2017 14:06:46 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id e28so86011763uah.0 for ; Tue, 23 May 2017 14:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=8iT+cVkHlOGAyhwyzY/eqNJ63YLTwjTC0K8iAVAovVM=; b=QrQlJUHEMkQbLE6lwvtpa4ulmBlEJx05RWAsBgaQRphQx0b75NvlUur7LMbDIQu/cS SGLCXMXRHyV3iEx2LZbEhjI0QLvVFPh3Ou4vXIX1vFM5J6TmVoPPDMsWOpCAa6iD5/OY rsqvrkDK0TlPhqbaHTrHYdYKG3+sdb8CoCROkA/7gAi0Ui66wS46j/Ppqg8Dk67AUku9 kqQIQDzVNhv8qEiuOVpxvnwQYhicYHV4pv2HiH4bPDp7bE8iSRiuGSbwvZh1ZpPSH/yG dwWwPNuHbA4vUr2M5TRyqcFqtxOfcQ9DVGFApDWBZyjsvZ0cDpG/yg0uvdsLb+R+oV3q sYLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8iT+cVkHlOGAyhwyzY/eqNJ63YLTwjTC0K8iAVAovVM=; b=qKxRamHE1YRQhoE3LPKRnJcFbM6Ofqa9cKbvXIlEvrH/PzJYyFbP1diGxJD2ee8QWC yHqW/2bk5TZaSnnGah4KEE6ShOEtQxEHMEhx8s/8B7I/NqUjaJXsI2HC0dgFGHuOBYIh ZepfJXIRy3DpknydHX5lqNFPLf0aR3MdHeJ46qZNRdoEhRIH6j1bM3EFvdDwa8w3LNBW wgGGiz27y2ZKN9gH6L1w75BEvfSEDaek9MtBrLdIaFMq8vVOB+a8XsygW5Mfv03Emouz 8KVR/Y1nwe2dJGScJ1LU7fxmwtyxPMEyzkN0lraXBynz3fuqjNzSB5eqf1vbLpNjfIfD L4FQ==
X-Gm-Message-State: AODbwcAluqir2w7XOTGm9Y2ego71Ts74phQRZgQOGK2gj3D16T5dv/dp nXU/rBFzlhdnHCIANQzNkdys3P0M/w==
X-Received: by 10.159.52.214 with SMTP id b22mr15781720uac.93.1495573605853; Tue, 23 May 2017 14:06:45 -0700 (PDT)
MIME-Version: 1.0
References:   <70b37362-d036-3a34-b616-58f4da10a384@akamai.com>
In-Reply-To: <70b37362-d036-3a34-b616-58f4da10a384@akamai.com>
From: Nick Sullivan 
Date: Tue, 23 May 2017 21:06:35 +0000
Message-ID: 
To: Benjamin Kaduk , tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045e7976832f300550375dc3"
Archived-At: 
Subject: Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 21:06:48 -0000

--f403045e7976832f300550375dc3
Content-Type: text/plain; charset="UTF-8"

Ben,

Thanks for pointing that out, you are right. A client is jointly
authoritative if there was in-handshake client auth followed by a
post-handshake client auth. Subsequent client authentications can be
computed in any order and are disambiguated by the context id.

Nick

On Tue, May 23, 2017 at 1:12 PM Benjamin Kaduk  wrote:

> On 05/23/2017 03:07 PM, Nick Sullivan wrote:
>
> 3) In TLS 1.3 post-handshake authentication, each successive certificate
> added to the connection is incorporated into the handshake state. The last
> certificate in a sequence of authentications would result in a connection
> in which the party could say they were jointly authoritative a over
> multiple identities. In exported authenticators, the only state that is
> signed comes from the original handshake, so there's no way to order them.
> Each exported authenticator is tied to the connection, but not tied
> directly to another authenticator, and therefore there is no proof that the
> party is "jointly authoritative". I welcome text changes to make this more
> clear.
>
>
> I thought at least for "normal" post-handshake auth, the handshake hash
> used was always just the initial handshake, and did not include
> intermediate certificates that had been transmitted.
>
> -Ben
>

--f403045e7976832f300550375dc3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ben,

Thanks for pointing that out, =
you are right. A client is jointly authoritative if there was in-handshake =
client auth followed by a post-handshake client auth. Subsequent client aut=
hentications can be computed in any order and are disambiguated by the cont=
ext id.

Nick

On Tue, May 23, 2017 at 1:12 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:

    On 05/23/2017 03:07 PM, Nick Sullivan wrote:

    
3)
      In TLS 1.3 post-handshake authentication, each successive
      certificate added to the connection is incorporated into the
      handshake state. The last certificate in a sequence of
      authentications would result in a connection in which the party
      could say they were jointly authoritative a over multiple
      identities. In exported authenticators, the only state that is
      signed comes from the original handshake, so there's no way to
      order them. Each exported authenticator is tied to the connection,
      but not tied directly to another authenticator, and therefore
      there is no proof that the party is "jointly authoritative"=
. I
      welcome text changes to make this more clear.

    

    I thought at least for "normal" post-handshake auth, the hand=
shake
    hash used was always just the initial handshake, and did not include
    intermediate certificates that had been transmitted.

    

    -Ben

  





--f403045e7976832f300550375dc3--


From nobody Tue May 23 15:00:58 2017
Return-Path: 
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 29C22128CDB; Tue, 23 May 2017 15:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5s3CUuSmqHPH; Tue, 23 May 2017 15:00:53 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6C41250B8; Tue, 23 May 2017 15:00:53 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id a5so44057612lfh.2; Tue, 23 May 2017 15:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uOUC0gWCwTkCJ7fxgi3SWGFbI31Ig4wbFSiJkrqZfUY=; b=qP5UrwGOIq7sGWPVRjArH5EzaOx/hYObzp0C15Y5FIhO87i4mkwzzVYK+YeV9NzC1f MMUY6UN8JTHn1XwOf7Vd85Uadg4KlXPKKpOAVJKQL/RLTaXLWWsaGHKRUwFdGyrGFXF+ PG+5r3XWpHevTEnkdvdTJJLWKQ1d/3UIzjGd4+X8ZysjTdpZHWcCi9T96yukcGp5C6lS 0JSVKVtptgRbB5HuEDKMgOAIuLevTRLbA185BEmDbckMQWg/awdG5vsEh1SxnhP4t/7a mRELEhoWoD7XQVeWkaTvrvPd1Ry7Ry/SfzHEqspNwfhLLV3WLq2ruQ9WvaK2wdnYkHWn 7ABA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uOUC0gWCwTkCJ7fxgi3SWGFbI31Ig4wbFSiJkrqZfUY=; b=QbmJBPvfsfgVxFivzhRvlhiTGMGfsnWHUFBYvRp4VjL68B+lxaJgtSyr6NzgXWT7NF ccdpyFroS95I264Lp+uGhSefR2xYvG9iDCRr1L/6TN9LCb3eI9rQc4bYKOG8JsE6gSln 8/NVAujjpu1DOwiMXs2jleUVOg/gVR+TVLh5kYzkkrBP0apYo/puMZsB635pxB3ggAlU 1mEJ4bVNOf2Z0jk1c25W0BJnpslb2GPtM+U6NAXKBMdn15TzPgXiwzVkAS3JWm4apOn6 3qG9yDo1Onaj/EKheXfr8Xo3KVzHKmpjfsBHsZug8aoRTaP79EnNWQvUH11yTIp79XJQ TQoQ==
X-Gm-Message-State: AODbwcCVzjAKDEwoBhVHPrJkmoicI0QxvMoIdWO5yRU0JyRgIFjrSof5 zXwxYvVgeNcCJJiwOxBe/YxvxDvaLw==
X-Received: by 10.25.80.79 with SMTP id z15mr7456613lfj.142.1495576851429; Tue, 23 May 2017 15:00:51 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 15:00:50 -0700 (PDT)
In-Reply-To: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>
From: Daniel Migault 
Date: Tue, 23 May 2017 18:00:50 -0400
X-Google-Sender-Auth: dy0yvpY3NSAux0DrVAQQrpTSz3s
Message-ID: 
To: Eric Rescorla 
Cc: The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org,  Joseph Salowey , tls-chairs , tls 
Content-Type: multipart/alternative; boundary="94eb2c1cb0b0f6bc0c0550381e6b"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 22:00:57 -0000

--94eb2c1cb0b0f6bc0c0550381e6b
Content-Type: text/plain; charset="UTF-8"

Hi Eric,

Thank you for your reviews. Please see my responses inline. If you agree
with the text I will update the draft.

Yours,
Daniel

On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The following text appears to have been added in -04
>
>    A server receiving a ClientHello and a client_version indicating
>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>    this document in ClientHello.cipher_suites can safely assume that
> the
>    client supports TLS 1.2 and is willing to use it.  The server MUST
>    NOT negotiate these cipher suites with TLS protocol versions earlier
>    than TLS 1.2.  Not requiring clients to indicate their support for
>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>    improves the interoperability in the installed base and use of TLS
>    1.2 AEAD cipher suites without upsetting the installed base of
>    version-intolerant TLS servers, results in more TLS handshakes
>    succeeding and obviates fallback mechanisms.
>
> This is a major technical change from -03, which, AFAIK, prohibited
> the server from negotiating these algorithms with TLS 1.1 and below
> and maintained the usual TLS version 1.2 negotiation rules.
>
> This is a very material technical change. I don't consider it wise,
> but in any case it would absolutely need WG consensus, which I
> don't believe that it has given the recent introduction.
>

I agree that the text is a technical change, and that it may not be
appropriated to do so now. The reason I included it was that it was conform
to the previous text, but I agree that implicit assumption of version 1.2
may need some additional discussion especially regarding RFC5246 Appendix
E. Unless you prefer further discussion I assume the text below address
your concern.

The cipher suites defined in this document MUST NOT be negotiated for
any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
these cipher suites with a (D)TLS version that differs from TLS 1.2.
Servers MUST NOT select one of these cipher suites with a TLS version that
differs from TLS 1.2. A client MUST treat the selection of these cipher
suites in combination with a version of TLS as an error and generate a
fatal 'illegal_parameter' TLS alert. 

>
> The discussion of dictionary attacks here seems inferior to that
> in 4279. In particular, you only need to actively attack one
> connection to capture the data you need for a brute force attack
> despite the text there referring to trying "different keys".
> Please correct that.
>
> I believe the text below address your concern:

OLD:
Use of Pre-Shared Keys of limited entropy may allow an active
attacker attempts to connect to the server and try different keys.
For example, limited entropy may be provided by using a short PSK in which
case an attacker may perform a brute-force attack. Another example
includes the use of a PSK  chosen by a human which thus may be exposed to
dictionary attacks.

NEW:
Pre-Shared Keys security relies on its associated entropy, and it is
RECOMMENDED to follow  to ensure the PSK has enough
entropy. Possible reasons for low entropy includes PSK chosen by humans or
PSK of small length as well as using random generators with limited
entropy. 

PSK of limited entropy may allow an attacker to test different PSK
values against a valid output such as master secret or any output derived
from it. In this document, the master secret is generated using the PSK as
well as the ECDHE shared secret. The use of ECDHE limits the possibilities
of passive eavesdropping attackers, as the ECDHE shared secret is not
expected to be derived from the observed ECDH parameters. As a result,
passive eavesdropping is unlikely to happen, and the collection of all
necessary material relies on an active attack.
An active attacker may collect the necessary material by setting a TLS
session as a client with the legitimate server. One PSK is tested for each
session, and a match occurs when key exchange succeeds. On the other hand,
an active attacker may also consider gathering the necessary information
for offline computation. One way consists in getting a legitimate client to
establish a connection with the attacker. It is also assumed that the
client will accept the ECDH parameters authenticated by the attacker's
private key and finally returns the Finished message authenticating the
exchange. The attacker will be then in possession of all the necessary
information to perform a brute force attack.


>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The citations to TLS 1.3 still seem pretty muddled. I think you
> should just stop referencing and discussing 1.3.
>

My understanding of your comment is that mentioning TLS 1.3 to further
insisting that the code point are not valid for TLS 1.3 is confusing. I
propose to:

Explicitly mention the TLS version in the title:

OLD title:
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
Security (TLS)

NEW title:
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
Security (TLS)

OLD Introduction:

    The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246 ] protocol,
version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347
], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13
].

NEW introduction

The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246 ] protocol,
version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347 ].


I suggest to keep the following text of the introduction:


AEAD algorithms that combine encryption and integrity protection are
   strongly recommended for (D)TLS [RFC7525
] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13
].
The AEAD
   algorithms considered in this document are AES-GCM and AES-CCM.  The
   use of AES-GCM in TLS is defined in [RFC5288
] and the use of AES-CCM
   is defined in [RFC6655 ].


I suggest to keep the following text of the Applicable versions sections,
as I believe the section discusses the cipher suites against all existing
TLS versions. In addition, it also justifies somewhat that we only defined
cipher suites that are compatible with TLS1.3.

   TLS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-tls13
]
Section 1.2 .
TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

I suggest to remove the reference to TLS1.3 in the security considerations

OLD

 The security considerations in TLS 1.2 [RFC5246
], DTLS 1.2 [RFC6347
],
   TLS 1.3 [I-D.ietf-tls-tls13
],
ECDHE_PSK [RFC5489 ], AES-GCM
[RFC5288 ],
   and AES-CCM [RFC6655 ] apply
to this document as well.

NEW

 The security considerations in TLS 1.2 [RFC5246
], DTLS 1.2 [RFC6347
],
 ECDHE_PSK [RFC5489 ], AES-GCM
[RFC5288 ],and AES-CCM [RFC6655
] apply
 to this document as well.


> S 2.
> I'm not sure that the discussion of the PRF is helpful here in
> mandating the non-use of these cipher suites with TLS 1.1 and
> below.
>

I find the text useful as it gives an idea why even introducing AEAD in TLS
version lower than 1.2 is a bad idea, so I would prefer to keep it. The
text has been changed to

OLD:
As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.

NEW:
As such,  all ECDHE_PSK
ciphers, including those defined outside this document, SHOULD NOT be
negotiated in TLS versions prior to 1.2.

--94eb2c1cb0b0f6bc0c0550381e6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eric, 

Thank you for your r=
eviews. Please see my responses inline. If you agree with the text I will u=
pdate the draft.

Yours, 
Daniel

On Mon, May 22,=
 2017 at 10:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the fo=
llowing ballot position for

draft-ietf-tls-ecdhe-psk-aead-04: Discuss



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/s=
tatement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc=
/draft-ietf-tls-ecdhe-psk-aead/







-----------------------------------------------------------------=
-----

DISCUSS:

-----------------------------------------------------------------=
-----



The following text appears to have been added in -04



=C2=A0 =C2=A0A server receiving a ClientHello and a client_version indicati=
ng

=C2=A0 =C2=A0(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any=
 of the cipher suites from

=C2=A0 =C2=A0this document in ClientHello.cipher_suites can safely assume t=
hat

the

=C2=A0 =C2=A0client supports TLS 1.2 and is willing to use it.=C2=A0 The se=
rver MUST

=C2=A0 =C2=A0NOT negotiate these cipher suites with TLS protocol versions e=
arlier

=C2=A0 =C2=A0than TLS 1.2.=C2=A0 Not requiring clients to indicate their su=
pport for

=C2=A0 =C2=A0TLS 1.2 cipher suites exclusively through ClientHello.client_h=
ello

=C2=A0 =C2=A0improves the interoperability in the installed base and use of=
 TLS

=C2=A0 =C2=A01.2 AEAD cipher suites without upsetting the installed base of=


=C2=A0 =C2=A0version-intolerant TLS servers, results in more TLS handshakes=


=C2=A0 =C2=A0succeeding and obviates fallback mechanisms.



This is a major technical change from -03, which, AFAIK, prohibited

the server from negotiating these algorithms with TLS 1.1 and below

and maintained the usual TLS version 1.2 negotiation rules.



This is a very material technical change. I don't consider it wise,

but in any case it would absolutely need WG consensus, which I

don't believe that it has given the recent introduction.

I agree that the text is a technical change, and that=
 it may not be appropriated to do so now. The reason I included it was that=
 it was conform to the previous text, but I agree that implicit assumption =
of version 1.2 may need some additional discussion especially regarding RFC=
5246 Appendix E. Unless you prefer further discussion I assume the text bel=
ow address your concern. =C2=A0 

<t>The cipher suites defined =
in this document MUST NOT be negotiated for any version of (D)TLS other tha=
n TLS 1.2. Clients MUST NOT offer one of these cipher suites with a (D)TLS =
version that differs from TLS 1.2. Servers MUST NOT select one of these cip=
her suites with a TLS version that differs from TLS 1.2. A client MUST trea=
t the selection of these cipher suites in combination with a version of TLS=
 as an error and generate a fatal 'illegal_parameter' TLS alert. &l=
t;/t> 



The discussion of dictionary attacks here seems inferior to that

in 4279. In particular, you only need to actively attack one

connection to capture the data you need for a brute force attack

despite the text there referring to trying "different keys".

Please correct that.


I believe the text below address your concern:
OLD:
<t>Use of Pre-Shared Keys of limited entropy may allow an ac=
tive
attacker attempts to connect to the server and try different keys.<=
br>For example, limited entropy may be provided by using a short PSK in whi=
ch
case an attacker may perform a brute-force attack. Another exampleincludes the use of a PSK=C2=A0 chosen by a human which thus may be expose=
d to
dictionary attacks.</t>

NEW:
<t>Pre-Shared Ke=
ys security relies on its associated entropy, and it is RECOMMENDED to foll=
ow <xref target=3D"4086"/> to ensure the PSK has enough ent=
ropy. Possible reasons for low entropy includes PSK chosen by humans or PSK=
 of small length as well as using random generators with limited entropy. &=
lt;/t>

<t>PSK of limited entropy may allow an attacker to t=
est different PSK values against a valid output such as master secret or an=
y output derived from it. In this document, the master secret is generated =
using the PSK as well as the ECDHE shared secret. The use of ECDHE limits t=
he possibilities of passive eavesdropping attackers, as the ECDHE shared se=
cret is not expected to be derived from the observed ECDH parameters. As a =
result, passive eavesdropping is unlikely to happen, and the collection of =
all necessary material relies on an active attack. 
An active attacker m=
ay collect the necessary material by setting a TLS session as a client with=
 the legitimate server. One PSK is tested for each session, and a match occ=
urs when key exchange succeeds. On the other hand, an active attacker may a=
lso consider gathering the necessary information for offline computation. O=
ne way consists in getting a legitimate client to establish a connection wi=
th the attacker. It is also assumed that the client will accept the ECDH pa=
rameters authenticated by the attacker's private key and finally return=
s the Finished message authenticating the exchange. The attacker will be th=
en in possession of all the necessary information to perform a brute force =
attack.</t>=C2=A0=C2=A0 
=C2=A0 



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



The citations to TLS 1.3 still seem pretty muddled. I think you

should just stop referencing and discussing 1.3.

<=
/div>
My understanding of your comment is that mentioning TLS 1.3 to fu=
rther insisting that the code point are not valid for TLS 1.3 is confusing.=
 I propose to:

Explicitly mention the TLS version in the =
title:

OLD title:
ECDHE_PSK with AES-GCM and AES-CCM C=
ipher Suites for Transport Layer Security (TLS)

NEW title=
:
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer S=
ecurity (TLS)
OLD=
 Introduction:
    Th=
e cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13].
NE=
W introduction

Th=
e cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347]. 


I suggest to keep the following text=
 of the introduction:

AEAD algorithms that combine encryption and integrity=
 protection are
   strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.=
ietf-tls-tls13].  The AEAD
   algorithms considered in this document are AES-GCM and AES-CCM.  The
   use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
   is defined in [RFC6655].


I suggest to keep the following text of the Applicable=
 versions sections, as I believe the section discusses the cipher suites ag=
ainst all existing TLS versions. In addition, it also justifies somewhat th=
at we only defined cipher suites that are compatible with TLS1.3.=C2=A0 
   TLS version 1.3 and =
later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-t=
ls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.
I suggest to re=
move the reference to TLS1.3 in the security considerations

OL=
D
 The security consi=
derations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
   TLS 1.3 [I-D.ietf-tls-tls13],=
 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],
   and AES-CCM [RFC6655] apply to this document as well.

NEW 
<=
pre class=3D"m_-6500030207053047939gmail-newpage"> The security considerati=
ons in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and=
 AES-CCM [RFC6655] apply 
 to this document as well.



S 2.

I'm not sure that the discussion of the PRF is helpful here in

mandating the non-use of these cipher suites with TLS 1.1 and

below.

I find the text useful as it giv=
es an idea why even introducing AEAD in TLS version lower than 1.2 is a bad=
 idea, so I would prefer to keep it. The text has been changed to 

<=
/div>
OLD:
As such TLS 1.0 and TLS 1.1 should not be used with ECDHE=
_PSK.

NEW:
As such,=C2=A0 all ECDHE_PSK
cip=
hers, including those defined outside this document, SHOULD NOT be
negot=
iated in TLS versions prior to 1.2.


--94eb2c1cb0b0f6bc0c0550381e6b--


From nobody Tue May 23 15:04:20 2017
Return-Path: 
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 681E4129B52; Tue, 23 May 2017 15:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jKjOw08IiKLH; Tue, 23 May 2017 15:04:17 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926BD1292F5; Tue, 23 May 2017 15:04:17 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id a5so44094574lfh.2; Tue, 23 May 2017 15:04:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uhTkRNgSR90a9FXfZxPXac0z87nmVS0GoPtaH3JsMHI=; b=fsWTu0Z5KCF47i+EeMtNLukrCbSZcq1BN+PkDGSq/qK+Dd/wX8bvHDIcZIMeIJk3iK DNPdaijBERWtu2QQnUzJHa2kKLhACGv9RLpCGG6eSLYYd9XUJHvYHBkIobEiXIJKa1vH MGn4FakapMjonMaN1lVvFj/TigyTuiMwGAAbz3CAeOQ+bHLmlb6WUO8i3jOr8UpqZfVM RuNZei73W9dziHI9uPK7kzGgIBx7+yhEN3/BqSibVOv6wiDHKU+aP/QCHqS31RHPZgZa /y8nd8+chyZsdwXYFguRZZipOOQMrYKHJdJZjEufc0cPF8hJJR9pfx+5o9cJqgB8gCR/ 0Tlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uhTkRNgSR90a9FXfZxPXac0z87nmVS0GoPtaH3JsMHI=; b=Tkx62OgR9x2sAiEAuUXZnw2237Emf1qLYq0YXAFPFN+X0o/bayBmSkL98EL9qlsK1K YbQqhzcBqc8B0K5aGvDHhdYv/wB+VLC5iyUqT1C7x/9hCWQtrbqmZ/bRGXqeOtJiYV6n AeFgBHtxz+BmFOI7QgY6+j8liQ4TphStdJIf3ztNSyZKgQ/wUgeGDMJhdw6LpMFI+Cp6 dmPbl+PmS4LhqHk0nx/2ZWepmyIYfpZyyZgkPDU18nbQHeSGu4i6HVB81dgkCVr3uA5I y7CkNnEZFPl2NI8iZNwqah25PYQSyR4zX+IDdXWKX5xwdnCKfviesNaC/uTK7jQ1P1OS v2+A==
X-Gm-Message-State: AODbwcBDNaAULl2B7U9EJVzyKpGYrv0a4lDXS1dzX75DOjv0mtBHQU3m wWFGczINwRdcE7gtg0Ne/2zF8sI9OQ==
X-Received: by 10.25.229.69 with SMTP id c66mr9821919lfh.102.1495577055946; Tue, 23 May 2017 15:04:15 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 15:04:15 -0700 (PDT)
In-Reply-To: <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp>
References: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com> <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp>
From: Daniel Migault 
Date: Tue, 23 May 2017 18:04:15 -0400
X-Google-Sender-Auth: RVs_6WbKdlhZLypCp37aChtnKxs
Message-ID: 
To: mrex@sap.com
Cc: Adam Roach , The IESG , tls , tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="001a113c0cb2276f480550382b54"
Archived-At: 
Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 22:04:19 -0000

--001a113c0cb2276f480550382b54
Content-Type: text/plain; charset="UTF-8"

Hi,

So I have propose a fall back to the latest version. However, if we agree
this is a better approach, I am fine adding it to the document.

Yours,
Daniel

On Tue, May 23, 2017 at 3:34 PM, Martin Rex  wrote:

> Adam Roach wrote:
> > draft-ietf-tls-ecdhe-psk-aead-04: No Objection
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I agree with EKR's discuss -- specifying semantics for these ciphersuites
> > with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in
> > which servers are encouraged to infer 1.2 support even in the absence of
> > explicit indication) is a bit baffling.
>
> It encourages (but does not require) servers to infer 1.2 support
> from _very_explicit_ information: the offering of TLSv1.2-only TLS
> ciphersuites is the very same TLS ClientHello handshake message.
>
> We know since rfc5746 that the most reliable scheme to indicate support
> for certain TLS protocol features is a cipher suite value.  It is far
> from rocket science to infer support for 1.2 from 1.2-only cipher
> suite codepoints in ClientHello.cipher_suites.
>
>
>
> I just realized that I suggested removal of a description of client
> behaviour that can, and should remain in the document (I'm sorry):
>
>                     A client MUST treat the selection of these cipher
>   suites in combination with a version of TLS that does not support
>   AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
>   'illegal_parameter' TLS alert.
>
>
> -Martin
>

--001a113c0cb2276f480550382b54
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, 

So I have propose a fall =
back to the latest version. However, if we agree this is a better approach,=
 I am fine adding it to the document. 

Yours,
Daniel<=
br>

On Tue, =
May 23, 2017 at 3:34 PM, Martin Rex <mrex@sap.com> wrote:
Adam Roach wrote:

> draft-ietf-tls-ecdhe-psk-aead-04: No Objection

>

> ------------------------------------------------------------=
----------

> COMMENT:

> ------------------------------------------------------------=
----------

>

> I agree with EKR's discuss -- specifying semantics for these ciphe=
rsuites

> with TLS 1.0 and 1.1 is a material change, and the proposed mechanism =
(in

> which servers are encouraged to infer 1.2 support even in the absence =
of

> explicit indication) is a bit baffling.



It encourages (but does not require) servers to infer 1.2 support
from _very_explicit_ information: the offering of TLSv1.2-only TLS

ciphersuites is the very same TLS ClientHello handshake message.



We know since rfc5746 that the most reliable scheme to indicate support

for certain TLS protocol features is a cipher suite value.=C2=A0 It is far<=
br>
from rocket science to infer support for 1.2 from 1.2-only cipher

suite codepoints in ClientHello.cipher_suites.







I just realized that I suggested removal of a description of client

behaviour that can, and should remain in the document (I'm sorry):



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A cli=
ent MUST treat the selection of these cipher

=C2=A0 suites in combination with a version of TLS that does not support
=C2=A0 AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal

=C2=A0 'illegal_parameter' TLS alert.





-Martin





--001a113c0cb2276f480550382b54--


From nobody Tue May 23 15:05:20 2017
Return-Path: 
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 65C7512EB49; Tue, 23 May 2017 15:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qjov76PGlap3; Tue, 23 May 2017 15:04:58 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012C912EB25; Tue, 23 May 2017 15:04:57 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id h4so57645961lfj.3; Tue, 23 May 2017 15:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BcPuDhO1pMmWTz00D2DzmDeckG9yrIFP/RDyuvcpmwU=; b=hk37aTM1gMC9xmHLiM2X1NRjMy1scZR1bHf9D5zFEV6SSSrE+w394A8e9X3OMh3E0I F8KVMl0nGPzN7DnpeXbI7O6hPd9wXgIZBEp81TIkns/d6qsaKrEIXrYgige0mCjFz0CO sqChPjKGzfeU3JxSgdIEJEmKvxjPzxSLWnHaZCqDD6V5IkqsWZqPoRXK4iBbPXNASHco GGbKW20PvPF+UscI92OK4D8SxqNpi08d2wdF74E8SIPFfozWvMuMKo4HTvBhFVQOsvEe WCQxZ2fxGFxW/82Cgv7Pq+/RBsA3JpRHZQYa2QYpeUm7A5m/zLfGgDagmcVLnUg+UvpA tZqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BcPuDhO1pMmWTz00D2DzmDeckG9yrIFP/RDyuvcpmwU=; b=f3QU4YUL9/a0DaBKhu02KBpWiXCtZAyLS0QH5uiHZMxaay2jrYDFFokepXRN8rf/1R ML1LromVNGH6R/x8hCX5AZl09yxleiTbVIaHhJ2KAD9p6fTM5ctIoRDeCJREBFg8A6qU PZvjbuGKk8dXp+r4uCVQWUUPKRrExd57u1LTjd6KgHKr3CCUS03s+SW/WdVFG7XDHxZj vfJrBWvUQS2jt7GxKFwK5AfMjUOfRQGvc9sd6a7R38+ZOncrZERXAK+swduIkkNbsfrZ Xec2bXgusWTe1X7Ykbq4ZsghsANsZBOoXeIJYCzwUCSWNWAZzkbuRkHNO5JfRgYhF3F4 LVng==
X-Gm-Message-State: AODbwcD9LVtd4OZAxukI0lQNvXLiZx4SSscX+jJIEnI3FrijXuwtI8jA fsiChjAnmE12J36oeGaa99Ep1Rbecg==
X-Received: by 10.46.81.17 with SMTP id f17mr8864653ljb.96.1495577096361; Tue, 23 May 2017 15:04:56 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 15:04:55 -0700 (PDT)
In-Reply-To: <20170522173534.GT39245@kduck.kaduk.org>
References: <20170519043827.GL39245@kduck.kaduk.org>  <20170519162725.GM39245@kduck.kaduk.org>  <20170522173534.GT39245@kduck.kaduk.org>
From: Daniel Migault 
Date: Tue, 23 May 2017 18:04:55 -0400
X-Google-Sender-Auth: mo_QA4jOMmlD5y2_qXqm4vGR1-M
Message-ID: 
To: Benjamin Kaduk 
Cc: tls , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org,  "ietf@ietf.org" , The IESG , secdir@ietf.org
Content-Type: multipart/alternative; boundary="f403045ff93c901dac0550382d46"
Archived-At: 
Subject: Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 22:04:59 -0000

--f403045ff93c901dac0550382d46
Content-Type: text/plain; charset="UTF-8"

Thank you for the clarifying text. I have added it on my local copy.
Yours,
Daniel

On Mon, May 22, 2017 at 1:35 PM, Benjamin Kaduk  wrote:

> Sorry for the slow reply.
>
> On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> > Thank you,
> >
> > Your comments have all been addressed. I have one remaining
> clarification.
> > In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and
> not
> > only for the cipher suites of the draft. In your opinion do we clarify
> > this, and should we use something else than SHOULD NOT ?
>
> It's somewhat awkward, as what we really want to do is Update RFC
> 5489 to add this prohibition there.  But, that's more process to
> jump through and this document is already at a late stage, so I do
> not actually propose doing that.  I would be okay saying
>
>   As such, all ECDHE_PSK ciphers, including those defined outside
>   this document, SHOULD NOT be negotiated in TLS versions prior to
>   1.2.
>
> to match up with the MUST NOT text we have for these new ciphers.
> (Taking into account Martin's text that the prohibition is on
> negotiating them, but offering them in a ClientHello that also
> offers the old version is okay.)
>
> -Ben
>

--f403045ff93c901dac0550382d46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you for the clarifying text. I have added =
it on my local copy. 
Yours, 
Daniel

On Mon, May 22, 2017 at 1:3=
5 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Sorry for the slow reply.



On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:

> Thank you,

>

> Your comments have all been addressed. I have one remaining clarificat=
ion.

> In my text the SHOULD NOT was intended to the ECDHE_PSK in general, an=
d not

> only for the cipher suites of the draft. In your opinion do we clarify=


> this, and should we use something else than SHOULD NOT ?



It's somewhat awkward, as what we really want to do is Update RF=
C

5489 to add this prohibition there.=C2=A0 But, that's more process to
jump through and this document is already at a late stage, so I do

not actually propose doing that.=C2=A0 I would be okay saying



=C2=A0 As such, all ECDHE_PSK ciphers, including those defined outside

=C2=A0 this document, SHOULD NOT be negotiated in TLS versions prior to

=C2=A0 1.2.



to match up with the MUST NOT text we have for these new ciphers.

(Taking into account Martin's text that the prohibition is on

negotiating them, but offering them in a ClientHello that also

offers the old version is okay.)



-Ben





--f403045ff93c901dac0550382d46--


From nobody Tue May 23 15:12:50 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2B8128B93; Tue, 23 May 2017 15:12:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Joseph Salowey ,  tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149557756331.28529.11248340972147793467.idtracker@ietfa.amsl.com>
Date: Tue, 23 May 2017 15:12:43 -0700
Archived-At: 
Subject: [TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 23 May 2017 22:12:43 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ekr's DISCUSS position.



From nobody Tue May 23 16:15:45 2017
Return-Path: 
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 1B2761287A5 for ; Tue, 23 May 2017 16:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 k9YuVLZVEuxJ for ; Tue, 23 May 2017 16:15:42 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB362127867 for ; Tue, 23 May 2017 16:15:42 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4NNDDSM020370; Wed, 24 May 2017 00:15:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=ENzEyH08lHuwpgRBNn98zpibxGAUHojEWHLWZjdBNXo=; b=UP0ivAl6eI2hWgE/C2m78WdpgE42P0v4viaYsfsH/2MYYIdFVjPGfIsPK+miF8vGTuGP mysmRUIoOgXs+tUU4TVTz4sep76TzG3Z8NVAKaE/PM3tr5WTZRuBEi0ZaT9z8CiIjnwX 8v0c+yz0yVuKABmNPxpPo36NvDoBaU+aqXv4WVxqq67/Eo9o6yRTJdQDGsMOTtb04xSd i0LXn4AlwBxBqUsMFsb6ipSGurT9MmBw3ssJJWc9GZA+PiP+T2A4ELJ3Zp1AsDGueou3 fEIphyChAjJlSU6uHJf3pn6ELYGfEnMLlcRKoW023V3D/mEf8soHmmLE8UO2UYYS9Ssg Kg== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2amtyk15e2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 May 2017 00:15:38 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4NN684u007294; Tue, 23 May 2017 19:15:38 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ajh4vekkx-1; Tue, 23 May 2017 19:15:38 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 981C580052; Tue, 23 May 2017 17:15:37 -0600 (MDT)
To: Ilari Liusvaara , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= 
Cc: "tls@ietf.org" 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520093347.GB32428@LK-Perkele-V2.elisa-laajakaista.fi>
From: Benjamin Kaduk 
Message-ID: 
Date: Tue, 23 May 2017 18:15:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <20170520093347.GB32428@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------6E663C954183D60E2BE03587"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230117
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-23_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705230118
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 23:15:44 -0000

This is a multi-part message in MIME format.
--------------6E663C954183D60E2BE03587
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05/20/2017 04:33 AM, Ilari Liusvaara wrote:
>
> I meant what prevents the (say 10 second) windows from stacking up into
> (say 20 second windows) if 0-RTT is used on multiple hops (client-
> middlebox and middlebox-server)?
>
> One can not assume that the client has knowledge of any middlebox on
> the path (e.g. CDNs in HTTP are in general invisible to the client).
>

I think the attacker has to delay sending the client's 0-RTT to the
middlebox for the 10-second window if it wants to get the 20-second
delay overall (assuming the middlebox does at-most-once properly), at
which point the client would have a sense that something fishy might be
going on.  Though, that still doesn't give the client a hard bound on
the delay, I suppose.

-Ben

--------------6E663C954183D60E2BE03587
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/20/2017 04:33 AM, Ilari Liusvaara wrote:

    


      
I meant what prevents the (say 10 second) windows from stacking up into
(say 20 second windows) if 0-RTT is used on multiple hops (client-
middlebox and middlebox-server)?

One can not assume that the client has knowledge of any middlebox on
the path (e.g. CDNs in HTTP are in general invisible to the client).



    

    

    I think the attacker has to delay sending the client's 0-RTT to the
    middlebox for the 10-second window if it wants to get the 20-second
    delay overall (assuming the middlebox does at-most-once properly),
    at which point the client would have a sense that something fishy
    might be going on.  Though, that still doesn't give the client a
    hard bound on the delay, I suppose.

    

    -Ben

  


--------------6E663C954183D60E2BE03587--


From nobody Tue May 23 16:41:19 2017
Return-Path: 
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 4AF53120724 for ; Tue, 23 May 2017 16:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 tORhdIpjkbXy for ; Tue, 23 May 2017 16:41:08 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E10128616 for ; Tue, 23 May 2017 16:41:07 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l74so82015175ywe.2 for ; Tue, 23 May 2017 16:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UeyMvDHrDVXz7Y64VZ4RDIzRv5cU2mq5PzpamncNZOU=; b=02zzkFWwx0r6zTxm5zIXw8WmjZOpQr6wS7P68ZTHsoI7svPSzj94ttMR6yyC9RGsM3 nreul3cSlMfMnDH/RGtjx29leY4Ef1kc0VI5JHJ+FHEfJu/vqXzItvMvCldhpHFhURaM v9llIz7noaDSOqWCXEY7Mj3RzL11XaSLAmKrXrlCZz9SEsamPYpR5OjCeXyPdYN+NHso yvc6Z6JmqJrm3eJ9psHvEU04SoVP6g5emSxUzQ+Hv1P4sJaNawerTUpOMy/o2MM4utfF nEb/lE/6eqz7pLFQHHDyEabgRTTP74rC3hh4aHIcYuyQ+C3w7EEr/YrbS5WGf4GRzIU6 n/dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UeyMvDHrDVXz7Y64VZ4RDIzRv5cU2mq5PzpamncNZOU=; b=AEKAKk5HaVivMCiQlmO/b7u8FnslwGVxOwRRy4R6BfD6QZelID3m8gye7BGSeAcine dMV1ti8VT2PeD6sxVrw7r7I01IRu6ZpWFBwwySf+jXKRcR9GXMPvMadn/8or8S1OfqVo 5xBFZfFoxMx0+JdXCU1GSYePOOhVZ6ae3BMCQ4Bij9E0pd8DyR5tKQUxUC0SgJmFps6i yRNHIrwmAE+OgpYuFM8ldGnnMpEoMnE12ZJHm8NUNteT+nqLiXQZ6N7z5KD1aW2ZMfrg JMQCXd/0CqcTiPvUfq9AwTLGtgJRoG2rGQnNNZomC+6ETEQPAU70MzvlrSX+pcrSmnec 9X4Q==
X-Gm-Message-State: AODbwcBsbetPBTwvbtmRDkProPdbkkk/U9eMDN02Q7FQmq0Pf8U9adfX DSI0sf+kmuOi1iFcrkC0+xdC7Ocf7O8q
X-Received: by 10.13.212.1 with SMTP id w1mr23972122ywd.24.1495582867248; Tue, 23 May 2017 16:41:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 23 May 2017 16:40:26 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com> 
From: Eric Rescorla 
Date: Wed, 24 May 2017 07:40:26 +0800
Message-ID: 
To: Daniel Migault 
Cc: The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org,  Joseph Salowey , tls-chairs , tls 
Content-Type: multipart/alternative; boundary="001a114fb0f688f0cb055039859c"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 23:41:11 -0000

--001a114fb0f688f0cb055039859c
Content-Type: text/plain; charset="UTF-8"

On Wed, May 24, 2017 at 6:00 AM, Daniel Migault  wrote:

> Hi Eric,
>
> Thank you for your reviews. Please see my responses inline. If you agree
> with the text I will update the draft.
>
> Yours,
> Daniel
>
> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> The following text appears to have been added in -04
>>
>>    A server receiving a ClientHello and a client_version indicating
>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>    this document in ClientHello.cipher_suites can safely assume that
>> the
>>    client supports TLS 1.2 and is willing to use it.  The server MUST
>>    NOT negotiate these cipher suites with TLS protocol versions earlier
>>    than TLS 1.2.  Not requiring clients to indicate their support for
>>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>>    improves the interoperability in the installed base and use of TLS
>>    1.2 AEAD cipher suites without upsetting the installed base of
>>    version-intolerant TLS servers, results in more TLS handshakes
>>    succeeding and obviates fallback mechanisms.
>>
>> This is a major technical change from -03, which, AFAIK, prohibited
>> the server from negotiating these algorithms with TLS 1.1 and below
>> and maintained the usual TLS version 1.2 negotiation rules.
>>
>> This is a very material technical change. I don't consider it wise,
>> but in any case it would absolutely need WG consensus, which I
>> don't believe that it has given the recent introduction.
>>
>
> I agree that the text is a technical change, and that it may not be
> appropriated to do so now. The reason I included it was that it was conform
> to the previous text, but I agree that implicit assumption of version 1.2
> may need some additional discussion especially regarding RFC5246 Appendix
> E. Unless you prefer further discussion I assume the text below address
> your concern.
>
> The cipher suites defined in this document MUST NOT be negotiated for
> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
> these cipher suites with a (D)TLS version that differs from TLS 1.2.
> Servers MUST NOT select one of these cipher suites with a TLS version that
> differs from TLS 1.2. A client MUST treat the selection of these cipher
> suites in combination with a version of TLS as an error and generate a
> fatal 'illegal_parameter' TLS alert. 
>

Yes, this seems fine


The discussion of dictionary attacks here seems inferior to that
>> in 4279. In particular, you only need to actively attack one
>> connection to capture the data you need for a brute force attack
>> despite the text there referring to trying "different keys".
>> Please correct that.
>>
>> I believe the text below address your concern:
>
> OLD:
> Use of Pre-Shared Keys of limited entropy may allow an active
> attacker attempts to connect to the server and try different keys.
> For example, limited entropy may be provided by using a short PSK in which
> case an attacker may perform a brute-force attack. Another example
> includes the use of a PSK  chosen by a human which thus may be exposed to
> dictionary attacks.
>
> NEW:
> Pre-Shared Keys security relies on its associated entropy, and it is
> RECOMMENDED to follow  to ensure the PSK has enough
> entropy. Possible reasons for low entropy includes PSK chosen by humans or
> PSK of small length as well as using random generators with limited
> entropy. 
>
> PSK of limited entropy may allow an attacker to test different PSK
> values against a valid output such as master secret or any output derived
> from it. In this document, the master secret is generated using the PSK as
> well as the ECDHE shared secret. The use of ECDHE limits the possibilities
> of passive eavesdropping attackers, as the ECDHE shared secret is not
> expected to be derived from the observed ECDH parameters. As a result,
> passive eavesdropping is unlikely to happen, and the collection of all
> necessary material relies on an active attack.
> An active attacker may collect the necessary material by setting a TLS
> session as a client with the legitimate server. One PSK is tested for each
> session, and a match occurs when key exchange succeeds. On the other hand,
> an active attacker may also consider gathering the necessary information
> for offline computation. One way consists in getting a legitimate client to
> establish a connection with the attacker. It is also assumed that the
> client will accept the ECDH parameters authenticated by the attacker's
> private key and finally returns the Finished message authenticating the
> exchange. The attacker will be then in possession of all the necessary
> information to perform a brute force attack.
>

Is there a reason to not just point directly to the 4279 security
considerations?

-

>
>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> The citations to TLS 1.3 still seem pretty muddled. I think you
>> should just stop referencing and discussing 1.3.
>>
>
> My understanding of your comment is that mentioning TLS 1.3 to further
> insisting that the code point are not valid for TLS 1.3 is confusing. I
> propose to:
>
> Explicitly mention the TLS version in the title:
>
> OLD title:
> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
> Security (TLS)
>
> NEW title:
> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
> Security (TLS)
>
> OLD Introduction:
>
>     The cipher
>    suites are defined for version 1.2 of the Transport Layer Security
>    (TLS) [RFC5246 ] protocol, version 1.2 of the Datagram Transport Layer
>    Security (DTLS) protocol [RFC6347 ], as well as version 1.3 of TLS
>    [I-D.ietf-tls-tls13 ].
>
> NEW introduction
>
> The cipher
>    suites are defined for version 1.2 of the Transport Layer Security
>    (TLS) [RFC5246 ] protocol, version 1.2 of the Datagram Transport Layer
>    Security (DTLS) protocol [RFC6347 ].
>
>
> I suggest to keep the following text of the introduction:
>
>
> AEAD algorithms that combine encryption and integrity protection are
>    strongly recommended for (D)TLS [RFC7525 ] and non-AEAD algorithms are
>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 ].  The AEAD
>    algorithms considered in this document are AES-GCM and AES-CCM.  The
>    use of AES-GCM in TLS is defined in [RFC5288 ] and the use of AES-CCM
>    is defined in [RFC6655 ].
>
>
Yes, this seems fine.



> I suggest to keep the following text of the Applicable versions sections,
> as I believe the section discusses the cipher suites against all existing
> TLS versions. In addition, it also justifies somewhat that we only defined
> cipher suites that are compatible with TLS1.3.
>
>    TLS version 1.3 and later negotiate these features in a different
>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
>    suite negotiation [I-D.ietf-tls-tls13 ] Section 1.2 .  TLS 1.3 supports
>    PSK with ECDHE key exchange and the cipher suites
>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
>    specification.  As a result, TLS 1.3 and higher versions, negotiate
>    and support these cipher suites in a different way.
>
>
OK.


> I suggest to remove the reference to TLS1.3 in the security considerations
>
> OLD
>
>  The security considerations in TLS 1.2 [RFC5246 ], DTLS 1.2 [RFC6347 ],
>    TLS 1.3 [I-D.ietf-tls-tls13 ], ECDHE_PSK [RFC5489 ], AES-GCM [RFC5288 ],
>    and AES-CCM [RFC6655 ] apply to this document as well.
>
> NEW
>
>  The security considerations in TLS 1.2 [RFC5246 ], DTLS 1.2 [RFC6347 ],
>  ECDHE_PSK [RFC5489 ], AES-GCM [RFC5288 ],and AES-CCM [RFC6655 ] apply
>  to this document as well.
>
>
>> S 2.
>> I'm not sure that the discussion of the PRF is helpful here in
>> mandating the non-use of these cipher suites with TLS 1.1 and
>> below.
>>
>
> I find the text useful as it gives an idea why even introducing AEAD in
> TLS version lower than 1.2 is a bad idea, so I would prefer to keep it. The
> text has been changed to
>
> OLD:
> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
>
> NEW:
> As such,  all ECDHE_PSK
> ciphers, including those defined outside this document, SHOULD NOT be
> negotiated in TLS versions prior to 1.2.
>

I don't think you should be levying a new normative requirement like this
for other ciphers
i this document

-Ek
r

--001a114fb0f688f0cb055039859c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <<=
a href=3D"mailto:daniel.migault@ericsson.com" target=3D"_blank">daniel.miga=
ult@ericsson.com> wrote:
Hi Eric, 

Thank you for your rev=
iews. Please see my responses inline. If you agree with the text I will upd=
ate the draft.

Yours, 
Daniel
=


On Mon, May 22, 2017 at 10:11 PM, Eric Rescorl=
a <e=
kr@rtfm.com> wrote:
Eric Rescorla has entered the following ballot position for

draft-ietf-tls-ecdhe-psk-aead-04: Discuss



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/s=
tatement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc=
/draft-ietf-tls-ecdhe-psk-aead/







-----------------------------------------------------------------=
-----

DISCUSS:

-----------------------------------------------------------------=
-----



The following text appears to have been added in -04



=C2=A0 =C2=A0A server receiving a ClientHello and a client_version indicati=
ng

=C2=A0 =C2=A0(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any=
 of the cipher suites from

=C2=A0 =C2=A0this document in ClientHello.cipher_suites can safely assume t=
hat

the

=C2=A0 =C2=A0client supports TLS 1.2 and is willing to use it.=C2=A0 The se=
rver MUST

=C2=A0 =C2=A0NOT negotiate these cipher suites with TLS protocol versions e=
arlier

=C2=A0 =C2=A0than TLS 1.2.=C2=A0 Not requiring clients to indicate their su=
pport for

=C2=A0 =C2=A0TLS 1.2 cipher suites exclusively through ClientHello.client_h=
ello

=C2=A0 =C2=A0improves the interoperability in the installed base and use of=
 TLS

=C2=A0 =C2=A01.2 AEAD cipher suites without upsetting the installed base of=


=C2=A0 =C2=A0version-intolerant TLS servers, results in more TLS handshakes=


=C2=A0 =C2=A0succeeding and obviates fallback mechanisms.



This is a major technical change from -03, which, AFAIK, prohibited

the server from negotiating these algorithms with TLS 1.1 and below

and maintained the usual TLS version 1.2 negotiation rules.



This is a very material technical change. I don't consider it wise,

but in any case it would absolutely need WG consensus, which I

don't believe that it has given the recent introduction.

I agree that the text is a technical chan=
ge, and that it may not be appropriated to do so now. The reason I included=
 it was that it was conform to the previous text, but I agree that implicit=
 assumption of version 1.2 may need some additional discussion especially r=
egarding RFC5246 Appendix E. Unless you prefer further discussion I assume =
the text below address your concern. =C2=A0 

<t>The cipher sui=
tes defined in this document MUST NOT be negotiated for any version of (D)T=
LS other than TLS 1.2. Clients MUST NOT offer one of these cipher suites wi=
th a (D)TLS version that differs from TLS 1.2. Servers MUST NOT select one =
of these cipher suites with a TLS version that differs from TLS 1.2. A clie=
nt MUST treat the selection of these cipher suites in combination with a ve=
rsion of TLS as an error and generate a fatal 'illegal_parameter' T=
LS alert. </t> 

Yes, this seems fine


=


The discussion of dictionary attacks here seems inferior to that

in 4279. In particular, you only need to actively attack one

connection to capture the data you need for a brute force attack

despite the text there referring to trying "different keys".

Please correct that.


I believe the text below address your concern:=


OLD:
<t>Use of Pre-Shared Keys of limited entropy may allo=
w an active
attacker attempts to connect to the server and try different=
 keys.
For example, limited entropy may be provided by using a short PSK=
 in which
case an attacker may perform a brute-force attack. Another exa=
mple
includes the use of a PSK=C2=A0 chosen by a human which thus may be=
 exposed to
dictionary attacks.</t>

NEW:
<t>Pre-Sh=
ared Keys security relies on its associated entropy, and it is RECOMMENDED =
to follow <xref target=3D"4086"/> to ensure the PSK has eno=
ugh entropy. Possible reasons for low entropy includes PSK chosen by humans=
 or PSK of small length as well as using random generators with limited ent=
ropy. </t>

<t>PSK of limited entropy may allow an attack=
er to test different PSK values against a valid output such as master secre=
t or any output derived from it. In this document, the master secret is gen=
erated using the PSK as well as the ECDHE shared secret. The use of ECDHE l=
imits the possibilities of passive eavesdropping attackers, as the ECDHE sh=
ared secret is not expected to be derived from the observed ECDH parameters=
. As a result, passive eavesdropping is unlikely to happen, and the collect=
ion of all necessary material relies on an active attack. 
An active att=
acker may collect the necessary material by setting a TLS session as a clie=
nt with the legitimate server. One PSK is tested for each session, and a ma=
tch occurs when key exchange succeeds. On the other hand, an active attacke=
r may also consider gathering the necessary information for offline computa=
tion. One way consists in getting a legitimate client to establish a connec=
tion with the attacker. It is also assumed that the client will accept the =
ECDH parameters authenticated by the attacker's private key and finally=
 returns the Finished message authenticating the exchange. The attacker wil=
l be then in possession of all the necessary information to perform a brute=
 force attack.</t>=C2=A0=C2=A0 

Is there a reason to not jus=
t point directly to the 4279 security considerations?

<=
div>-
<=
div>
=C2=A0 
<=
/div>



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



The citations to TLS 1.3 still seem pretty muddled. I think you

should just stop referencing and discussing 1.3.

<=
/div>
My understanding of your comment is that mentioning TLS 1.=
3 to further insisting that the code point are not valid for TLS 1.3 is con=
fusing. I propose to:

Explicitly mention the TLS version =
in the title:

OLD title:
ECDHE_PSK with AES-GCM and AE=
S-CCM Cipher Suites for Transport Layer Security (TLS)

NE=
W title:
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport =
Layer Security (TLS)
=

OLD Introduction:
    The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13].
NE=
W introduction

The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347]. 


I suggest to keep the following text=
 of the introduction:

AEAD algori=
thms that combine encryption and integrity protection are
   strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.=
ietf-tls-tls13].  The AEAD
   algorithms considered in this document are AES-GCM and AES-CCM.  The
   use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
   is defined in [RFC6655].
<=
/div>

Yes, this seems fine.

<=
/div>
=C2=A0
I =
suggest to keep the following text of the Applicable versions sections, as =
I believe the section discusses the cipher suites against all existing TLS =
versions. In addition, it also justifies somewhat that we only defined ciph=
er suites that are compatible with TLS1.3.=C2=A0 
   T=
LS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-t=
ls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

OK.
=C2=A0
I suggest to remove the referen=
ce to TLS1.3 in the security considerations

OLD
 The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
   TLS 1.3 [I-D.ietf-tls-tls13],=
 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],
   and AES-CCM [RFC6655] apply to this document as well.

NEW 
<=
pre class=3D"m_4429336679413947623m_-101311485245468505m_-65000302070530479=
39gmail-newpage"> The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 =
[RFC6347], ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [RFC6655] apply 
 to th=
is document as well.



S 2.

I'm not sure that the discussion of the PRF is helpful here in

mandating the non-use of these cipher suites with TLS 1.1 and

below.

I find the text useful as=
 it gives an idea why even introducing AEAD in TLS version lower than 1.2 i=
s a bad idea, so I would prefer to keep it. The text has been changed to 
OLD:
As such TLS 1.0 and TLS 1.1 should not be used wit=
h ECDHE_PSK.

NEW:
As such,=C2=A0 all ECDHE_PSK=

ciphers, including those defined outside this document, SHOULD NOT benegotiated in TLS versions prior to 1.2.

I don't think you should be levying a new normative req=
uirement like this for other ciphers
i this document
-Ek
r



--001a114fb0f688f0cb055039859c--


From nobody Tue May 23 17:11:05 2017
Return-Path: 
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 C3427127866; Tue, 23 May 2017 17:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dyqT6G3-c4vV; Tue, 23 May 2017 17:11:01 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC01120727; Tue, 23 May 2017 17:11:01 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id h4so58659240lfj.3; Tue, 23 May 2017 17:11:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eQ0qEItdqOv8FuAmHewQEbT0mBiJpfySIN3tQFVPJDI=; b=k9oy4ZN4LaK7gWOqeXzMwYFP7fv3lzrhjytq3N2ezhbQUmEPulwKX2k9nLKtSxPrQu CrYK8imLd/YW1stKey94R3hWzvRLCxX2oEEA6lbzltZ6CURRzzLJb9sHD1PtyyMQcvXU 6zX7UrIuBcuTujxXOt0ARcFOX8difsaghfVHNp3KJ/ZVfXMgghUxlt5AFd41uuYhoaZf uizXDOQxv9v1fJOuaNrfxN69vCfLOBFWoSbf72rY/X21+AXkjBcwb3sGyAzOwcPkKmd/ yS1oEWTWDa51X+KRL9wFFhiBIr02F3sYeg7oNHP4FMAgGhqG9mXoNW69CLaHgWRTgm1y oQbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eQ0qEItdqOv8FuAmHewQEbT0mBiJpfySIN3tQFVPJDI=; b=EMwnsOZv3QI9InDrpwkLqbtrizirYXjLpTLYY3yDdGOsEVQZLVCV9p+RaCbI5E0eig 0LUGIXaH0AU7VYz1w/u+ST8sIe1lj1IlhchTEaVZd6hcicVuoC9lUHcE+TZzOtRZf2A3 78oovYkAwXhPkih+q/GPWmmaREW+TmrCs5dASYl54tJ/zLcFgez+BFJRCYNQfYCKQMq9 u9YHbAmAuFIGuSVtod/8uy2i+nrgxgA/l9F/u0QLJxa4ZzSqtcSDbD4dcsWwOTiXpw7S Qga+8PgSiC3neRL375EPMVg5SaiZWE9Xna5t7tTKqAQMWTFgQJwSPYFFHCbdOX8bX4cE 0Zdw==
X-Gm-Message-State: AODbwcDi0TbVUbrLmu+ZY2A8kZcG6CLFAe4Sm9/o5DeJj0FdvdBCCqno 0KR/IumxDEzNj1VE64xXuZk5WJcHHQ==
X-Received: by 10.25.215.198 with SMTP id q67mr7625292lfi.76.1495584659525; Tue, 23 May 2017 17:10:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Tue, 23 May 2017 17:10:58 -0700 (PDT)
In-Reply-To: 
References: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com> <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp> 
From: Martin Thomson 
Date: Wed, 24 May 2017 10:10:58 +1000
Message-ID: 
To: Daniel Migault 
Cc: "mrex@sap.com" , tls-chairs ,  draft-ietf-tls-ecdhe-psk-aead@ietf.org, Adam Roach ,  The IESG , tls 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 00:11:03 -0000

On 24 May 2017 at 08:04, Daniel Migault  wrote:
> So I have propose a fall back to the latest version. However, if we agree
> this is a better approach, I am fine adding it to the document.


Not sure what you mean by this.  If you mean removing the offending
paragraph, that seems best.

It's OK for these suites to be 1.2 only.


From nobody Tue May 23 19:33:30 2017
Return-Path: 
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 2EC3C129421; Tue, 23 May 2017 19:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZK9rJdFp37iO; Tue, 23 May 2017 19:33:26 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2EC1286AB; Tue, 23 May 2017 19:33:26 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id a5so46144418lfh.2; Tue, 23 May 2017 19:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=36M8Rl/qL562eGhQpnSROiYCZpEzb5NZ2IeFmsJ5Vq4=; b=b0b1lhhyZBrMljp6U712UoJHW4RroIjkzQu8Ha2swibpgDtxADNarVew0cfuYGBkte D97qtZTUAYPRI+EJBgDIGE6tMD4LccVN4/K9ycC1mBiyDZCk6V6wFMFci3/LAUsxwWn7 adRIfUld5y574AdrOUuA0APrkKTH83TVbhRyVLX4FjZ4JDYv0Z1AVLooMegkd/8hGvg/ 3PyiW3/JZHeqjGjAwUn7Z2IGJgSts0b7T3yXoubUMvOmwCSU4FAdQAVYdwL4lIv0qZt8 sRH7I/huBPj5Jqey32X9zJAci1k154FIWVrOf+DaeI4MtzrtuhZ/y6EWry8VqR2yFp2S VBVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=36M8Rl/qL562eGhQpnSROiYCZpEzb5NZ2IeFmsJ5Vq4=; b=iEaPg1Po1ZTWomQX1ZnDyX2YLC/C48WsfcqsWU7MdM3yObU8Pyp9bMcEGNMYAvsRXS PiT5FnNQCjsWSmfDKhFAxfGqxG3aTd/sHoKVeq90coEONg2Hc6q96HCgCdtbwIIdJE6x tm3yodL/HsbrBtl7nDBW+WMq3GoKpr2nifI8utHHDCIxelVQz9alfAhV6aiHMrzvup7P f9sWRk4TCHOIbM+Wdu5vwwg5CbO2PwiKkUfunkwU0IwPmHYTL+i7c3mAl3VMTJ0B6OlQ K0YwRx13jZGLc2dUVaG3DQhcjBoNqOlQjywBY2LjtGEv6cJQO/Ajcnxbc28yfPZ6kYrr dZsg==
X-Gm-Message-State: AODbwcC/QyU7Dja4iHPD7f4xP06v25Pmkg6xRv9Wu4i+Sq4VAUb4dkg9 b9kCagpdfhONliGJT5bCOk1q3ulojw==
X-Received: by 10.46.76.1 with SMTP id z1mr7838645lja.128.1495593204574; Tue, 23 May 2017 19:33:24 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 19:33:23 -0700 (PDT)
In-Reply-To: 
References: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com> <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp>  
From: Daniel Migault 
Date: Tue, 23 May 2017 21:33:23 -0500
X-Google-Sender-Auth: XT4bu6NHQpVfA9SBOoujmdvObc0
Message-ID: 
To: Martin Thomson 
Cc: "mrex@sap.com" , tls-chairs ,  draft-ietf-tls-ecdhe-psk-aead@ietf.org, Adam Roach ,  The IESG , tls 
Content-Type: multipart/alternative; boundary="f403045ea6daaff0d805503bedd6"
Archived-At: 
Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 02:33:28 -0000

--f403045ea6daaff0d805503bedd6
Content-Type: text/plain; charset="UTF-8"

Hi Martin,

The current version does not consider that proposing the cipher suites of
the document implicitly assumes the client supports TLS1.2. However, if
people think there is an advantage of adding this I am fine this being
discussed and  added in the next versions.

Yours,
Daniel

On Tue, May 23, 2017 at 7:10 PM, Martin Thomson 
wrote:

> On 24 May 2017 at 08:04, Daniel Migault 
> wrote:
> > So I have propose a fall back to the latest version. However, if we agree
> > this is a better approach, I am fine adding it to the document.
>
>
> Not sure what you mean by this.  If you mean removing the offending
> paragraph, that seems best.
>
> It's OK for these suites to be 1.2 only.
>

--f403045ea6daaff0d805503bedd6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Martin, 

The current versio=
n does not consider that proposing the cipher suites of the document implic=
itly assumes the client supports TLS1.2. However, if people think there is =
an advantage of adding this I am fine this being discussed and=C2=A0 added =
in the next versions.

Yours, 
Daniel 

On Tue, May 23, 2017 at=
 7:10 PM, Martin Thomson <martin.thomson@gmail.com> w=
rote:
On 24 May 2017 at =
08:04, Daniel Migault <da=
niel.migault@ericsson.com> wrote:

> So I have propose a fall back to the latest version. However, if we ag=
ree

> this is a better approach, I am fine adding it to the document.





Not sure what you mean by this.=C2=A0 If you mean removing the offen=
ding

paragraph, that seems best.



It's OK for these suites to be 1.2 only.





--f403045ea6daaff0d805503bedd6--


From nobody Tue May 23 19:37:43 2017
Return-Path: 
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 05E6C12946C; Tue, 23 May 2017 19:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CgXD_x1RRhJz; Tue, 23 May 2017 19:37:36 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2481286AB; Tue, 23 May 2017 19:37:35 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id h4so59720109lfj.3; Tue, 23 May 2017 19:37:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ywg70humm/wAG37gn1zWDG9mE5/mrn+OhW94pzYwutM=; b=ig0Om4LtNfWbnyYiiSO62d7FdpT8Y+6HGmQDTX2vv85MF7Gx/scWKfVRVu1Qi7qJBz XXrVC3bj8zRf0rnFzA0WnlvSUPo3AwIGZhbqiJ87XcM4TIXFm4U9HvoLaap4iN7zt8Nl ng/arq3oH1q2E9g7tFcfL9cxJm0pbyjo1Tu+8VUr93ctFUM5RVs+09ieChwVjhP3ys6o 7j3cq5UDqn9vc3kncFVNKPNhLQi/lXsmOceeCAaHPxEXLVwS51GdAtNLFidrVyBL4dke edPsUDfiRPtqcGFrhIgXHvccO8r3HEn7ZAKyBL/4zp8DABiZpKpzwudsWAndWAiwT3uC U9mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ywg70humm/wAG37gn1zWDG9mE5/mrn+OhW94pzYwutM=; b=Shg3B67/xvUkKF7nAd23L6bnb8rsNsLmDErbrO9dUKgrOdJUmuVbpfchzcbN/CDkF0 zLUKXqVb601fl5ZCkqjlYcK8P7nW9Xp2lDbdwL7DqNSh6YkUb45OFEC8KAUeXxrXIRQt WZpOKU7xacWdqMtjXJg3q37ry+JZh3jGw97z2a/t20IwLXZY+qio4d8kQD6JB5776fGA U/F8Eg+eLXO+H5QYpcEooYyGv9LuDd2+tynAwPNHw31N1UUnShynUMVEEK6qx1BxAv/u 6NI2S130ZQ0q9zf2BsPhLIAEs2OdN4pTEjz7Xvs+ugoPF0p3MsKbKEwZgx7GdOwzz6fl uicA==
X-Gm-Message-State: AODbwcAz+JG/1+lNVLLFxHxThYYyZ9d3J78mhW8DY3+trT8vsgWHy+Cd 0H1zJcz7CVGUFPFzqdkSeLH89dhBog==
X-Received: by 10.25.208.14 with SMTP id h14mr7224506lfg.174.1495593453923; Tue, 23 May 2017 19:37:33 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 19:37:33 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>   
From: Daniel Migault 
Date: Tue, 23 May 2017 21:37:33 -0500
X-Google-Sender-Auth: vhBbM_T1hl-s3GknTGuQREBJ1EQ
Message-ID: 
To: Eric Rescorla 
Cc: The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org,  Joseph Salowey , tls-chairs , tls 
Content-Type: multipart/mixed; boundary="001a11412d3c8cca6305503bfc78"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 02:37:41 -0000

--001a11412d3c8cca6305503bfc78
Content-Type: multipart/alternative; boundary="001a11412d3c8cca5e05503bfc76"

--001a11412d3c8cca5e05503bfc76
Content-Type: text/plain; charset="UTF-8"

re-sending with the version 05 but removing the diff to be under the 100 KB
limit.
Yours,
Daniel

On Tue, May 23, 2017 at 9:28 PM, Daniel Migault  wrote:

> Hi Eric,
>
> Thank you for the feed backs. The version 05 contains all text changes you
> agreed. In addition, the text explaining dictionary/brute force has been
> removed and replace by a reference to 4279. The recommendation regarding to
> all PSK ciphers has been limited to the one of the document.  Please see
> inline for more details.
>
> For some reasons I am not able to validate the submission of version 05. I
> have attached the diff with version 04 as well as the locally generated
> version 05.
>
> Yours,
> Daniel
>
> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <
>> daniel.migault@ericsson.com> wrote:
>>
>>> Hi Eric,
>>>
>>> Thank you for your reviews. Please see my responses inline. If you agree
>>> with the text I will update the draft.
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
>>>
>>>> Eric Rescorla has entered the following ballot position for
>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to https://www.ietf.org/iesg/stat
>>>> ement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> The following text appears to have been added in -04
>>>>
>>>>    A server receiving a ClientHello and a client_version indicating
>>>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>>>    this document in ClientHello.cipher_suites can safely assume that
>>>> the
>>>>    client supports TLS 1.2 and is willing to use it.  The server MUST
>>>>    NOT negotiate these cipher suites with TLS protocol versions earlier
>>>>    than TLS 1.2.  Not requiring clients to indicate their support for
>>>>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>>>>    improves the interoperability in the installed base and use of TLS
>>>>    1.2 AEAD cipher suites without upsetting the installed base of
>>>>    version-intolerant TLS servers, results in more TLS handshakes
>>>>    succeeding and obviates fallback mechanisms.
>>>>
>>>> This is a major technical change from -03, which, AFAIK, prohibited
>>>> the server from negotiating these algorithms with TLS 1.1 and below
>>>> and maintained the usual TLS version 1.2 negotiation rules.
>>>>
>>>> This is a very material technical change. I don't consider it wise,
>>>> but in any case it would absolutely need WG consensus, which I
>>>> don't believe that it has given the recent introduction.
>>>>
>>>
>>> I agree that the text is a technical change, and that it may not be
>>> appropriated to do so now. The reason I included it was that it was conform
>>> to the previous text, but I agree that implicit assumption of version 1.2
>>> may need some additional discussion especially regarding RFC5246 Appendix
>>> E. Unless you prefer further discussion I assume the text below address
>>> your concern.
>>>
>>> The cipher suites defined in this document MUST NOT be negotiated for
>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
>>> these cipher suites with a (D)TLS version that differs from TLS 1.2.
>>> Servers MUST NOT select one of these cipher suites with a TLS version that
>>> differs from TLS 1.2. A client MUST treat the selection of these cipher
>>> suites in combination with a version of TLS as an error and generate a
>>> fatal 'illegal_parameter' TLS alert. 
>>>
>>
>> Yes, this seems fine
>>
>>
>> The discussion of dictionary attacks here seems inferior to that
>>>> in 4279. In particular, you only need to actively attack one
>>>> connection to capture the data you need for a brute force attack
>>>> despite the text there referring to trying "different keys".
>>>> Please correct that.
>>>>
>>>> I believe the text below address your concern:
>>>
>>> OLD:
>>> Use of Pre-Shared Keys of limited entropy may allow an active
>>> attacker attempts to connect to the server and try different keys.
>>> For example, limited entropy may be provided by using a short PSK in
>>> which
>>> case an attacker may perform a brute-force attack. Another example
>>> includes the use of a PSK  chosen by a human which thus may be exposed to
>>> dictionary attacks.
>>>
>>> NEW:
>>> Pre-Shared Keys security relies on its associated entropy, and it is
>>> RECOMMENDED to follow  to ensure the PSK has enough
>>> entropy. Possible reasons for low entropy includes PSK chosen by humans or
>>> PSK of small length as well as using random generators with limited
>>> entropy. 
>>>
>>> PSK of limited entropy may allow an attacker to test different PSK
>>> values against a valid output such as master secret or any output derived
>>> from it. In this document, the master secret is generated using the PSK as
>>> well as the ECDHE shared secret. The use of ECDHE limits the possibilities
>>> of passive eavesdropping attackers, as the ECDHE shared secret is not
>>> expected to be derived from the observed ECDH parameters. As a result,
>>> passive eavesdropping is unlikely to happen, and the collection of all
>>> necessary material relies on an active attack.
>>> An active attacker may collect the necessary material by setting a TLS
>>> session as a client with the legitimate server. One PSK is tested for each
>>> session, and a match occurs when key exchange succeeds. On the other hand,
>>> an active attacker may also consider gathering the necessary information
>>> for offline computation. One way consists in getting a legitimate client to
>>> establish a connection with the attacker. It is also assumed that the
>>> client will accept the ECDH parameters authenticated by the attacker's
>>> private key and finally returns the Finished message authenticating the
>>> exchange. The attacker will be then in possession of all the necessary
>>> information to perform a brute force attack.
>>>
>>
>> Is there a reason to not just point directly to the 4279 security
>> considerations?
>>
>
> No, basically I tried to complete the previous text that missed the
> offline use case. The current version just point to 4279, without having
> the above text. If you think the text above is clarifying I can add it as
> well.
>
>> -
>>
>>>
>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> The citations to TLS 1.3 still seem pretty muddled. I think you
>>>> should just stop referencing and discussing 1.3.
>>>>
>>>
>>> My understanding of your comment is that mentioning TLS 1.3 to further
>>> insisting that the code point are not valid for TLS 1.3 is confusing. I
>>> propose to:
>>>
>>> Explicitly mention the TLS version in the title:
>>>
>>> OLD title:
>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>>> Security (TLS)
>>>
>>> NEW title:
>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>>> Security (TLS)
>>>
>>> OLD Introduction:
>>>
>>>     The cipher
>>>    suites are defined for version 1.2 of the Transport Layer Security
>>>    (TLS) [RFC5246 ] protocol, version 1.2 of the Datagram Transport Layer
>>>    Security (DTLS) protocol [RFC6347 ], as well as version 1.3 of TLS
>>>    [I-D.ietf-tls-tls13 ].
>>>
>>> NEW introduction
>>>
>>> The cipher
>>>    suites are defined for version 1.2 of the Transport Layer Security
>>>    (TLS) [RFC5246 ] protocol, version 1.2 of the Datagram Transport Layer
>>>    Security (DTLS) protocol [RFC6347 ].
>>>
>>>
>>> I suggest to keep the following text of the introduction:
>>>
>>>
>>> AEAD algorithms that combine encryption and integrity protection are
>>>    strongly recommended for (D)TLS [RFC7525 ] and non-AEAD algorithms are
>>>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 ].  The AEAD
>>>    algorithms considered in this document are AES-GCM and AES-CCM.  The
>>>    use of AES-GCM in TLS is defined in [RFC5288 ] and the use of AES-CCM
>>>    is defined in [RFC6655 ].
>>>
>>>
>> Yes, this seems fine.
>>
>>
>>
>>> I suggest to keep the following text of the Applicable versions
>>> sections, as I believe the section discusses the cipher suites against all
>>> existing TLS versions. In addition, it also justifies somewhat that we only
>>> defined cipher suites that are compatible with TLS1.3.
>>>
>>>    TLS version 1.3 and later negotiate these features in a different
>>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
>>>    suite negotiation [I-D.ietf-tls-tls13 ] Section 1.2 .  TLS 1.3 supports
>>>    PSK with ECDHE key exchange and the cipher suites
>>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
>>>    specification.  As a result, TLS 1.3 and higher versions, negotiate
>>>    and support these cipher suites in a different way.
>>>
>>>
>> OK.
>>
>>
>>> I suggest to remove the reference to TLS1.3 in the security
>>> considerations
>>>
>>> OLD
>>>
>>>  The security considerations in TLS 1.2 [RFC5246 ], DTLS 1.2 [RFC6347 ],
>>>    TLS 1.3 [I-D.ietf-tls-tls13 ], ECDHE_PSK [RFC5489 ], AES-GCM [RFC5288 ],
>>>    and AES-CCM [RFC6655 ] apply to this document as well.
>>>
>>> NEW
>>>
>>>  The security considerations in TLS 1.2 [RFC5246 ], DTLS 1.2 [RFC6347 ],
>>>  ECDHE_PSK [RFC5489 ], AES-GCM [RFC5288 ],and AES-CCM [RFC6655 ] apply
>>>  to this document as well.
>>>
>>>
>>>> S 2.
>>>> I'm not sure that the discussion of the PRF is helpful here in
>>>> mandating the non-use of these cipher suites with TLS 1.1 and
>>>> below.
>>>>
>>>
>>> I find the text useful as it gives an idea why even introducing AEAD in
>>> TLS version lower than 1.2 is a bad idea, so I would prefer to keep it. The
>>> text has been changed to
>>>
>>> OLD:
>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
>>>
>>> NEW:
>>> As such,  all ECDHE_PSK
>>> ciphers, including those defined outside this document, SHOULD NOT be
>>> negotiated in TLS versions prior to 1.2.
>>>
>>
>> I don't think you should be levying a new normative requirement like this
>> for other ciphers
>> i this document
>>
>
> Consideration for other ciphers has been removed. The requirement is
> limited to the ciphers of the document. The new text is:
>
> As such, all ECDHE_PSK ciphers, including those defined in this document,
> SHOULD NOT be
> negotiated in TLS versions prior to 1.2.
>
>>
>> -Ek
>> r
>>
>>
>

--001a11412d3c8cca5e05503bfc76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


re-sending with the version 05 but removing the =
diff to be under the 100 KB limit. 
Yours, 
Daniel

On Tu=
e, May 23, 2017 at 9:28 PM, Daniel Migault <daniel.migault@erics=
son.com> wrote:
Hi Eric, 

Thank you for the feed backs. The ve=
rsion 05 contains all text changes you agreed. In addition, the text explai=
ning dictionary/brute force has been removed and replace by a reference to =
4279. The recommendation regarding to all PSK ciphers has been limited to t=
he one of the document.=C2=A0 Please see=C2=A0 inline for more details.
=

For some reasons I am not able to validate the submission of version =
05. I have attached the diff with version 04 as well as the locally generat=
ed version 05. 

Yours, 
Daniel

On Tue, May 2=
3, 2017 at 7:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, May 24, 2017 at 6:00 AM=
, Daniel Migault <daniel.migault@ericsson.com> wro=
te:
<=
div>
Hi Eric, 

Thank you for your reviews. Please see=
 my responses inline. If you agree with the text I will update the draft.
Yours, 
Daniel

On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <=
ekr@rtfm.com> wrote:
Eric Rescorl=
a has entered the following ballot position for

draft-ietf-tls-ecdhe-psk-aead-04: Discuss



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/s=
tatement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc=
/draft-ietf-tls-ecdhe-psk-aead/







-----------------------------------------------------------------=
-----

DISCUSS:

-----------------------------------------------------------------=
-----



The following text appears to have been added in -04



=C2=A0 =C2=A0A server receiving a ClientHello and a client_version indicati=
ng

=C2=A0 =C2=A0(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any=
 of the cipher suites from

=C2=A0 =C2=A0this document in ClientHello.cipher_suites can safely assume t=
hat

the

=C2=A0 =C2=A0client supports TLS 1.2 and is willing to use it.=C2=A0 The se=
rver MUST

=C2=A0 =C2=A0NOT negotiate these cipher suites with TLS protocol versions e=
arlier

=C2=A0 =C2=A0than TLS 1.2.=C2=A0 Not requiring clients to indicate their su=
pport for

=C2=A0 =C2=A0TLS 1.2 cipher suites exclusively through ClientHello.client_h=
ello

=C2=A0 =C2=A0improves the interoperability in the installed base and use of=
 TLS

=C2=A0 =C2=A01.2 AEAD cipher suites without upsetting the installed base of=


=C2=A0 =C2=A0version-intolerant TLS servers, results in more TLS handshakes=


=C2=A0 =C2=A0succeeding and obviates fallback mechanisms.



This is a major technical change from -03, which, AFAIK, prohibited

the server from negotiating these algorithms with TLS 1.1 and below

and maintained the usual TLS version 1.2 negotiation rules.



This is a very material technical change. I don't consider it wise,

but in any case it would absolutely need WG consensus, which I

don't believe that it has given the recent introduction.

I agree that the text is a technical chan=
ge, and that it may not be appropriated to do so now. The reason I included=
 it was that it was conform to the previous text, but I agree that implicit=
 assumption of version 1.2 may need some additional discussion especially r=
egarding RFC5246 Appendix E. Unless you prefer further discussion I assume =
the text below address your concern. =C2=A0 

<t>The cipher sui=
tes defined in this document MUST NOT be negotiated for any version of (D)T=
LS other than TLS 1.2. Clients MUST NOT offer one of these cipher suites wi=
th a (D)TLS version that differs from TLS 1.2. Servers MUST NOT select one =
of these cipher suites with a TLS version that differs from TLS 1.2. A clie=
nt MUST treat the selection of these cipher suites in combination with a ve=
rsion of TLS as an error and generate a fatal 'illegal_parameter' T=
LS alert. </t> 

Yes, this seems fine

<=
div>

The discussion of dictionary attacks here seems inferior to that

in 4279. In particular, you only need to actively attack one

connection to capture the data you need for a brute force attack

despite the text there referring to trying "different keys".

Please correct that.


I believe the text below address your concern:=


OLD:
<t>Use of Pre-Shared Keys of limited entropy may allo=
w an active
attacker attempts to connect to the server and try different=
 keys.
For example, limited entropy may be provided by using a short PSK=
 in which
case an attacker may perform a brute-force attack. Another exa=
mple
includes the use of a PSK=C2=A0 chosen by a human which thus may be=
 exposed to
dictionary attacks.</t>

NEW:
<t>Pre-Sh=
ared Keys security relies on its associated entropy, and it is RECOMMENDED =
to follow <xref target=3D"4086"/> to ensure the PSK has eno=
ugh entropy. Possible reasons for low entropy includes PSK chosen by humans=
 or PSK of small length as well as using random generators with limited ent=
ropy. </t>

<t>PSK of limited entropy may allow an attack=
er to test different PSK values against a valid output such as master secre=
t or any output derived from it. In this document, the master secret is gen=
erated using the PSK as well as the ECDHE shared secret. The use of ECDHE l=
imits the possibilities of passive eavesdropping attackers, as the ECDHE sh=
ared secret is not expected to be derived from the observed ECDH parameters=
. As a result, passive eavesdropping is unlikely to happen, and the collect=
ion of all necessary material relies on an active attack. 
An active att=
acker may collect the necessary material by setting a TLS session as a clie=
nt with the legitimate server. One PSK is tested for each session, and a ma=
tch occurs when key exchange succeeds. On the other hand, an active attacke=
r may also consider gathering the necessary information for offline computa=
tion. One way consists in getting a legitimate client to establish a connec=
tion with the attacker. It is also assumed that the client will accept the =
ECDH parameters authenticated by the attacker's private key and finally=
 returns the Finished message authenticating the exchange. The attacker wil=
l be then in possession of all the necessary information to perform a brute=
 force attack.</t>=C2=A0=C2=A0 

Is there a reason to =
not just point directly to the 4279 security considerations?

No, basically I tried=
 to complete the previous text that missed the offline use case. The curren=
t version just point to 4279, without having the above text. If you think t=
he text above is clarifying I can add it as well.=C2=A0 =C2=A0 =C2=A0 
<=
/div>
<=
div>-
<=
div>
=C2=A0 



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



The citations to TLS 1.3 still seem pretty muddled. I think you

should just stop referencing and discussing 1.3.

<=
/div>
My understanding of your comment is that mentioning TLS 1.=
3 to further insisting that the code point are not valid for TLS 1.3 is con=
fusing. I propose to:

Explicitly mention the TLS version =
in the title:

OLD title:
ECDHE_PSK with AES-GCM and AE=
S-CCM Cipher Suites for Transport Layer Security (TLS)

NE=
W title:
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport =
Layer Security (TLS)
OLD Introduction:
    The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13].
NE=
W introduction

The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347]. 


I suggest to keep the following text=
 of the introduction:

AEAD algorithms t=
hat combine encryption and integrity protection are
   strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.=
ietf-tls-tls13].  The AEAD
   algorithms considered in this document are AES-GCM and AES-CCM.  The
   use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
   is defined in [RFC6655].
<=
/div>

Yes, this seems fine.
=C2=A0
<=
div dir=3D"ltr">
=
I suggest to keep the following text of the Applicable versions sections, a=
s I believe the section discusses the cipher suites against all existing TL=
S versions. In addition, it also justifies somewhat that we only defined ci=
pher suites that are compatible with TLS1.3.=C2=A0 
   TLS v=
ersion 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-t=
ls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

OK.
=C2=A0
I suggest to remove the reference =
to TLS1.3 in the security considerations

OLD
 T=
he security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
   TLS 1.3 [I-D.ietf-tls-tls13],=
 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],
   and AES-CCM [RFC6655] apply to this document as well.

NEW 
<=
pre class=3D"m_4394873319862751035m_5356331867454488272gmail-m_499715382688=
4106269m_4429336679413947623m_-101311485245468505m_-6500030207053047939gmai=
l-newpage"> The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
 ECD=
HE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [RFC6655] apply 
 to this docu=
ment as well.



S 2.

I'm not sure that the discussion of the PRF is helpful here in

mandating the non-use of these cipher suites with TLS 1.1 and

below.

I find the text useful as=
 it gives an idea why even introducing AEAD in TLS version lower than 1.2 i=
s a bad idea, so I would prefer to keep it. The text has been changed to 
OLD:
As such TLS 1.0 and TLS 1.1 should not be used wit=
h ECDHE_PSK.

NEW:
As such,=C2=A0 all ECDHE_PSK=

ciphers, including those defined outside this document, SHOULD NOT benegotiated in TLS versions prior to 1.2.

I don't think you should be levying a new normat=
ive requirement like this for other ciphers
i this document
=


Consideratio=
n for other ciphers has been removed. The requirement is limited to the cip=
hers of the document. The new text is:

As such, all ECDHE_PSK cipher=
s, including those defined in this document, SHOULD NOT be=

negotiated in TLS versions prior to 1.2.

-Ek
r








--001a11412d3c8cca5e05503bfc76--

--001a11412d3c8cca6305503bfc78
Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-tls-ecdhe-psk-aead-05.txt"
Content-Disposition: attachment; 
	filename="draft-ietf-tls-ecdhe-psk-aead-05.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_j32dnssw2

CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBKLiBNYXR0c3NvbgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEQuIE1pZ2F1bHQKSW50ZW5kZWQgc3RhdHVzOiBTdGFu
ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uCkV4cGly
ZXM6IE5vdmVtYmVyIDI0LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1h
eSAyMywgMjAxNwoKCiAgRUNESEVfUFNLIHdpdGggQUVTLUdDTSBhbmQgQUVTLUNDTSBDaXBoZXIg
U3VpdGVzIGZvciBUcmFuc3BvcnQgTGF5ZXIKICAgICAgICAgICAgICAgICAgU2VjdXJpdHkgKFRM
UykgUHJvdG9jb2wgdmVyc2lvbiAxLjIKICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXRs
cy1lY2RoZS1wc2stYWVhZC0wNQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBz
ZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNwb3J0CiAgIExheWVyIFNlY3Vy
aXR5IChUTFMpIHByb3RvY29sIHZlcnNpb24gMS4yLiAgVGhlIGNpcGhlciBzdWl0ZXMgYXJlIGFs
bAogICBiYXNlZCBvbiB0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlIERpZmZpZS1IZWxsbWFu
IHdpdGggUHJlLVNoYXJlZAogICBLZXkgKEVDREhFX1BTSykga2V5IGV4Y2hhbmdlIHRvZ2V0aGVy
IHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQKICAgRW5jcnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0
YSAoQUVBRCkgYWxnb3JpdGhtcyBBRVMtR0NNIGFuZCBBRVMtCiAgIENDTS4gIFBTSyBwcm92aWRl
cyBsaWdodCBhbmQgZWZmaWNpZW50IGF1dGhlbnRpY2F0aW9uLCBFQ0RIRSBwcm92aWRlcwogICBm
b3J3YXJkIHNlY3JlY3ksIGFuZCBBRVMtR0NNIGFuZCBBRVMtQ0NNIHByb3ZpZGVzIGVuY3J5cHRp
b24gYW5kCiAgIGludGVncml0eSBwcm90ZWN0aW9uLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAg
VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRo
IHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAg
VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry
aWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qg
b2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv
Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1
cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkK
ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyBy
ZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsg
aW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3Zl
bWJlciAyNCwgMjAxNy4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNyBJ
RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBh
dXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj
dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxh
dGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5z
ZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBk
b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMg
dGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAoK
CgpNYXR0c3NvbiAmIE1pZ2F1bHQgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI0LCAyMDE3ICAgICAg
ICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVDREhFX1BT
S19BRUFEICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTcKCgogICB0byB0aGlzIGRvY3VtZW50
LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBp
bmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv
biA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3
aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGlj
ZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIEludHJvZHVj
dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAy
CiAgIDMuICBFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMg
IC4gLiAuIC4gLiAuICAgMwogICA0LiAgQXBwbGljYWJsZSBUTFMgVmVyc2lvbnMgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlv
bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDYuICBT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuICAgNAogICA3LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgOC4xLiAgTm9ybWF0
aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog
ICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgIDYKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CgoxLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9u
CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM
IiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs
ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl
cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKMi4gIEludHJvZHVjdGlvbgoKICAg
VGhpcyBkb2N1bWVudCBkZWZpbmVzIG5ldyBjaXBoZXIgc3VpdGVzIHRoYXQgcHJvdmlkZSBQcmUt
U2hhcmVkIEtleQogICAoUFNLKSBhdXRoZW50aWNhdGlvbiwgUGVyZmVjdCBGb3J3YXJkIFNlY3Jl
Y3kgKFBGUyksIGFuZAogICBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVk
IERhdGEgKEFFQUQpLiAgVGhlIGNpcGhlcgogICBzdWl0ZXMgYXJlIGRlZmluZWQgZm9yIHZlcnNp
b24gMS4yIG9mIHRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkKICAgKFRMUykgW1JGQzUyNDZd
IHByb3RvY29sIGFuZCB2ZXJzaW9uIDEuMiBvZiB0aGUgRGF0YWdyYW0gVHJhbnNwb3J0CiAgIExh
eWVyIFNlY3VyaXR5IChEVExTKSBwcm90b2NvbCBbUkZDNjM0N10uCgogICBQcmUtU2hhcmVkIEtl
eSAoUFNLKSBBdXRoZW50aWNhdGlvbiBpcyB3aWRlbHkgdXNlZCBpbiBtYW55IHNjZW5hcmlvcy4K
ICAgT25lIGRlcGxveW1lbnQgaXMgM0dQUCBuZXR3b3JrcyB3aGVyZSBwcmUtc2hhcmVkIGtleXMg
YXJlIHVzZWQgdG8KICAgYXV0aGVudGljYXRlIGJvdGggc3Vic2NyaWJlciBhbmQgbmV0d29yay4g
IEFub3RoZXIgZGVwbG95bWVudCBpcwogICBJbnRlcm5ldCBvZiBUaGluZ3Mgd2hlcmUgUFNLIGF1
dGhlbnRpY2F0aW9uIGlzIG9mdGVuIHByZWZlcnJlZCBmb3IKICAgcGVyZm9ybWFuY2UgYW5kIGVu
ZXJneSBlZmZpY2llbmN5IHJlYXNvbnMuICBJbiBib3RoIHNjZW5hcmlvcyB0aGUKICAgZW5kcG9p
bnRzIGFyZSBvd25lZC9jb250cm9sbGVkIGJ5IGEgcGFydHkgdGhhdCBwcm92aXNpb25zIHRoZSBw
cmUtCiAgIHNoYXJlZCBrZXlzIGFuZCBtYWtlcyBzdXJlIHRoYXQgdGhleSBwcm92aWRlIGEgaGln
aCBsZXZlbCBvZiBlbnRyb3B5LgoKICAgUGVyZmVjdCBGb3J3YXJkIFNlY3JlY3kgKFBGUykgaXMg
YSBzdHJvbmdseSByZWNvbW1lbmRlZCBmZWF0dXJlIGluCiAgIHNlY3VyaXR5IHByb3RvY29sIGRl
c2lnbiBhbmQgY2FuIGJlIGFjY29tcGxpc2hlZCBieSB1c2luZyBhbgogICBlcGhlbWVyYWwgRGlm
ZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlIG1ldGhvZC4gIEVwaGVtZXJhbCBFbGxpcHRpYwogICBD
dXJ2ZSBEaWZmaWUtSGVsbG1hbiAoRUNESEUpIHByb3ZpZGVzIFBGUyB3aXRoIGV4Y2VsbGVudCBw
ZXJmb3JtYW5jZQogICBhbmQgc21hbGwga2V5IHNpemVzLiAgRUNESEUgaXMgbWFuZGF0b3J5IHRv
IGltcGxlbWVudCBpbiBib3RoIEhUVFAvMgogICBbUkZDNzU0MF0gYW5kIENvQVAgW1JGQzcyNTJd
LgoKCgpNYXR0c3NvbiAmIE1pZ2F1bHQgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI0LCAyMDE3ICAg
ICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVDREhF
X1BTS19BRUFEICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTcKCgogICBBRUFEIGFsZ29yaXRo
bXMgdGhhdCBjb21iaW5lIGVuY3J5cHRpb24gYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGFyZQog
ICBzdHJvbmdseSByZWNvbW1lbmRlZCBmb3IgKEQpVExTIFtSRkM3NTI1XSBhbmQgbm9uLUFFQUQg
YWxnb3JpdGhtcyBhcmUKICAgZm9yYmlkZGVuIHRvIHVzZSBpbiBUTFMgMS4zIFtJLUQuaWV0Zi10
bHMtdGxzMTNdLiAgVGhlIEFFQUQKICAgYWxnb3JpdGhtcyBjb25zaWRlcmVkIGluIHRoaXMgZG9j
dW1lbnQgYXJlIEFFUy1HQ00gYW5kIEFFUy1DQ00uICBUaGUKICAgdXNlIG9mIEFFUy1HQ00gaW4g
VExTIGlzIGRlZmluZWQgaW4gW1JGQzUyODhdIGFuZCB0aGUgdXNlIG9mIEFFUy1DQ00KICAgaXMg
ZGVmaW5lZCBpbiBbUkZDNjY1NV0uCgogICBbUkZDNDI3OV0gZGVmaW5lcyBQcmUtU2hhcmVkIEtl
eSAoUFNLKSBjaXBoZXIgc3VpdGVzIGZvciBUTFMgYnV0IGRvZXMKICAgbm90IGNvbnNpZGVyIEVs
bGlwdGljIEN1cnZlIENyeXB0b2dyYXBoeS4gIFtSRkM0NDkyXSBpbnRyb2R1Y2VzCiAgIEVsbGlw
dGljIEN1cnZlIENyeXB0b2dyYXBoeSBmb3IgVExTIGJ1dCBkb2VzIG5vdCBjb25zaWRlciBQU0sK
ICAgYXV0aGVudGljYXRpb24uICBbUkZDNTQ4N10gZGVzY3JpYmVzIHRoZSB1c2Ugb2YgQUVTLUdD
TSBpbgogICBjb21iaW5hdGlvbiB3aXRoIFBTSyBhdXRoZW50aWNhdGlvbiwgYnV0IGRvZXMgbm90
IGNvbnNpZGVyIEVDREhFLgogICBbUkZDNTQ4OV0gZGVzY3JpYmVzIHRoZSB1c2Ugb2YgUFNLIGlu
IGNvbWJpbmF0aW9uIHdpdGggRUNESEUgYnV0IGRvZXMKICAgbm90IGNvbnNpZGVyIEFFUy1HQ00g
b3IgQUVTLUNDTS4KCjMuICBFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhl
ciBTdWl0ZXMKCiAgIFRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBh
cmUgYmFzZWQgb24gdGhlIEFFUy1HQ00KICAgYW5kIEFFUy1DQ00gQXV0aGVudGljYXRlZCBFbmNy
eXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKQogICBhbGdvcml0aG1zIEFFQURfQUVT
XzEyOF9HQ00sIEFFQURfQUVTXzI1Nl9HQ00gYW5kIEFFQURfQUVTXzEyOF9DQ00KICAgZGVmaW5l
ZCBpbiBbUkZDNTExNl0sIGFuZCBBRUFEX0FFU18xMjhfQ0NNXzggZGVmaW5lZCBpbiBbUkZDNjY1
NV0uCgogICBNZXNzYWdlcyBhbmQgcHJlLW1hc3RlciBzZWNyZXQgY29uc3RydWN0aW9uIGluIHRo
aXMgZG9jdW1lbnQgYXJlCiAgIGRlZmluZWQgaW4gW1JGQzU0ODldLiAgVGhlIFNlcnZlcktleUV4
Y2hhbmdlIGFuZCBDbGllbnRLZXlFeGNoYW5nZQogICBtZXNzYWdlcyBhcmUgdXNlZCBhbmQgdGhl
IHByZS1tYXN0ZXIgc2VjcmV0IGlzIGNvbXB1dGVkIGFzIGZvciB0aGUKICAgRUNESEVfUFNLIGtl
eSBleGNoYW5nZS4gIFRoZSBlbGxpcHRpYyBjdXJ2ZSBwYXJhbWV0ZXJzIHVzZWQgaW4gaW4gdGhl
CiAgIERpZmZpZS1IZWxsbWFuIHBhcmFtZXRlcnMgYXJlIG5lZ290aWF0ZWQgdXNpbmcgZXh0ZW5z
aW9ucyBkZWZpbmVkIGluCiAgIFtJLUQuaWV0Zi10bHMtcmZjNDQ5MmJpc10uCgogICBGb3IgVExT
IDEuMiwgdGhlIGZvbGxvd2luZyBjaXBoZXIgc3VpdGVzIGFyZSBkZWZpbmVkOgoKICAgVExTX0VD
REhFX1BTS19XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiAgID0gezB4VEJELDB4VEJEfTsKICAgVExT
X0VDREhFX1BTS19XSVRIX0FFU18yNTZfR0NNX1NIQTM4NCAgID0gezB4VEJELDB4VEJEfTsKICAg
VExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhfQ0NNXzhfU0hBMjU2ID0gezB4VEJELDB4VEJEfTsK
ICAgVExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhfQ0NNX1NIQTI1NiAgID0gezB4VEJELDB4VEJE
fTsKCiAgIFRoZSBhc3NpZ25lZCBjb2RlIHBvaW50cyBjYW4gb25seSBiZSB1c2VkIGZvciBUTFMg
MS4yLgoKNC4gIEFwcGxpY2FibGUgVExTIFZlcnNpb25zCgogICBUaGUgY2lwaGVyIHN1aXRlcyBk
ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgTVVTVCBOT1QgYmUgbmVnb3RpYXRlZCBmb3IKICAgYW55
IHZlcnNpb24gb2YgKEQpVExTIG90aGVyIHRoYW4gVExTIDEuMi4gIENsaWVudHMgTVVTVCBOT1Qg
b2ZmZXIgb25lCiAgIG9mIHRoZXNlIGNpcGhlciBzdWl0ZXMgd2l0aCBhIChEKVRMUyB2ZXJzaW9u
IHRoYXQgZGlmZmVycyBmcm9tIFRMUwogICAxLjIuICBTZXJ2ZXJzIE1VU1QgTk9UIHNlbGVjdCBv
bmUgb2YgdGhlc2UgY2lwaGVyIHN1aXRlcyB3aXRoIGEgVExTCiAgIHZlcnNpb24gdGhhdCBkaWZm
ZXJzIGZyb20gVExTIDEuMi4gIEEgY2xpZW50IE1VU1QgdHJlYXQgdGhlIHNlbGVjdGlvbgogICBv
ZiB0aGVzZSBjaXBoZXIgc3VpdGVzIGluIGNvbWJpbmF0aW9uIHdpdGggYSB2ZXJzaW9uIG9mIFRM
UyBhcyBhbgogICBlcnJvciBhbmQgZ2VuZXJhdGUgYSBmYXRhbCAnaWxsZWdhbF9wYXJhbWV0ZXIn
IFRMUyBhbGVydC4KCgoKCk1hdHRzc29uICYgTWlnYXVsdCAgICAgIEV4cGlyZXMgTm92ZW1iZXIg
MjQsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg
ICAgICAgRUNESEVfUFNLX0FFQUQgICAgICAgICAgICAgICAgICAgICBNYXkgMjAxNwoKCiAgIFRM
UyB2ZXJzaW9uIDEuMyBhbmQgbGF0ZXIgbmVnb3RpYXRlIHRoZXNlIGZlYXR1cmVzIGluIGEgZGlm
ZmVyZW50CiAgIG1hbm5lci4gIFVubGlrZSBUTFMgMS4yLCBUTFMgMS4zIHNlcGFyYXRlcyBhdXRo
ZW50aWNhdGlvbiBhbmQgY2lwaGVyCiAgIHN1aXRlIG5lZ290aWF0aW9uIFtJLUQuaWV0Zi10bHMt
dGxzMTNdIFNlY3Rpb24gMS4yLiAgVExTIDEuMyBzdXBwb3J0cwogICBQU0sgd2l0aCBFQ0RIRSBr
ZXkgZXhjaGFuZ2UgYW5kIHRoZSBjaXBoZXIgc3VpdGVzCiAgIFRMU19BRVNfMTI4X0dDTV9TSEEy
NTYsIFRMU19BRVNfMjU2X0dDTV9TSEEzODQsCiAgIFRMU19BRVNfMTI4X0NDTV84X1NIQTI1NiBh
bmQgVExTX0FFU18xMjhfQ0NNX1NIQTI1NiBhcmUgcGFydCBvZiB0aGUKICAgc3BlY2lmaWNhdGlv
bi4gIEFzIGEgcmVzdWx0LCBUTFMgMS4zIGFuZCBoaWdoZXIgdmVyc2lvbnMsIG5lZ290aWF0ZQog
ICBhbmQgc3VwcG9ydCB0aGVzZSBjaXBoZXIgc3VpdGVzIGluIGEgZGlmZmVyZW50IHdheS4KCiAg
IFRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBtYWtlIHVzZSBvZiB0
aGUKICAgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIHdpdGggYWRkaXRpb25hbCBkYXRhIChBRUFE
KSBkZWZpbmVkIGluIFRMUwogICAxLjIgW1JGQzUyNDZdIGFuZCBEVExTIDEuMiBbUkZDNjM0N10u
ICBFYXJsaWVyIHZlcnNpb25zIG9mIFRMUyBkbyBub3QKICAgaGF2ZSBzdXBwb3J0IGZvciBBRUFE
IGFuZCBjb25zZXF1ZW50bHksIHRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4KICAgdGhpcyBk
b2N1bWVudCBNVVNUIE5PVCBiZSBuZWdvdGlhdGVkIGluIFRMUyB2ZXJzaW9ucyBwcmlvciB0byAx
LjIuCiAgIEluIGFkZGl0aW9uLCBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBUTFMgMS4wIFtSRkMy
MjQ2XSBhbmQgVExTIDEuMgogICBbUkZDNDM0Nl0gc3BsaXQgdGhlIHByZS1tYXN0ZXIgaW50byB0
d28gcGFydHMuICBUaGUgUFJGIHJlc3VsdHMgZnJvbQogICBtaXhpbmcgdGhlIHR3byBwc2V1ZG9y
YW5kb20gc3RyZWFtcyB3aXRoIGRpc3RpbmN0IGhhc2ggZnVuY3Rpb25zIChNRDUKICAgYW5kIFNI
QS0xKSBieSBleGNsdXNpdmUtT1JpbmcgdGhlbSB0b2dldGhlci4gIEluIHRoZSBjYXNlIG9mCiAg
IEVDREhFX1BTSyBhdXRoZW50aWNhdGlvbiwgdGhlIFBTSyBhbmQgRUNESEUgc2hhcmVkIHNlY3Jl
dCBhcmUgdHJlYXRlZAogICBieSBkaXN0aW5jdCBoYXNoIGZ1bmN0aW9uIHdpdGggZGlzdGluY3Qg
cHJvcGVydGllcy4gIFRoaXMgbWF5CiAgIGludHJvZHVjZSB2dWxuZXJhYmlsaXRpZXMgb3ZlciB0
aGUgZXhwZWN0ZWQgc2VjdXJpdHkgcHJvdmlkZWQgYnkgdGhlCiAgIGNvbnN0cnVjdGVkIHByZS1t
YXN0ZXIuICBBcyBzdWNoLCBhbGwgRUNESEVfUFNLIGNpcGhlcnMsIGluY2x1ZGluZwogICB0aG9z
ZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsIFNIT1VMRCBOT1QgYmUgbmVnb3RpYXRlZCBpbiBU
TFMKICAgdmVyc2lvbnMgcHJpb3IgdG8gMS4yLgoKNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAg
IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIG5ldyBjaXBoZXIgc3VpdGVzLCB3
aG9zZSB2YWx1ZXMKICAgaGF2ZSBiZWVuIGFzc2lnbmVkIGluIHRoZSBUTFMgQ2lwaGVyIFN1aXRl
IFJlZ2lzdHJ5IGRlZmluZWQgYnkKICAgW1JGQzUyNDZdLgoKICAgVExTX0VDREhFX1BTS19XSVRI
X0FFU18xMjhfR0NNX1NIQTI1NiAgID0gezB4VEJEOyAweFRCRH0gezB4RDAsMHgwMX07CiAgIFRM
U19FQ0RIRV9QU0tfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQgICA9IHsweFRCRDsgMHhUQkR9IHsw
eEQwLDB4MDJ9OwogICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9DQ01fOF9TSEEyNTYgPSB7
MHhUQkQ7IDB4VEJEfSB7MHhEMCwweDAzfTsKICAgVExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhf
Q0NNX1NIQTI1NiAgID0gezB4VEJEOyAweFRCRH0gezB4RDAsMHgwNX07CgogICBOT1RFIFRPIFRI
RSBSRkMgRURJVE9SOiBQTEVBU0UgUkVNT1ZFIFRISVMgUEFSQUdSQVBILiAgVGhlIGNpcGhlcgog
ICBzdWl0ZSBudW1iZXJzIGxpc3RlZCBpbiB0aGUgbGFzdCBjb2x1bW4gYXJlIG51bWJlcnMgdXNl
ZCBmb3IgY2lwaGVyCiAgIHN1aXRlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhbmQgaXQncyBz
dWdnZXN0ZWQgdGhhdCBJQU5BIHVzZSB0aGVzZQogICB2YWx1ZXMgZm9yIGFzc2lnbm1lbnQuCgo2
LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u
cyBpbiBUTFMgMS4yIFtSRkM1MjQ2XSwgRFRMUyAxLjIgW1JGQzYzNDddLAogICBQU0sgQ2lwaGVy
c3VpdGVzIGZvciBUTFMgW1JGQzQyNzldLCBFQ0RIRV9QU0sgW1JGQzU0ODldLCBBRVMtR0NNCiAg
IFtSRkM1Mjg4XSwgYW5kIEFFUy1DQ00gW1JGQzY2NTVdIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQg
YXMgd2VsbC4KCgoKCgpNYXR0c3NvbiAmIE1pZ2F1bHQgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI0
LCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg
ICAgIEVDREhFX1BTS19BRUFEICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTcKCgogICBBbGwg
dGhlIGNpcGhlciBzdWl0ZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IHByb3ZpZGUKICAgY29u
ZmlkZW50aWFsaXR5LCBtdXR1YWwgYXV0aGVudGljYXRpb24sIGFuZCBmb3J3YXJkIHNlY3JlY3ku
ICBUaGUKICAgQUVTLTEyOCBjaXBoZXIgc3VpdGVzIHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBh
bmQgdGhlIEFFUy0yNTYgY2lwaGVyCiAgIHN1aXRlcyBwcm92aWRlIGF0IGxlYXN0IDE5Mi1iaXQg
c2VjdXJpdHkuICBIb3dldmVyLCBBRVNfMTI4X0NDTV84CiAgIG9ubHkgcHJvdmlkZXMgNjQtYml0
IHNlY3VyaXR5IGFnYWluc3QgbWVzc2FnZSBmb3JnZXJ5LgoKICAgVGhlIFByZS1TaGFyZWQgS2V5
cyB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBNVVNUIGhhdmUgYSBzZWN1cml0eQogICBsZXZlbCBl
cXVhbCBvciBoaWdoZXIgdGhhbiB0aGUgY2lwaGVyIHN1aXRlIHVzZWQsIGkuZS4sIGF0IGxlYXN0
CiAgIDEyOC1iaXQgZm9yIHRoZSBBRVMtMTI4IGNpcGhlciBzdWl0ZXMgYW5kIGF0IGxlYXN0IDE5
Mi1iaXQgZm9yIHRoZQogICBBRVMtMjU2IGNpcGhlciBzdWl0ZXMuCgogICBHQ00gb3IgQ0NNIGVu
Y3J5cHRpb24gLSBldmVuIG9mIGRpZmZlcmVudCBjbGVhciB0ZXh0IC0gcmUtdXNpbmcgYQogICBu
b25jZSB3aXRoIGEgc2FtZSBrZXkgdW5kZXJtaW5lcyB0aGUgc2VjdXJpdHkgb2YgR0NNIGFuZCBD
Q00uICBBcyBhCiAgIHJlc3VsdCwgR0NNIGFuZCBDQ00gTVVTVCBvbmx5IGJlIHVzZWQgd2l0aCBh
IHN5c3RlbSBndWFyYW50ZWVpbmcKICAgbm9uY2UgdW5pcXVlbmVzcyBbUkZDNTExNl0uCgo3LiAg
QWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBJbGFy
aSBMaXVzdmFhcmEsIEVyaWMgUmVzY29ybGEsIERhbgogICBIYXJraW5zLCBSdXNzIEhvdXNsZXks
IERhbiBIYXJraW5zLCBNYXJ0aW4gVGhvbXNvbiwgTmlrb3MKICAgTWF2cm9naWFubm9wb3Vsb3Ms
IFBldGVyIERldHRtYW4sIFhpYW95aW4gTGl1LCBKb3NlcGggU2Fsb3dleSwgU2VhbgogICBUdXJu
ZXIgRGF2ZSBHYXJyZXR0LCBNYXJ0aW4gUmV4IGFuZCBLYXRobGVlbiBNb3JpYXJ0eSBmb3IgdGhl
aXIKICAgdmFsdWFibGUgY29tbWVudHMgYW5kIGZlZWRiYWNrLgoKOC4gIFJlZmVyZW5jZXMKCjgu
MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmlldGYtdGxzLXJmYzQ0OTJiaXNdCiAg
ICAgICAgICAgICAgTmlyLCBZLiwgSm9zZWZzc29uLCBTLiwgYW5kIE0uIFBlZ291cmllLUdvbm5h
cmQsICJFbGxpcHRpYwogICAgICAgICAgICAgIEN1cnZlIENyeXB0b2dyYXBoeSAoRUNDKSBDaXBo
ZXIgU3VpdGVzIGZvciBUcmFuc3BvcnQgTGF5ZXIKICAgICAgICAgICAgICBTZWN1cml0eSAoVExT
KSBWZXJzaW9ucyAxLjIgYW5kIEVhcmxpZXIiLCBkcmFmdC1pZXRmLXRscy0KICAgICAgICAgICAg
ICByZmM0NDkyYmlzLTE3ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTcuCgogICBbSS1ELmll
dGYtdGxzLXRsczEzXQogICAgICAgICAgICAgIFJlc2NvcmxhLCBFLiwgIlRoZSBUcmFuc3BvcnQg
TGF5ZXIgU2VjdXJpdHkgKFRMUykgUHJvdG9jb2wKICAgICAgICAgICAgICBWZXJzaW9uIDEuMyIs
IGRyYWZ0LWlldGYtdGxzLXRsczEzLTIwICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAg
ICBBcHJpbCAyMDE3LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3Ig
dXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi
LCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBN
YXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v
cmZjMjExOT4uCgogICBbUkZDMjI0Nl0gIERpZXJrcywgVC4gYW5kIEMuIEFsbGVuLCAiVGhlIFRM
UyBQcm90b2NvbCBWZXJzaW9uIDEuMCIsCiAgICAgICAgICAgICAgUkZDIDIyNDYsIERPSSAxMC4x
NzQ4Ny9SRkMyMjQ2LCBKYW51YXJ5IDE5OTksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZj
LWVkaXRvci5vcmcvaW5mby9yZmMyMjQ2Pi4KCgoKCk1hdHRzc29uICYgTWlnYXVsdCAgICAgIEV4
cGlyZXMgTm92ZW1iZXIgMjQsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0
LURyYWZ0ICAgICAgICAgICAgICAgRUNESEVfUFNLX0FFQUQgICAgICAgICAgICAgICAgICAgICBN
YXkgMjAxNwoKCiAgIFtSRkM0Mjc5XSAgRXJvbmVuLCBQLiwgRWQuIGFuZCBILiBUc2Nob2Zlbmln
LCBFZC4sICJQcmUtU2hhcmVkIEtleQogICAgICAgICAgICAgIENpcGhlcnN1aXRlcyBmb3IgVHJh
bnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIiwKICAgICAgICAgICAgICBSRkMgNDI3OSwgRE9J
IDEwLjE3NDg3L1JGQzQyNzksIERlY2VtYmVyIDIwMDUsCiAgICAgICAgICAgICAgPGh0dHA6Ly93
d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0Mjc5Pi4KCiAgIFtSRkM0MzQ2XSAgRGllcmtzLCBU
LiBhbmQgRS4gUmVzY29ybGEsICJUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5CiAgICAgICAg
ICAgICAgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjEiLCBSRkMgNDM0NiwKICAgICAgICAgICAg
ICBET0kgMTAuMTc0ODcvUkZDNDM0NiwgQXByaWwgMjAwNiwKICAgICAgICAgICAgICA8aHR0cDov
L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQzNDY+LgoKICAgW1JGQzUxMTZdICBNY0dyZXcs
IEQuLCAiQW4gSW50ZXJmYWNlIGFuZCBBbGdvcml0aG1zIGZvciBBdXRoZW50aWNhdGVkCiAgICAg
ICAgICAgICAgRW5jcnlwdGlvbiIsIFJGQyA1MTE2LCBET0kgMTAuMTc0ODcvUkZDNTExNiwgSmFu
dWFyeSAyMDA4LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v
cmZjNTExNj4uCgogICBbUkZDNTI0Nl0gIERpZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAiVGhl
IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQogICAgICAgICAgICAgIChUTFMpIFByb3RvY29sIFZl
cnNpb24gMS4yIiwgUkZDIDUyNDYsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzUyNDYs
IEF1Z3VzdCAyMDA4LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu
Zm8vcmZjNTI0Nj4uCgogICBbUkZDNTI4OF0gIFNhbG93ZXksIEouLCBDaG91ZGh1cnksIEEuLCBh
bmQgRC4gTWNHcmV3LCAiQUVTIEdhbG9pcwogICAgICAgICAgICAgIENvdW50ZXIgTW9kZSAoR0NN
KSBDaXBoZXIgU3VpdGVzIGZvciBUTFMiLCBSRkMgNTI4OCwKICAgICAgICAgICAgICBET0kgMTAu
MTc0ODcvUkZDNTI4OCwgQXVndXN0IDIwMDgsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZj
LWVkaXRvci5vcmcvaW5mby9yZmM1Mjg4Pi4KCiAgIFtSRkM2MzQ3XSAgUmVzY29ybGEsIEUuIGFu
ZCBOLiBNb2RhZHVndSwgIkRhdGFncmFtIFRyYW5zcG9ydCBMYXllcgogICAgICAgICAgICAgIFNl
Y3VyaXR5IFZlcnNpb24gMS4yIiwgUkZDIDYzNDcsIERPSSAxMC4xNzQ4Ny9SRkM2MzQ3LAogICAg
ICAgICAgICAgIEphbnVhcnkgMjAxMiwgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y
ZmM2MzQ3Pi4KCiAgIFtSRkM2NjU1XSAgTWNHcmV3LCBELiBhbmQgRC4gQmFpbGV5LCAiQUVTLUND
TSBDaXBoZXIgU3VpdGVzIGZvcgogICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0
eSAoVExTKSIsIFJGQyA2NjU1LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM2NjU1LCBK
dWx5IDIwMTIsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y
ZmM2NjU1Pi4KCjguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkM0NDkyXSAgQmxh
a2UtV2lsc29uLCBTLiwgQm9seWFyZCwgTi4sIEd1cHRhLCBWLiwgSGF3aywgQy4sIGFuZCBCLgog
ICAgICAgICAgICAgIE1vZWxsZXIsICJFbGxpcHRpYyBDdXJ2ZSBDcnlwdG9ncmFwaHkgKEVDQykg
Q2lwaGVyIFN1aXRlcwogICAgICAgICAgICAgIGZvciBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkg
KFRMUykiLCBSRkMgNDQ5MiwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNDQ5MiwgTWF5
IDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0
NDkyPi4KCiAgIFtSRkM1NDg3XSAgQmFkcmEsIE0uLCAiUHJlLVNoYXJlZCBLZXkgQ2lwaGVyIFN1
aXRlcyBmb3IgVExTIHdpdGggU0hBLQogICAgICAgICAgICAgIDI1Ni8zODQgYW5kIEFFUyBHYWxv
aXMgQ291bnRlciBNb2RlIiwgUkZDIDU0ODcsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JG
QzU0ODcsIE1hcmNoIDIwMDksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5v
cmcvaW5mby9yZmM1NDg3Pi4KCgoKCgoKTWF0dHNzb24gJiBNaWdhdWx0ICAgICAgRXhwaXJlcyBO
b3ZlbWJlciAyNCwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg
ICAgICAgICAgICAgICBFQ0RIRV9QU0tfQUVBRCAgICAgICAgICAgICAgICAgICAgIE1heSAyMDE3
CgoKICAgW1JGQzU0ODldICBCYWRyYSwgTS4gYW5kIEkuIEhhamplaCwgIkVDREhFX1BTSyBDaXBo
ZXIgU3VpdGVzIGZvcgogICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExT
KSIsIFJGQyA1NDg5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM1NDg5LCBNYXJjaCAy
MDA5LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTQ4
OT4uCgogICBbUkZDNzI1Ml0gIFNoZWxieSwgWi4sIEhhcnRrZSwgSy4sIGFuZCBDLiBCb3JtYW5u
LCAiVGhlIENvbnN0cmFpbmVkCiAgICAgICAgICAgICAgQXBwbGljYXRpb24gUHJvdG9jb2wgKENv
QVApIiwgUkZDIDcyNTIsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzcyNTIsIEp1bmUg
MjAxNCwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcy
NTI+LgoKICAgW1JGQzc1MjVdICBTaGVmZmVyLCBZLiwgSG9seiwgUi4sIGFuZCBQLiBTYWludC1B
bmRyZSwKICAgICAgICAgICAgICAiUmVjb21tZW5kYXRpb25zIGZvciBTZWN1cmUgVXNlIG9mIFRy
YW5zcG9ydCBMYXllcgogICAgICAgICAgICAgIFNlY3VyaXR5IChUTFMpIGFuZCBEYXRhZ3JhbSBU
cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkKICAgICAgICAgICAgICAoRFRMUykiLCBCQ1AgMTk1LCBS
RkMgNzUyNSwgRE9JIDEwLjE3NDg3L1JGQzc1MjUsIE1heQogICAgICAgICAgICAgIDIwMTUsIDxo
dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzUyNT4uCgogICBbUkZDNzU0MF0gIEJl
bHNoZSwgTS4sIFBlb24sIFIuLCBhbmQgTS4gVGhvbXNvbiwgRWQuLCAiSHlwZXJ0ZXh0CiAgICAg
ICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgVmVyc2lvbiAyIChIVFRQLzIpIiwgUkZDIDc1NDAs
CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc1NDAsIE1heSAyMDE1LAogICAgICAgICAg
ICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzU0MD4uCgpBdXRob3JzJyBB
ZGRyZXNzZXMKCiAgIEpvaG4gTWF0dHNzb24KICAgRXJpY3Nzb24gQUIKICAgU0UtMTY0IDgwIFN0
b2NraG9sbQogICBTd2VkZW4KCiAgIFBob25lOiArNDYgNzYgMTE1IDM1IDAxCiAgIEVtYWlsOiBq
b2huLm1hdHRzc29uQGVyaWNzc29uLmNvbQoKCiAgIERhbmllbCBNaWdhdWx0CiAgIEVyaWNzc29u
CiAgIDg0MDAgYm91bGV2YXJkIERlY2FyaWUKICAgTW9udHJlYWwsIFFDICAgSDRQIDJOMgogICBD
YW5hZGEKCiAgIFBob25lOiArMSA1MTQtNDUyLTIxNjAKICAgRW1haWw6IGRhbmllbC5taWdhdWx0
QGVyaWNzc29uLmNvbQoKCgoKCgoKCgoKCk1hdHRzc29uICYgTWlnYXVsdCAgICAgIEV4cGlyZXMg
Tm92ZW1iZXIgMjQsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA3XQo=
--001a11412d3c8cca6305503bfc78--


From nobody Tue May 23 19:42:20 2017
Return-Path: 
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 ECB171286D6; Tue, 23 May 2017 19:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F6mUOTVBzPPs; Tue, 23 May 2017 19:42:17 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E892126CC4; Tue, 23 May 2017 19:42:17 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id 99so59577423lfu.1; Tue, 23 May 2017 19:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lqLrGbmUEMpJxATjZ1QV1tvEiOCu8RlKcNY4qtfWqKY=; b=lVuQguDzyuvc2VHS+Q9W8ripkVhZgx8/MrR38+/+rtWFjx5EEp559FRyAouoXW0CVl zty/vgsEvIsYRJEX7YhJJjrmmNWi1eCUAi9f3MWLnzl+D7C4Mv46jX3G3nAxnspKDSgR 0VZHLE3RUXEtAUj6eQJW8GgQRbFFhIblUGySu5yrUt4/jTy3ZOiw/RE2aZV7NLPlGs5a omjsLs489Jw+gc4bYIZ6wkrUDlZChYsj3gmq0MhpGFJ2KHKx/eEz1fXbH49USbiOP37q znqVy+09Z4DKhbciPICknFfXuwLsAqrt41Yr+9D8/Mdx4vDw8VQaMf3T9sDWxEnfKR9o dhZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lqLrGbmUEMpJxATjZ1QV1tvEiOCu8RlKcNY4qtfWqKY=; b=InMh1rL4BfRbh+zcOiuzNuWdzPrrggSvHCTfF0mV3zZtBuZu7i8yUQ9K2hFNkNLP9A Xkl+IHenoTRQd6RAmoCYXwk4tGRUe5P1DxDsv6SphmXKKCTjTnB0OhrA24PE9gbal0uY DQONX8Nge9Urg8pN9tFhfKBBHc2y9SX9FvRmZ6dwWggqotcUXm4u5VpndZHE8hWFVlJL k/GML4WJkHhRp0fD8lDarYct6/2sGCsVypxPnKXgc4UpWgcxDpTojMS6ICI5AIuHj9Q9 HBA0yHXjD2+8xhVo6PyThVJSYsUnRQRAakdHrCm2oAg72hKvk6lbVlYTK6nWM2FVzZha UYBA==
X-Gm-Message-State: AODbwcBjwUJLfydjwJz0mdqZFeB7qKSID5xd1xbKtz06FkZSKAQh8otz WLaLBW/7oZVZoON9uDnMSiWzo7o/pQ==
X-Received: by 10.25.145.88 with SMTP id y24mr7743537lfj.14.1495593735436; Tue, 23 May 2017 19:42:15 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 19:42:14 -0700 (PDT)
In-Reply-To: <149557756331.28529.11248340972147793467.idtracker@ietfa.amsl.com>
References: <149557756331.28529.11248340972147793467.idtracker@ietfa.amsl.com>
From: Daniel Migault 
Date: Tue, 23 May 2017 22:42:14 -0400
X-Google-Sender-Auth: zcDRa0hRFE9SZ9rkvhpwDKvQJOE
Message-ID: 
To: Ben Campbell 
Cc: The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org,  Joseph Salowey , tls-chairs , tls 
Content-Type: multipart/alternative; boundary="94eb2c1cdb3c54401f05503c0d6b"
Archived-At: 
Subject: Re: [TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 02:42:19 -0000

--94eb2c1cdb3c54401f05503c0d6b
Content-Type: text/plain; charset="UTF-8"

Hi,
Thanks for your review. I believe version 05 address Eric comments..
Yours,
Daniel

On Tue, May 23, 2017 at 6:12 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Ekr's DISCUSS position.
>
>
>

--94eb2c1cdb3c54401f05503c0d6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, 
Thanks for your review. I bel=
ieve version 05 address Eric comments.. 
Yours, 
Daniel

On Tue, M=
ay 23, 2017 at 6:12 PM, Ben Campbell <ben@nostrum.com> wrote:<=
br>
Ben Campbell has entered the following ba=
llot position for

draft-ietf-tls-ecdhe-psk-aead-04: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc=
/draft-ietf-tls-ecdhe-psk-aead/







-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



I support Ekr's DISCUSS position.









--94eb2c1cdb3c54401f05503c0d6b--


From nobody Tue May 23 19:48:24 2017
Return-Path: 
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 7A12C129453 for ; Tue, 23 May 2017 19:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 pCbGIWj4z0op for ; Tue, 23 May 2017 19:48:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE48C126C25 for ; Tue, 23 May 2017 19:48:14 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4O2mAtD018837 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 21:48:11 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Daniel Migault , Martin Thomson 
Cc: "mrex@sap.com" , tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org, The IESG , tls 
References: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com> <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp>   
From: Adam Roach 
Message-ID: <25caac84-190f-cc51-848b-a7b2e9ee6f17@nostrum.com>
Date: Tue, 23 May 2017 21:48:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 02:48:17 -0000

On 5/23/17 9:33 PM, Daniel Migault wrote:
> The current version does not consider that proposing the cipher suites 
> of the document implicitly assumes the client supports TLS1.2.

Really? Can you clarify the meaning of the following passage? Because I 
can't read it in any way other than to contradict your assertion above:


    A server receiving a ClientHello and a client_version indicating
    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
    this document in ClientHello.cipher_suites can safely assume that the
    client supports TLS 1.2 and is willing to use it.



/a


From nobody Tue May 23 21:09:51 2017
Return-Path: 
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 08A0B128B91; Tue, 23 May 2017 21:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WD7ADE4dUPph; Tue, 23 May 2017 21:09:39 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C081D12717E; Tue, 23 May 2017 21:09:38 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id a5so46825822lfh.2; Tue, 23 May 2017 21:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ER1/5RAuT1Bks4JkbSx7qc+Jx0HbPU0FabJy4Se8sPE=; b=bw8wTEEYFiwTvAhLYyAFbuwI39bLFJTd2sV+KlN68HCJLUC2F+9Mn9g7aFbWzDo3Wi B/Vu1ZVxf0xnBKJ3CuWgCg08ReZ3Pljk5Nsq7A+qti0MYYrgu1ESvOZpceqyqQ74ON5C uv1mDWry0TlMq1vSRqDBK5xdBNPZ/778lHnsT4snz9V19gm068T/hv43zmdSOwAXM7Bl S333gqIcp4KLDRsHBk9R8yeBZRHIvllmJEju9NQD2yk/coKEpfJzl5lDFlzNqWTkm88m ijjv9NP1gwYukrNULTObgFJxTf24pQy7wve7NaDb/zCupBT2VzmxGVJ6nXQJq7U4frAb ACdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ER1/5RAuT1Bks4JkbSx7qc+Jx0HbPU0FabJy4Se8sPE=; b=l0ZIjMhh/tBtTrB9lyRl41G2iSraRZBIjkTN8k1R2MZG33hZnbFKi0w0m681gUHsxk Hd+9wu1vpQj0cfayJid3Ufjo1Rf50q44JwVJO0c9O/fKxI8pEkPxPqR5KXx8G4wSE/3Z 5qfBTkssj37OSCwPQxWcO+ogvn2WrN8VZdEWN+aOXFe3aHA5BIePAUbXvVr8IfaqfUKi Y73r1DNlACRZahh7JSJZnojoA5/InE5wacmExYDImEkXS95Sa/gBdXhssT99vGz2L67X 1hrN+kb38d0WPPCm8zQqTYooA98sI+7xScDmOvAWVwTvbYqLSsfM3rKd6LqbOeRorgOh Lfig==
X-Gm-Message-State: AODbwcAJXgRytr6P1nSHRXCqmuti9hvgNGkHM4HWJhX53H+iVuGOMr2C LysIWb5QFz9xog8c8P9aVat7shYLYf8sjdk=
X-Received: by 10.46.77.138 with SMTP id c10mr9571235ljd.103.1495598976762; Tue, 23 May 2017 21:09:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Tue, 23 May 2017 21:09:36 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>    
From: Martin Thomson 
Date: Wed, 24 May 2017 14:09:36 +1000
Message-ID: 
To: Daniel Migault 
Cc: Eric Rescorla , tls-chairs , The IESG ,  tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 04:09:42 -0000

Hi Daniel,

This removes the offending text.

This is incorrect:

> Clients MUST NOT offer one of these cipher suites with a (D)TLS version that differs from TLS 1.2.

It should be possible to offer these when attempting to negotiate TLS
1.3.  The server simply cannot negotiate these cipher suites if it
chooses to use 1.3.  I'd remove that sentence (and the one following
it, since it's redundant with the first sentence of the paragraph).

As others have noted, the paragraph about TLS 1.3 isn't helpful and
should be removed.

This:

> In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2 [RFC4346] split the pre-master into two  parts.  The PRF results from mixing the two pseudorandom streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing them together.

You mean TLS 1.1 rather than 1.2.  But as with the former paragraph,
talking about the limitations of TLS versions that you explicitly
don't support isn't useful.  Remove this paragraph also.

Nits:
s/pre-master(| secret)/premaster secret/g

You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
means to use AEAD_AES_128_GCM (and the same for the other
ciphersuites).  I mention this because the order in which the AEAD
algorithms are mentioned is different to the order of the ciphersuites
in the list.



On 24 May 2017 at 12:37, Daniel Migault  wrote:
> re-sending with the version 05 but removing the diff to be under the 100 KB
> limit.
> Yours,
> Daniel
>
> On Tue, May 23, 2017 at 9:28 PM, Daniel Migault
>  wrote:
>>
>> Hi Eric,
>>
>> Thank you for the feed backs. The version 05 contains all text changes you
>> agreed. In addition, the text explaining dictionary/brute force has been
>> removed and replace by a reference to 4279. The recommendation regarding to
>> all PSK ciphers has been limited to the one of the document.  Please see
>> inline for more details.
>>
>> For some reasons I am not able to validate the submission of version 05. I
>> have attached the diff with version 04 as well as the locally generated
>> version 05.
>>
>> Yours,
>> Daniel
>>
>> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault
>>>  wrote:
>>>>
>>>> Hi Eric,
>>>>
>>>> Thank you for your reviews. Please see my responses inline. If you agree
>>>> with the text I will update the draft.
>>>>
>>>> Yours,
>>>> Daniel
>>>>
>>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
>>>>>
>>>>> Eric Rescorla has entered the following ballot position for
>>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> The following text appears to have been added in -04
>>>>>
>>>>>    A server receiving a ClientHello and a client_version indicating
>>>>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>>>>    this document in ClientHello.cipher_suites can safely assume that
>>>>> the
>>>>>    client supports TLS 1.2 and is willing to use it.  The server MUST
>>>>>    NOT negotiate these cipher suites with TLS protocol versions earlier
>>>>>    than TLS 1.2.  Not requiring clients to indicate their support for
>>>>>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>>>>>    improves the interoperability in the installed base and use of TLS
>>>>>    1.2 AEAD cipher suites without upsetting the installed base of
>>>>>    version-intolerant TLS servers, results in more TLS handshakes
>>>>>    succeeding and obviates fallback mechanisms.
>>>>>
>>>>> This is a major technical change from -03, which, AFAIK, prohibited
>>>>> the server from negotiating these algorithms with TLS 1.1 and below
>>>>> and maintained the usual TLS version 1.2 negotiation rules.
>>>>>
>>>>> This is a very material technical change. I don't consider it wise,
>>>>> but in any case it would absolutely need WG consensus, which I
>>>>> don't believe that it has given the recent introduction.
>>>>
>>>>
>>>> I agree that the text is a technical change, and that it may not be
>>>> appropriated to do so now. The reason I included it was that it was conform
>>>> to the previous text, but I agree that implicit assumption of version 1.2
>>>> may need some additional discussion especially regarding RFC5246 Appendix E.
>>>> Unless you prefer further discussion I assume the text below address your
>>>> concern.
>>>>
>>>> The cipher suites defined in this document MUST NOT be negotiated for
>>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
>>>> these cipher suites with a (D)TLS version that differs from TLS 1.2. Servers
>>>> MUST NOT select one of these cipher suites with a TLS version that differs
>>>> from TLS 1.2. A client MUST treat the selection of these cipher suites in
>>>> combination with a version of TLS as an error and generate a fatal
>>>> 'illegal_parameter' TLS alert. 
>>>
>>>
>>> Yes, this seems fine
>>>
>>>
>>>>> The discussion of dictionary attacks here seems inferior to that
>>>>> in 4279. In particular, you only need to actively attack one
>>>>> connection to capture the data you need for a brute force attack
>>>>> despite the text there referring to trying "different keys".
>>>>> Please correct that.
>>>>>
>>>> I believe the text below address your concern:
>>>>
>>>> OLD:
>>>> Use of Pre-Shared Keys of limited entropy may allow an active
>>>> attacker attempts to connect to the server and try different keys.
>>>> For example, limited entropy may be provided by using a short PSK in
>>>> which
>>>> case an attacker may perform a brute-force attack. Another example
>>>> includes the use of a PSK  chosen by a human which thus may be exposed
>>>> to
>>>> dictionary attacks.
>>>>
>>>> NEW:
>>>> Pre-Shared Keys security relies on its associated entropy, and it is
>>>> RECOMMENDED to follow  to ensure the PSK has enough
>>>> entropy. Possible reasons for low entropy includes PSK chosen by humans or
>>>> PSK of small length as well as using random generators with limited entropy.
>>>> 
>>>>
>>>> PSK of limited entropy may allow an attacker to test different PSK
>>>> values against a valid output such as master secret or any output derived
>>>> from it. In this document, the master secret is generated using the PSK as
>>>> well as the ECDHE shared secret. The use of ECDHE limits the possibilities
>>>> of passive eavesdropping attackers, as the ECDHE shared secret is not
>>>> expected to be derived from the observed ECDH parameters. As a result,
>>>> passive eavesdropping is unlikely to happen, and the collection of all
>>>> necessary material relies on an active attack.
>>>> An active attacker may collect the necessary material by setting a TLS
>>>> session as a client with the legitimate server. One PSK is tested for each
>>>> session, and a match occurs when key exchange succeeds. On the other hand,
>>>> an active attacker may also consider gathering the necessary information for
>>>> offline computation. One way consists in getting a legitimate client to
>>>> establish a connection with the attacker. It is also assumed that the client
>>>> will accept the ECDH parameters authenticated by the attacker's private key
>>>> and finally returns the Finished message authenticating the exchange. The
>>>> attacker will be then in possession of all the necessary information to
>>>> perform a brute force attack.
>>>
>>>
>>> Is there a reason to not just point directly to the 4279 security
>>> considerations?
>>
>>
>> No, basically I tried to complete the previous text that missed the
>> offline use case. The current version just point to 4279, without having the
>> above text. If you think the text above is clarifying I can add it as well.
>>>
>>> -
>>>>
>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> The citations to TLS 1.3 still seem pretty muddled. I think you
>>>>> should just stop referencing and discussing 1.3.
>>>>
>>>>
>>>> My understanding of your comment is that mentioning TLS 1.3 to further
>>>> insisting that the code point are not valid for TLS 1.3 is confusing. I
>>>> propose to:
>>>>
>>>> Explicitly mention the TLS version in the title:
>>>>
>>>> OLD title:
>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>>>> Security (TLS)
>>>>
>>>> NEW title:
>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>>>> Security (TLS)
>>>>
>>>> OLD Introduction:
>>>>
>>>>     The cipher
>>>>    suites are defined for version 1.2 of the Transport Layer Security
>>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>>>>    Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>>>>    [I-D.ietf-tls-tls13].
>>>>
>>>> NEW introduction
>>>>
>>>> The cipher
>>>>    suites are defined for version 1.2 of the Transport Layer Security
>>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>>>>    Security (DTLS) protocol [RFC6347].
>>>>
>>>>
>>>> I suggest to keep the following text of the introduction:
>>>>
>>>>
>>>> AEAD algorithms that combine encryption and integrity protection are
>>>>    strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
>>>>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].  The AEAD
>>>>    algorithms considered in this document are AES-GCM and AES-CCM.  The
>>>>    use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
>>>>    is defined in [RFC6655].
>>>
>>>
>>> Yes, this seems fine.
>>>
>>>
>>>>
>>>> I suggest to keep the following text of the Applicable versions
>>>> sections, as I believe the section discusses the cipher suites against all
>>>> existing TLS versions. In addition, it also justifies somewhat that we only
>>>> defined cipher suites that are compatible with TLS1.3.
>>>>
>>>>    TLS version 1.3 and later negotiate these features in a different
>>>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
>>>>    suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
>>>>    PSK with ECDHE key exchange and the cipher suites
>>>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
>>>>    specification.  As a result, TLS 1.3 and higher versions, negotiate
>>>>    and support these cipher suites in a different way.
>>>
>>>
>>> OK.
>>>
>>>>
>>>> I suggest to remove the reference to TLS1.3 in the security
>>>> considerations
>>>>
>>>> OLD
>>>>
>>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
>>>>    TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM [RFC5288],
>>>>    and AES-CCM [RFC6655] apply to this document as well.
>>>>
>>>> NEW
>>>>
>>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
>>>>  ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [RFC6655] apply
>>>>  to this document as well.
>>>>>
>>>>>
>>>>> S 2.
>>>>> I'm not sure that the discussion of the PRF is helpful here in
>>>>> mandating the non-use of these cipher suites with TLS 1.1 and
>>>>> below.
>>>>
>>>>
>>>> I find the text useful as it gives an idea why even introducing AEAD in
>>>> TLS version lower than 1.2 is a bad idea, so I would prefer to keep it. The
>>>> text has been changed to
>>>>
>>>> OLD:
>>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
>>>>
>>>> NEW:
>>>> As such,  all ECDHE_PSK
>>>> ciphers, including those defined outside this document, SHOULD NOT be
>>>> negotiated in TLS versions prior to 1.2.
>>>
>>>
>>> I don't think you should be levying a new normative requirement like this
>>> for other ciphers
>>> i this document
>>
>>
>> Consideration for other ciphers has been removed. The requirement is
>> limited to the ciphers of the document. The new text is:
>>
>> As such, all ECDHE_PSK ciphers, including those defined in this document,
>> SHOULD NOT be
>> negotiated in TLS versions prior to 1.2.
>>>
>>>
>>> -Ek
>>> r
>>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Wed May 24 05:39:21 2017
Return-Path: 
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 2060C129AE5; Wed, 24 May 2017 05:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YE8M_MDoMh1Y; Wed, 24 May 2017 05:39:10 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE42129AD0; Wed, 24 May 2017 05:39:09 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id m18so66699158lfj.0; Wed, 24 May 2017 05:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qjaGb39B3jm7ADS27tVPHiL0doItOTMWjzosMz+z654=; b=Hp4RG6eKRqmKhHeczdnRO8xPdQyLI+uKouU7TlQLy6NQrhS8RcijV1yGQCG3Xp2iL0 JS+wMmobIdEfI5vvaZRCNikOmRErWVB08/Effdt5o9nuoZgevn5tw+i6F2qfeIOJLq1G 0Slvc7Kvx/qltHdViHSVvV+ZB/AGy+y2G7nmLFAyMUb6GN1cIUEn+LNHkRfKcxASzf+c gIhB4U5gq6ruXfgiX8AqVl6LswSyfM3KQ5qmv0CQvFswXiWcUoinWb6Tgoz0qoKyQ8bf CsHQFdR8Z3bRDq2+zmFJP9NG1AdCcRnRpatuzLnz+eG+DtQPcMirVK7Ia0X3GzoO6dG8 V4hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qjaGb39B3jm7ADS27tVPHiL0doItOTMWjzosMz+z654=; b=LgXWHvGiDKo6ImH4XNr5EoP9ixJoqIh6+Dw0qjjfEBtk7p8sgxgpRn9LbZa3cPqzQG 8hVOtHtaFtFxTkUQ1G/F0Xa5DjyaixgHXtzwTkjzv7weWPmT4b8EvWJXnharLmW6fOAf WH/sabUgt5dfR2vbAfmE26fY/EY9HYKc8yYt+D1P69gl2FV2gxSAlGvXOTiHd3CKLBQp 2If2EPG4YQvvsWfn31ARbcof6Ngx9Moog2HlK9z5ZQK3qJjboPja6PpTVQmdl/YbH1he e4FeYWAPDSUEgCF3Zk//fiIgsP8Jx9tPEEdPkU/TOGOemfXdR0J3I6Wn3RJM95Anzkvb Mjmg==
X-Gm-Message-State: AODbwcDlfKNY7C3LwukuCurAOZ69kpV28Vaq057ZNWMGJMjMa9TEy0Vo lvZUNNi+eHcJ4B5XHJxuqsN3Eusk2g==
X-Received: by 10.46.76.1 with SMTP id z1mr8591744lja.128.1495629548100; Wed, 24 May 2017 05:39:08 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Wed, 24 May 2017 05:39:07 -0700 (PDT)
In-Reply-To: <25caac84-190f-cc51-848b-a7b2e9ee6f17@nostrum.com>
References: <149556730804.28545.6150805815075208815.idtracker@ietfa.amsl.com> <20170523193453.CF9761A6A6@ld9781.wdf.sap.corp>    <25caac84-190f-cc51-848b-a7b2e9ee6f17@nostrum.com>
From: Daniel Migault 
Date: Wed, 24 May 2017 08:39:07 -0400
X-Google-Sender-Auth: wVnDrCUvjuArklceyHyhx5cFCjg
Message-ID: 
To: Adam Roach 
Cc: Martin Thomson , "mrex@sap.com" ,  tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org,  The IESG , tls 
Content-Type: multipart/alternative; boundary="f403045ea6daee24d60550446397"
Archived-At: 
Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 12:39:12 -0000

--f403045ea6daee24d60550446397
Content-Type: text/plain; charset="UTF-8"

Hi Adam,

The text you mention is from version 04. Version 05 has been submitted, but
is somewhere in the datatracker. For some reason I am not able to confirm
the submission, so I have attached it to my response to Eric. The text of
the current version 05 is:

Yours,
Daniel
"""
4.     Applicable TLS Versions

   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
   of these cipher suites with a (D)TLS version that differs from TLS
   1.2.  Servers MUST NOT select one of these cipher suites with a TLS
   version that differs from TLS 1.2.  A client MUST treat the selection
   of these cipher suites in combination with a version of TLS as an
   error and generate a fatal 'illegal_parameter' TLS alert.




Mattsson & Migault      Expires November 24, 2017               [Page 3]
^L
Internet-Draft               ECDHE_PSK_AEAD                     May 2017


   TLS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

   The cipher suites defined in this document make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
   [RFC4346] split the pre-master into two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and ECDHE shared secret are treated
   by distinct hash function with distinct properties.  This may
   introduce vulnerabilities over the expected security provided by the
   constructed pre-master.  As such, all ECDHE_PSK ciphers, including
   those defined in this document, SHOULD NOT be negotiated in TLS
   versions prior to 1.2.
"""

On Tue, May 23, 2017 at 10:48 PM, Adam Roach  wrote:

> On 5/23/17 9:33 PM, Daniel Migault wrote:
>
>> The current version does not consider that proposing the cipher suites of
>> the document implicitly assumes the client supports TLS1.2.
>>
>
> Really? Can you clarify the meaning of the following passage? Because I
> can't read it in any way other than to contradict your assertion above:
>
>
>    A server receiving a ClientHello and a client_version indicating
>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>    this document in ClientHello.cipher_suites can safely assume that the
>    client supports TLS 1.2 and is willing to use it.
>
>
>
> /a
>

--f403045ea6daee24d60550446397
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Adam, 

The text you mention=
 is from version 04. Version 05 has been submitted, but is somewhere in the=
 datatracker. For some reason I am not able to confirm the submission, so I=
 have attached it to my response to Eric. The text of the current version 0=
5 is:

Yours, 
Daniel
"""<=
br>4. =C2=A0=C2=A0=C2=A0 Applicable TLS Versions

=C2=A0=C2=A0 The ci=
pher suites defined in this document MUST NOT be negotiated for
=C2=A0=
=C2=A0 any version of (D)TLS other than TLS 1.2.=C2=A0 Clients MUST NOT off=
er one
=C2=A0=C2=A0 of these cipher suites with a (D)TLS version that di=
ffers from TLS
=C2=A0=C2=A0 1.2.=C2=A0 Servers MUST NOT select one of th=
ese cipher suites with a TLS
=C2=A0=C2=A0 version that differs from TLS =
1.2.=C2=A0 A client MUST treat the selection
=C2=A0=C2=A0 of these ciphe=
r suites in combination with a version of TLS as an
=C2=A0=C2=A0 error a=
nd generate a fatal 'illegal_parameter' TLS alert.



<=
br>Mattsson & Migault=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires November 24=
, 2017=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 [Page 3]
^L
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ECDHE_PSK_AEAD=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 May 2017


=C2=A0=C2=A0=
 TLS version 1.3 and later negotiate these features in a different
=C2=
=A0=C2=A0 manner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separates authentication an=
d cipher
=C2=A0=C2=A0 suite negotiation [I-D.ietf-tls-tls13] Section 1.2=
.=C2=A0 TLS 1.3 supports
=C2=A0=C2=A0 PSK with ECDHE key exchange and th=
e cipher suites
=C2=A0=C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA=
384,
=C2=A0=C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 ar=
e part of the
=C2=A0=C2=A0 specification.=C2=A0 As a result, TLS 1.3 and=
 higher versions, negotiate
=C2=A0=C2=A0 and support these cipher suites=
 in a different way.

=C2=A0=C2=A0 The cipher suites defined in this =
document make use of the
=C2=A0=C2=A0 authenticated encryption with addi=
tional data (AEAD) defined in TLS
=C2=A0=C2=A0 1.2 [RFC5246] and DTLS 1.=
2 [RFC6347].=C2=A0 Earlier versions of TLS do not
=C2=A0=C2=A0 have supp=
ort for AEAD and consequently, the cipher suites defined in
=C2=A0=C2=A0=
 this document MUST NOT be negotiated in TLS versions prior to 1.2.
=C2=
=A0=C2=A0 In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.=
2
=C2=A0=C2=A0 [RFC4346] split the pre-master into two parts.=C2=A0 The =
PRF results from
=C2=A0=C2=A0 mixing the two pseudorandom streams with d=
istinct hash functions (MD5
=C2=A0=C2=A0 and SHA-1) by exclusive-ORing t=
hem together.=C2=A0 In the case of
=C2=A0=C2=A0 ECDHE_PSK authentication=
, the PSK and ECDHE shared secret are treated
=C2=A0=C2=A0 by distinct h=
ash function with distinct properties.=C2=A0 This may
=C2=A0=C2=A0 intro=
duce vulnerabilities over the expected security provided by the
=C2=A0=
=C2=A0 constructed pre-master.=C2=A0 As such, all ECDHE_PSK ciphers, includ=
ing
=C2=A0=C2=A0 those defined in this document, SHOULD NOT be negotiate=
d in TLS
=C2=A0=C2=A0 versions prior to 1.2.
"""

O=
n Tue, May 23, 2017 at 10:48 PM, Adam Roach <adam@nostrum.com> wrote:
On 5/23/17 9:=
33 PM, Daniel Migault wrote:



The current version does not consider that proposing the cipher suites of t=
he document implicitly assumes the client supports TLS1.2.





Really? Can you clarify the meaning of the following passage? Because I can=
't read it in any way other than to contradict your assertion above:




=C2=A0 =C2=A0A server receiving a ClientHello and a client_version indicati=
ng

=C2=A0 =C2=A0(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any=
 of the cipher suites from

=C2=A0 =C2=A0this document in ClientHello.cipher_suites can safely assume t=
hat the

=C2=A0 =C2=A0client supports TLS 1.2 and is willing to use it.







/a





--f403045ea6daee24d60550446397--


From nobody Wed May 24 06:50:41 2017
Return-Path: 
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 ABA11129AA0 for ; Wed, 24 May 2017 06:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 oDGv9BNh-1C4 for ; Wed, 24 May 2017 06:50:39 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8206012EAE4 for ; Wed, 24 May 2017 06:50:39 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4ODoZa1019115; Wed, 24 May 2017 14:50:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=Q4RQCxsg3ECUYXv27K5C18jrFR2UxcTa7hgl8BiiRps=; b=jLObZI7Y3uZr+tc/g2J9Wxkrn/tCU279urdonF/099hv4ElGIg7tGl5r7ZkWTQyelbLa 8jSIjyL52cvRocVH+Wwvf/mKrTth4eWLfE0KYjTy9wkKpa21vnKaV76KdrKwcoYBw3of 7OyVRaiTdUPJqAeML8svRhcg2IDYCFk5UCV/CtYdx3vp5RRw9g/7k+BPmbZ+q2HQM/s2 BeEB8R9RTPt8zT4u/esCEdOK+WeT27C3O+t/UCleCc9EYvvPPM8Sx2oGX+hgHIo6zyCD sAXoMvWnOcBoW/e83eUhd9pBPmrbqyZuc4bsD9zGXWgwbLzDAA8wLiwNRPFggXYDsltV hQ== 
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2anbc880f3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 May 2017 14:50:34 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4ODk3cU005815; Wed, 24 May 2017 09:50:08 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ajh4uvs5t-1; Wed, 24 May 2017 09:50:08 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9F7571FC7B; Wed, 24 May 2017 13:50:07 +0000 (GMT)
To: Eric Rescorla , Ilari Liusvaara 
Cc: "tls@ietf.org" 
References:       <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Benjamin Kaduk 
Message-ID: <071fb4df-56e6-d82a-87de-3db084235021@akamai.com>
Date: Wed, 24 May 2017 08:50:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DB91F68371C423C52CFCD43C"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705240067
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705240066
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 13:50:40 -0000

This is a multi-part message in MIME format.
--------------DB91F68371C423C52CFCD43C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 05/21/2017 05:47 PM, Eric Rescorla wrote:
>
>
> On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara
> > wrote:
>
>     On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
>      
>
>     - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>
>
> I don't understand the purpose of this requirement. As you note below,
> servers are ultimately responsible for enforcing it, and it's not clear to
> me why clients obeying it makes life easier for the server.
>

I think it's just an attempt to make clear what the client behavior
should be.  It's like when we say that implementations MUST NOT put more
than one extension of the same type in a given extension block.  The
peer has to validate received messages, but the local implementation has
to know to not generate them, either.

>  
>
>     - Servers MAY accept the same ticket multiple times.
>
>
> This seems implicit.
>

It seems implicit to me, as well, though I'm not sure that there's harm
in saying it explicitly, particularly when reusing a ticket is a MUST
NOT in certain specific cases (0-RTT).

>  
>
>     - Servers MUST NOT accept the same ticket with the same binder
>     multiple
>       times for 0-RTT (if any part of ClientHello covered by binder is
>       different, one can assume binders are different). This holds even
>       across servers (i.e., if server1 accepts 0-RTT with ticket X and
>       binder Y, then server2 can not accept 0-RTT with ticket X and binder
>       Y).
>
>
> I assume that what you have in mind here is that the server would know
> which tickets it was authoritative for anti-replay and would simply reject
> 0-RTT if it wasn't authoritative? This seems like it would
> significantly cut
> down on mass replays, though it would of course still make
> application-level
> replay a problem.
>

Right, this would bring replays down from the millions hypothesized for
the weak time-based thing to more like tens, which is kind of in the
regime that we are currently in with (at least some) application behavior.

> I'm happy to write this up as part of the first two techniques. I'd be 
> interested in hearing from others in the WG what they think about:
>

I think it's worth writing up the most-secure scheme(s) we know of, to
give us some concrete text to digest and decide if we can live with.

> 1. Requiring it.
> 2. Whether they still want to retain the stateless technique.
>

If we think we can require it and have it actually stick, that seems
like the safest plan.  The results of this discussion leave me uneasy
with a scheme that permits millions of replays, even if there is not
something concrete that I definitely object to.  As DKG (almost) said,
"we're designing a security protocol, not an easy-to-implement
protocol".  I'm still concerned that if we put MUST it will be more RFC
6919 than 2119, though, even if clients and/or ssllabs try to grease
it.  So, if we require it, then the stateless technique is not needed
per se (but we still want the time limit so as to bound the size of a
strike register).  If we don't/can't require it, then I would say keep
the stateless technique but try to crank down the time window and
suggest that implementations rate-limit 0-RTT acceptance per domain to
try to get away from the billions of replay regime.

Another crazy idea would be to just say that servers MUST limit the use
of a single binder to at most 100 times, with the usual case being just
once, to allow for alternative designs that have weaker distributed
consensus requirements (but still describe these current two methods as
examples of ways to do so).

-Ben


--------------DB91F68371C423C52CFCD43C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/21/2017 05:47 PM, Eric Rescorla wrote:

    

      
      


        


          
On Sat, May 20, 2017 at 6:16 AM,
            Ilari Liusvaara <ilariliusvaara@welho.com>
            wrote:

            
On Fri, May 19, 2017 at 09:59:57AM -0700, Colm
                MacCárthaigh wrote:

                 
              

            

            

              - Clients MUST NOT use the same ticket multiple times for
              0-RTT.

            

            


            

            
I don't understand the purpose of this requirement. As
              you note below,

            
servers are ultimately responsible for enforcing it,
              and it's not clear to

            
me why clients obeying it makes life easier for the
              server.

            


            

          

        

      

    

    

    I think it's just an attempt to make clear what the client behavior
    should be.  It's like when we say that implementations MUST NOT put
    more than one extension of the same type in a given extension
    block.  The peer has to validate received messages, but the local
    implementation has to know to not generate them, either.

    

    

      

        

          

            
 

            

            

              - Servers MAY accept the same ticket multiple times.

            

            


            

            
This seems implicit.

            


            

          

        

      

    

    

    It seems implicit to me, as well, though I'm not sure that there's
    harm in saying it explicitly, particularly when reusing a ticket is
    a MUST NOT in certain specific cases (0-RTT).

    

    

      

        

          

            
 

            

              - Servers MUST NOT accept the same ticket with the same
              binder multiple

                times for 0-RTT (if any part of ClientHello covered by
              binder is

                different, one can assume binders are different). This
              holds even

                across servers (i.e., if server1 accepts 0-RTT with
              ticket X and

                binder Y, then server2 can not accept 0-RTT with ticket
              X and binder

                Y).

            

            


            

            
I assume that what you have in mind here is that the
              server would know

            
which tickets it was authoritative for anti-replay and
              would simply reject

            
0-RTT if it wasn't authoritative? This seems like it
              would significantly cut

            
down on mass replays, though it would of course still
              make application-level

            
replay a problem.

            


            

          

        

      

    

    

    Right, this would bring replays down from the millions hypothesized
    for the weak time-based thing to more like tens, which is kind of in
    the regime that we are currently in with (at least some) application
    behavior.

    

    

      

        

          

            
I'm happy to write this up as part of the first two
              techniques. I'd be 

            
interested in hearing from others in the WG what they
              think about:

            


            

          

        

      

    

    

    I think it's worth writing up the most-secure scheme(s) we know of,
    to give us some concrete text to digest and decide if we can live
    with.

    

    

      

        

          

            
1. Requiring it.

            
2. Whether they still want to retain the stateless
              technique.

            

          

        

      

    

    

    If we think we can require it and have it actually stick, that seems
    like the safest plan.  The results of this discussion leave me
    uneasy with a scheme that permits millions of replays, even if there
    is not something concrete that I definitely object to.  As DKG
    (almost) said, "we're designing a security protocol, not an
    easy-to-implement protocol".  I'm still concerned that if we put
    MUST it will be more RFC 6919 than 2119, though, even if clients
    and/or ssllabs try to grease it.  So, if we require it, then the
    stateless technique is not needed per se (but we still want the time
    limit so as to bound the size of a strike register).  If we
    don't/can't require it, then I would say keep the stateless
    technique but try to crank down the time window and suggest that
    implementations rate-limit 0-RTT acceptance per domain to try to get
    away from the billions of replay regime.

    

    Another crazy idea would be to just say that servers MUST limit the
    use of a single binder to at most 100 times, with the usual case
    being just once, to allow for alternative designs that have weaker
    distributed consensus requirements (but still describe these current
    two methods as examples of ways to do so).

    

    -Ben

    

  


--------------DB91F68371C423C52CFCD43C--


From nobody Wed May 24 07:04:51 2017
Return-Path: 
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 E3885129AF1; Wed, 24 May 2017 07:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1xu0f4TTBEmd; Wed, 24 May 2017 07:04:37 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD13127F0E; Wed, 24 May 2017 07:04:36 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id a5so54638883lfh.2; Wed, 24 May 2017 07:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RGmF/47KcZWSIvADl2kgdMwk396f0vzgTP05U1prPYI=; b=W1mHqvUuq2u9ze/tLzw74M1HTo59vs6eJgTfa3+8usHgjxDDmWxSfOpM/bgnKt/80p fglNwhBvTaefjzOVfTAE125l4LqvktNbgh0gyE0e430y+2s+/1dxHp60bgKU7ZxzaeN2 TTmPtxArpIUxpjZzygcpaHF+AqaUytufgeGPs/QbjLiB4c4LVKv/wNo955+3X7vQPwH8 bO2G7nvnt1jW1MucuBKeeoVwVQ6unJ6eXMOwtYxkTB+LHQkkkQGgbuglBvwOatKPTWKi 0Cjrn111ciE650wZTkk4UxiUCZsqVEvGVQU2g9RoZ1OMIERodI0gZk0XbYFM6IkPNd1E miZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RGmF/47KcZWSIvADl2kgdMwk396f0vzgTP05U1prPYI=; b=oAiLySXZXqVKbmRm+O5F4Uo4XKZy3ODP2qB9FzoEdm7f/W/t4X63nEUKTfPcELyfXG Pr56ZMQR7KkJHS/S43gx+3zNGjVJiCpxeojn8yI9GlpIpmZIth3uNGsvyYavPuKY/KUS pvRe5j67QNOa763d2tipJoSo1GDWeBqtMJ+Zk2fKrPrLr3uoj0c4QmyAEl4VqOY5A76m gOcLixWc6P8dtnQhmtCHCChU3/vJtdrOKs/taZr7TraacM6Cu4EvlsTVLx0Z47Izp9B2 /ptHazPH/ygJemIeeCWf6Kwh7PbkddvZoG1JDB3u8BN01r6Z2cJu8jpO2R6P90HHSfpL Osnw==
X-Gm-Message-State: AODbwcD9w/TdiLDrP+tCWroq6JCU25B4/dNCmtzMoK41BsPufapixsUO pQqhJoARu758Sa6KiDT26/dmwdHTiZRM
X-Received: by 10.25.145.88 with SMTP id y24mr8577694lfj.14.1495634674668; Wed, 24 May 2017 07:04:34 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Wed, 24 May 2017 07:04:33 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>     
From: Daniel Migault 
Date: Wed, 24 May 2017 10:04:33 -0400
X-Google-Sender-Auth: W9l1OBARiLLZSVQ0R4jq2SuavqY
Message-ID: 
To: Martin Thomson 
Cc: Eric Rescorla , tls-chairs , The IESG ,  tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1cdb3c7f5ccb055045958f"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 14:04:42 -0000

--94eb2c1cdb3c7f5ccb055045958f
Content-Type: text/plain; charset="UTF-8"

Hi Martin,

Thank you for your review. Some comment were about text in the
applicability section. I think I agree with you that this section details
and clarifies  the following sentence of the previous section:  """ The
assigned code points can only be used for TLS 1.2.""". Most of the text of
this section has been added in order to address comments, thus in order to
make this section helpful for many readers, I prefer to keep most of the
text you mentioned as not useful.

Please see inline for more detail responses and let me know if that address
your comments.

Yours,
Daniel

On Wed, May 24, 2017 at 12:09 AM, Martin Thomson 
wrote:

> Hi Daniel,
>
> This removes the offending text.
>
> This is incorrect:
>
> > Clients MUST NOT offer one of these cipher suites with a (D)TLS version
> that differs from TLS 1.2.
>
> It should be possible to offer these when attempting to negotiate TLS
> 1.3.  The server simply cannot negotiate these cipher suites if it
> chooses to use 1.3.  I'd remove that sentence (and the one following
> it, since it's redundant with the first sentence of the paragraph).
>
> My understanding is that you suggest to remove "Clients MUST NOT offer one
..." for the following reasons:

A) it is redundant with the first sentence of the paragraph: "The cipher
suites defined in this document MUST NOT be negotiated ...".  This sentence
clarifies on the client side what "MUST NOT be negotiated" means, and the
same is done for the server side. If we provide clarification for the
server side, I would prefer to keep a clarification for the client side as
well.

B) It is not true as TLS1.3 enables these cipher suites to be negotiated
with TLS1.3. In the text cipher suites stands for the cipher suites code
points of the IANA registry.  Maybe we can have a better wording. However I
believe the next paragraph clarifies that TLS1.3 negotiates these ciphers
suites in a different way. Would the following wording address your
comment. If so I will update the section to remove the confusion.

"Clients MUST NOT offer one of the cipher suites code points defined in the
document with a (D)TLS version that differs from TLS 1.2."

The text in question is:
"""
   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
   of these cipher suites with a (D)TLS version that differs from TLS
   1.2.  Servers MUST NOT select one of these cipher suites with a TLS
   version that differs from TLS 1.2.  A client MUST treat the selection
   of these cipher suites in combination with a version of TLS as an
   error and generate a fatal 'illegal_parameter' TLS alert.

"""


> As others have noted, the paragraph about TLS 1.3 isn't helpful and
> should be removed.
>
>
Suggestion to remove TLS1.3 related text was to clarify that the cipher
suites were only defined for TLS1.2. Unless I missed something we have
removed most of the text that could cause confusion. On the other hand,
TLS1.3 has been designed, and we also have received comments to position
the defined cipher suites toward TLS1.3 as we do fro TLS1.0 and TLS1.1.
This is the intent of the remaining text mentioning TLS1.3.

In the applicable version section, the text for TLS1.3 is intended to
clarify why the cipher suites are restricted to TLS1.2. I believe this is
useful for readers not so familiar with TLS1.3 that may not be aware of how
TLS1.3 negotiate ciphers. My personal opinion is that it might be better to
have it explicit rather than implicit, and I would prefer to keep the text
below:

"""
   TLS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

"""




> This:
>
> > In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
> [RFC4346] split the pre-master into two  parts.  The PRF results from
> mixing the two pseudorandom streams with distinct hash functions (MD5 and
> SHA-1) by exclusive-ORing them together.
>
> You mean TLS 1.1 rather than 1.2.  But as with the former paragraph,
> talking about the limitations of TLS versions that you explicitly
> don't support isn't useful.  Remove this paragraph also.
>
>
Yes that is TLS1.1. I updated it. I believe the text is useful as it
provides a clear justification on why it should not be used on TLS version
lower than 1.2. More specifically, previous version do not support AEAD,
but this may not prevent someone using AEAD with these versions. The reason
provided is not AEAD related but PSK related. I believe it is useful to
explicitly justify why the cipher suites defined in the document should not
be used with previous TLS versions. The text has bee suggested by the
secdir and I would prefer to keep it, unless there is a strong willingness
to remove it.


> Nits:
> s/pre-master(| secret)/premaster secret/g
>

Corrected: The text only have premaster secret.


> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
> means to use AEAD_AES_128_GCM (and the same for the other
> ciphersuites).  I mention this because the order in which the AEAD
> algorithms are mentioned is different to the order of the ciphersuites
> in the list.
>
>
Unless I miss your comment, I believe the section 3 already addresses it.
If not please let me knoe what text you would like to see.

"""
3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites

   The cipher suites defined in this document are based on the AES-GCM
   and AES-CCM Authenticated Encryption with Associated Data (AEAD)
   algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
   defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].

"""

>
> On 24 May 2017 at 12:37, Daniel Migault 
> wrote:
> > re-sending with the version 05 but removing the diff to be under the 100
> KB
> > limit.
> > Yours,
> > Daniel
> >
> > On Tue, May 23, 2017 at 9:28 PM, Daniel Migault
> >  wrote:
> >>
> >> Hi Eric,
> >>
> >> Thank you for the feed backs. The version 05 contains all text changes
> you
> >> agreed. In addition, the text explaining dictionary/brute force has been
> >> removed and replace by a reference to 4279. The recommendation
> regarding to
> >> all PSK ciphers has been limited to the one of the document.  Please see
> >> inline for more details.
> >>
> >> For some reasons I am not able to validate the submission of version
> 05. I
> >> have attached the diff with version 04 as well as the locally generated
> >> version 05.
> >>
> >> Yours,
> >> Daniel
> >>
> >> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault
> >>>  wrote:
> >>>>
> >>>> Hi Eric,
> >>>>
> >>>> Thank you for your reviews. Please see my responses inline. If you
> agree
> >>>> with the text I will update the draft.
> >>>>
> >>>> Yours,
> >>>> Daniel
> >>>>
> >>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
> >>>>>
> >>>>> Eric Rescorla has entered the following ballot position for
> >>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
> >>>>>
> >>>>> When responding, please keep the subject line intact and reply to all
> >>>>> email addresses included in the To and CC lines. (Feel free to cut
> this
> >>>>> introductory paragraph, however.)
> >>>>>
> >>>>>
> >>>>> Please refer to
> >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>
> >>>>>
> >>>>> The document, along with other ballot positions, can be found here:
> >>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ----------
> >>>>> DISCUSS:
> >>>>> ------------------------------------------------------------
> ----------
> >>>>>
> >>>>> The following text appears to have been added in -04
> >>>>>
> >>>>>    A server receiving a ClientHello and a client_version indicating
> >>>>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites
> from
> >>>>>    this document in ClientHello.cipher_suites can safely assume that
> >>>>> the
> >>>>>    client supports TLS 1.2 and is willing to use it.  The server MUST
> >>>>>    NOT negotiate these cipher suites with TLS protocol versions
> earlier
> >>>>>    than TLS 1.2.  Not requiring clients to indicate their support for
> >>>>>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
> >>>>>    improves the interoperability in the installed base and use of TLS
> >>>>>    1.2 AEAD cipher suites without upsetting the installed base of
> >>>>>    version-intolerant TLS servers, results in more TLS handshakes
> >>>>>    succeeding and obviates fallback mechanisms.
> >>>>>
> >>>>> This is a major technical change from -03, which, AFAIK, prohibited
> >>>>> the server from negotiating these algorithms with TLS 1.1 and below
> >>>>> and maintained the usual TLS version 1.2 negotiation rules.
> >>>>>
> >>>>> This is a very material technical change. I don't consider it wise,
> >>>>> but in any case it would absolutely need WG consensus, which I
> >>>>> don't believe that it has given the recent introduction.
> >>>>
> >>>>
> >>>> I agree that the text is a technical change, and that it may not be
> >>>> appropriated to do so now. The reason I included it was that it was
> conform
> >>>> to the previous text, but I agree that implicit assumption of version
> 1.2
> >>>> may need some additional discussion especially regarding RFC5246
> Appendix E.
> >>>> Unless you prefer further discussion I assume the text below address
> your
> >>>> concern.
> >>>>
> >>>> The cipher suites defined in this document MUST NOT be negotiated
> for
> >>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one
> of
> >>>> these cipher suites with a (D)TLS version that differs from TLS 1.2.
> Servers
> >>>> MUST NOT select one of these cipher suites with a TLS version that
> differs
> >>>> from TLS 1.2. A client MUST treat the selection of these cipher
> suites in
> >>>> combination with a version of TLS as an error and generate a fatal
> >>>> 'illegal_parameter' TLS alert. 
> >>>
> >>>
> >>> Yes, this seems fine
> >>>
> >>>
> >>>>> The discussion of dictionary attacks here seems inferior to that
> >>>>> in 4279. In particular, you only need to actively attack one
> >>>>> connection to capture the data you need for a brute force attack
> >>>>> despite the text there referring to trying "different keys".
> >>>>> Please correct that.
> >>>>>
> >>>> I believe the text below address your concern:
> >>>>
> >>>> OLD:
> >>>> Use of Pre-Shared Keys of limited entropy may allow an active
> >>>> attacker attempts to connect to the server and try different keys.
> >>>> For example, limited entropy may be provided by using a short PSK in
> >>>> which
> >>>> case an attacker may perform a brute-force attack. Another example
> >>>> includes the use of a PSK  chosen by a human which thus may be exposed
> >>>> to
> >>>> dictionary attacks.
> >>>>
> >>>> NEW:
> >>>> Pre-Shared Keys security relies on its associated entropy, and it
> is
> >>>> RECOMMENDED to follow  to ensure the PSK has
> enough
> >>>> entropy. Possible reasons for low entropy includes PSK chosen by
> humans or
> >>>> PSK of small length as well as using random generators with limited
> entropy.
> >>>> 
> >>>>
> >>>> PSK of limited entropy may allow an attacker to test different PSK
> >>>> values against a valid output such as master secret or any output
> derived
> >>>> from it. In this document, the master secret is generated using the
> PSK as
> >>>> well as the ECDHE shared secret. The use of ECDHE limits the
> possibilities
> >>>> of passive eavesdropping attackers, as the ECDHE shared secret is not
> >>>> expected to be derived from the observed ECDH parameters. As a result,
> >>>> passive eavesdropping is unlikely to happen, and the collection of all
> >>>> necessary material relies on an active attack.
> >>>> An active attacker may collect the necessary material by setting a TLS
> >>>> session as a client with the legitimate server. One PSK is tested for
> each
> >>>> session, and a match occurs when key exchange succeeds. On the other
> hand,
> >>>> an active attacker may also consider gathering the necessary
> information for
> >>>> offline computation. One way consists in getting a legitimate client
> to
> >>>> establish a connection with the attacker. It is also assumed that the
> client
> >>>> will accept the ECDH parameters authenticated by the attacker's
> private key
> >>>> and finally returns the Finished message authenticating the exchange.
> The
> >>>> attacker will be then in possession of all the necessary information
> to
> >>>> perform a brute force attack.
> >>>
> >>>
> >>> Is there a reason to not just point directly to the 4279 security
> >>> considerations?
> >>
> >>
> >> No, basically I tried to complete the previous text that missed the
> >> offline use case. The current version just point to 4279, without
> having the
> >> above text. If you think the text above is clarifying I can add it as
> well.
> >>>
> >>> -
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ----------
> >>>>> COMMENT:
> >>>>> ------------------------------------------------------------
> ----------
> >>>>>
> >>>>> The citations to TLS 1.3 still seem pretty muddled. I think you
> >>>>> should just stop referencing and discussing 1.3.
> >>>>
> >>>>
> >>>> My understanding of your comment is that mentioning TLS 1.3 to further
> >>>> insisting that the code point are not valid for TLS 1.3 is confusing.
> I
> >>>> propose to:
> >>>>
> >>>> Explicitly mention the TLS version in the title:
> >>>>
> >>>> OLD title:
> >>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
> >>>> Security (TLS)
> >>>>
> >>>> NEW title:
> >>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
> >>>> Security (TLS)
> >>>>
> >>>> OLD Introduction:
> >>>>
> >>>>     The cipher
> >>>>    suites are defined for version 1.2 of the Transport Layer Security
> >>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport
> Layer
> >>>>    Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
> >>>>    [I-D.ietf-tls-tls13].
> >>>>
> >>>> NEW introduction
> >>>>
> >>>> The cipher
> >>>>    suites are defined for version 1.2 of the Transport Layer Security
> >>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport
> Layer
> >>>>    Security (DTLS) protocol [RFC6347].
> >>>>
> >>>>
> >>>> I suggest to keep the following text of the introduction:
> >>>>
> >>>>
> >>>> AEAD algorithms that combine encryption and integrity protection are
> >>>>    strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms
> are
> >>>>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].  The AEAD
> >>>>    algorithms considered in this document are AES-GCM and AES-CCM.
> The
> >>>>    use of AES-GCM in TLS is defined in [RFC5288] and the use of
> AES-CCM
> >>>>    is defined in [RFC6655].
> >>>
> >>>
> >>> Yes, this seems fine.
> >>>
> >>>
> >>>>
> >>>> I suggest to keep the following text of the Applicable versions
> >>>> sections, as I believe the section discusses the cipher suites
> against all
> >>>> existing TLS versions. In addition, it also justifies somewhat that
> we only
> >>>> defined cipher suites that are compatible with TLS1.3.
> >>>>
> >>>>    TLS version 1.3 and later negotiate these features in a different
> >>>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and
> cipher
> >>>>    suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3
> supports
> >>>>    PSK with ECDHE key exchange and the cipher suites
> >>>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
> >>>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
> >>>>    specification.  As a result, TLS 1.3 and higher versions, negotiate
> >>>>    and support these cipher suites in a different way.
> >>>
> >>>
> >>> OK.
> >>>
> >>>>
> >>>> I suggest to remove the reference to TLS1.3 in the security
> >>>> considerations
> >>>>
> >>>> OLD
> >>>>
> >>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
> >>>>    TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM
> [RFC5288],
> >>>>    and AES-CCM [RFC6655] apply to this document as well.
> >>>>
> >>>> NEW
> >>>>
> >>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
> >>>>  ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [RFC6655] apply
> >>>>  to this document as well.
> >>>>>
> >>>>>
> >>>>> S 2.
> >>>>> I'm not sure that the discussion of the PRF is helpful here in
> >>>>> mandating the non-use of these cipher suites with TLS 1.1 and
> >>>>> below.
> >>>>
> >>>>
> >>>> I find the text useful as it gives an idea why even introducing AEAD
> in
> >>>> TLS version lower than 1.2 is a bad idea, so I would prefer to keep
> it. The
> >>>> text has been changed to
> >>>>
> >>>> OLD:
> >>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
> >>>>
> >>>> NEW:
> >>>> As such,  all ECDHE_PSK
> >>>> ciphers, including those defined outside this document, SHOULD NOT be
> >>>> negotiated in TLS versions prior to 1.2.
> >>>
> >>>
> >>> I don't think you should be levying a new normative requirement like
> this
> >>> for other ciphers
> >>> i this document
> >>
> >>
> >> Consideration for other ciphers has been removed. The requirement is
> >> limited to the ciphers of the document. The new text is:
> >>
> >> As such, all ECDHE_PSK ciphers, including those defined in this
> document,
> >> SHOULD NOT be
> >> negotiated in TLS versions prior to 1.2.
> >>>
> >>>
> >>> -Ek
> >>> r
> >>>
> >>
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>

--94eb2c1cdb3c7f5ccb055045958f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Martin, 

Thank you for your=
 review. Some comment were about text in the applicability section. I think=
 I agree with you that this section details and clarifies=C2=A0 the followi=
ng sentence of the previous section:=C2=A0 """   The assigne=
d code points can only be used for TLS 1.2.""". Most of the =
text of this section has been added in order to address comments, thus in o=
rder to make this section helpful for many readers, I prefer to keep most o=
f the text you mentioned as not useful. 

Please see inline for more =
detail responses and let me know if that address your comments.

Yours, 
Daniel

=

On Wed, May 24, 2017 at 12:09 AM, Martin Thomson=
 <martin.thomson@gmail.com> wrote:
Hi Daniel,



This removes the offending text.



This is incorrect:



> Clients MUST NOT offer one of these cipher suites with a (D)TLS versio=
n that differs from TLS 1.2.



It should be possible to offer these when attempting to negotiate TL=
S

1.3.=C2=A0 The server simply cannot negotiate these cipher suites if it

chooses to use 1.3.=C2=A0 I'd remove that sentence (and the one followi=
ng

it, since it's redundant with the first sentence of the paragraph).


My understanding is that you suggest to remove "=
Clients MUST NOT offer one ..." for the following reasons:

A)
 it is redundant with the first sentence of the paragraph: "The cipher=
=20
suites defined in this document MUST NOT be negotiated ...".=C2=A0 Thi=
s=20
sentence clarifies on the client side what "MUST NOT be negotiated&quo=
t;=20
means, and the same is done for the server side. If we provide=20
clarification for the server side, I would prefer to keep a=20
clarification for the client side as well.=C2=A0 

B)
 It is not true as TLS1.3 enables these cipher suites to be negotiated=20
with TLS1.3. In the text cipher suites stands for the cipher suites code
 points of the IANA registry.=C2=A0 Maybe we can have a better wording.=20
However I believe the next paragraph clarifies that TLS1.3 negotiates=20
these ciphers suites in a different way. Would the following wording addres=
s your comment. If so I will update the section to remove the confusion.
"Clients MUST NOT offer one of the cipher =
suites code points defined in the document with a (D)TLS version that diffe=
rs from TLS 1.2."

The text in question is:
"&q=
uot;"
=C2=A0=C2=A0 The cipher suites defined in this document MUST =
NOT be negotiated for
=C2=A0=C2=A0 any version of (D)TLS other than TLS =
1.2.=C2=A0 Clients MUST NOT offer one
=C2=A0=C2=A0 of these cipher suite=
s with a (D)TLS version that differs from TLS
=C2=A0=C2=A0 1.2.=C2=A0 Se=
rvers MUST NOT select one of these cipher suites with a TLS
=C2=A0=C2=A0=
 version that differs from TLS 1.2.=C2=A0 A client MUST treat the selection=

=C2=A0=C2=A0 of these cipher suites in combination with a version of TL=
S as an
=C2=A0=C2=A0 error and generate a fatal 'illegal_parameter&#=
39; TLS alert.

"""
=C2=A0

As others have noted, the paragraph about TLS 1.3 isn't helpful and

should be removed.



Suggestion to remove TLS1.3 related te=
xt was to clarify that the cipher suites were only defined for TLS1.2. Unle=
ss I missed something we have removed most of the text that could cause con=
fusion. On the other hand, TLS1.3 has been designed, and we also have recei=
ved comments to position the defined cipher suites toward TLS1.3 as we do f=
ro TLS1.0 and TLS1.1. This is the intent of the remaining text mentioning T=
LS1.3. 

In the applicable ver=
sion section, the text for TLS1.3 is intended to clarify why the cipher sui=
tes are restricted to TLS1.2. I believe this is useful for  readers not so =
familiar with TLS1.3 that may not be aware of how TLS1.3=20
negotiate ciphers. My personal opinion is that it might be better to have i=
t explicit rather than implicit, and I would prefer to keep the text below:=


"""
=C2=A0=C2=A0=
 TLS version 1.3 and later negotiate these features in a different
=C2=
=A0=C2=A0 manner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separates authentication an=
d cipher
=C2=A0=C2=A0 suite negotiation [I-D.ietf-tls-tls13] Section 1.2=
.=C2=A0 TLS 1.3 supports
=C2=A0=C2=A0 PSK with ECDHE key exchange and th=
e cipher suites
=C2=A0=C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA=
384,
=C2=A0=C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 ar=
e part of the
=C2=A0=C2=A0 specification.=C2=A0 As a result, TLS 1.3 and=
 higher versions, negotiate
=C2=A0=C2=A0 and support these cipher suites=
 in a different way.

""" 
=C2=A0

=C2=A0

This:



> In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2 [RF=
C4346] split the pre-master into two=C2=A0 parts.=C2=A0 The PRF results fro=
m mixing the two pseudorandom streams with distinct hash functions (MD5 and=
 SHA-1) by exclusive-ORing them together.



You mean TLS 1.1 rather than 1.2.=C2=A0 But as with the former paragraph,
talking about the limitations of TLS versions that you explicitly

don't support isn't useful.=C2=A0 Remove this paragraph also.



Yes that is TLS1.1. I updated it. I believe the t=
ext is useful as it provides a clear justification on why it should not be =
used on TLS version lower than 1.2. More specifically, previous version do =
not support AEAD, but this may not prevent someone using AEAD with these ve=
rsions. The reason provided is not AEAD related but PSK related. I believe =
it is useful to explicitly justify why the cipher suites defined in the doc=
ument should not be used with previous TLS versions. The text has bee sugge=
sted by the secdir and I would prefer to keep it, unless there is a strong =
willingness to remove it. =C2=A0 =C2=A0 
=C2=A0 

Nits:

s/pre-master(| secret)/premaster secret/g

Corrected: The text only have premaster secret. =C2=A0 
=
=C2=A0

You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA25=
6

means to use AEAD_AES_128_GCM (and the same for the other

ciphersuites).=C2=A0 I mention this because the order in which the AEAD

algorithms are mentioned is different to the order of the ciphersuites

in the list.




Unless I miss your comment, I believe the section 3 already addresses it=
. If not please let me knoe what text you would like to see. 
=C2=A0
=

"""
3.=C2=A0 ECDHE_PSK with AES-GCM and AES-CC=
M Cipher Suites

=C2=A0=C2=A0 The cipher suites defined in this docum=
ent are based on the AES-GCM
=C2=A0=C2=A0 and AES-CCM Authenticated Encr=
yption with Associated Data (AEAD)
=C2=A0=C2=A0 algorithms AEAD_AES_128_=
GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
=C2=A0=C2=A0 defined in [RFC5=
116], and AEAD_AES_128_CCM_8 defined in [RFC6655].

"""=
;=C2=A0 



On 24 May 2017 at 12:37, Daniel Migault <daniel.migault@ericsson.com> wrote:

> re-sending with the version 05 but removing the diff to be under the 1=
00 KB

> limit.

> Yours,

> Daniel

>

> On Tue, May 23, 2017 at 9:28 PM, Daniel Migault

> <daniel.migault@eric=
sson.com> wrote:

>>

>> Hi Eric,

>>

>> Thank you for the feed backs. The version 05 contains all text cha=
nges you

>> agreed. In addition, the text explaining dictionary/brute force ha=
s been

>> removed and replace by a reference to 4279. The recommendation reg=
arding to

>> all PSK ciphers has been limited to the one of the document.=C2=A0=
 Please see

>> inline for more details.

>>

>> For some reasons I am not able to validate the submission of versi=
on 05. I

>> have attached the diff with version 04 as well as the locally gene=
rated

>> version 05.

>>

>> Yours,

>> Daniel

>>

>> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>>

>>>

>>>

>>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault

>>> <daniel.miga=
ult@ericsson.com> wrote:

>>>>

>>>> Hi Eric,

>>>>

>>>> Thank you for your reviews. Please see my responses inline=
. If you agree

>>>> with the text I will update the draft.

>>>>

>>>> Yours,

>>>> Daniel

>>>>

>>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>>>>

>>>>> Eric Rescorla has entered the following ballot positio=
n for

>>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss

>>>>>

>>>>> When responding, please keep the subject line intact a=
nd reply to all

>>>>> email addresses included in the To and CC lines. (Feel=
 free to cut this

>>>>> introductory paragraph, however.)

>>>>>

>>>>>

>>>>> Please refer to

>>>>> https://www.ietf.org/i=
esg/statement/discuss-criteria.html

>>>>> for more information about IESG DISCUSS and COMMENT po=
sitions.

>>>>>

>>>>>

>>>>> The document, along with other ballot positions, can b=
e found here:

>>>>> https://datatrac=
ker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

>>>>>

>>>>>

>>>>>

>>>>> -------------------------------------------------=
---------------------

>>>>> DISCUSS:

>>>>> -------------------------------------------------=
---------------------

>>>>>

>>>>> The following text appears to have been added in -04
>>>>>

>>>>>=C2=A0 =C2=A0 A server receiving a ClientHello and a cl=
ient_version indicating

>>>>>=C2=A0 =C2=A0 (3,1) "TLS 1.0" or (3,2) "=
TLS 1.1" and any of the cipher suites from

>>>>>=C2=A0 =C2=A0 this document in ClientHello.cipher_suite=
s can safely assume that

>>>>> the

>>>>>=C2=A0 =C2=A0 client supports TLS 1.2 and is willing to=
 use it.=C2=A0 The server MUST

>>>>>=C2=A0 =C2=A0 NOT negotiate these cipher suites with TL=
S protocol versions earlier

>>>>>=C2=A0 =C2=A0 than TLS 1.2.=C2=A0 Not requiring clients=
 to indicate their support for

>>>>>=C2=A0 =C2=A0 TLS 1.2 cipher suites exclusively through=
 ClientHello.client_hello

>>>>>=C2=A0 =C2=A0 improves the interoperability in the inst=
alled base and use of TLS

>>>>>=C2=A0 =C2=A0 1.2 AEAD cipher suites without upsetting =
the installed base of

>>>>>=C2=A0 =C2=A0 version-intolerant TLS servers, results i=
n more TLS handshakes

>>>>>=C2=A0 =C2=A0 succeeding and obviates fallback mechanis=
ms.

>>>>>

>>>>> This is a major technical change from -03, which, AFAI=
K, prohibited

>>>>> the server from negotiating these algorithms with TLS =
1.1 and below

>>>>> and maintained the usual TLS version 1.2 negotiation r=
ules.

>>>>>

>>>>> This is a very material technical change. I don't =
consider it wise,

>>>>> but in any case it would absolutely need WG consensus,=
 which I

>>>>> don't believe that it has given the recent introdu=
ction.

>>>>

>>>>

>>>> I agree that the text is a technical change, and that it m=
ay not be

>>>> appropriated to do so now. The reason I included it was th=
at it was conform

>>>> to the previous text, but I agree that implicit assumption=
 of version 1.2

>>>> may need some additional discussion especially regarding R=
FC5246 Appendix E.

>>>> Unless you prefer further discussion I assume the text bel=
ow address your

>>>> concern.

>>>>

>>>> <t>The cipher suites defined in this document MUST N=
OT be negotiated for

>>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT=
 offer one of

>>>> these cipher suites with a (D)TLS version that differs fro=
m TLS 1.2. Servers

>>>> MUST NOT select one of these cipher suites with a TLS vers=
ion that differs

>>>> from TLS 1.2. A client MUST treat the selection of these c=
ipher suites in

>>>> combination with a version of TLS as an error and generate=
 a fatal

>>>> 'illegal_parameter' TLS alert. </t>

>>>

>>>

>>> Yes, this seems fine

>>>

>>>

>>>>> The discussion of dictionary attacks here seems inferi=
or to that

>>>>> in 4279. In particular, you only need to actively atta=
ck one

>>>>> connection to capture the data you need for a brute fo=
rce attack

>>>>> despite the text there referring to trying "diffe=
rent keys".

>>>>> Please correct that.

>>>>>

>>>> I believe the text below address your concern:

>>>>

>>>> OLD:

>>>> <t>Use of Pre-Shared Keys of limited entropy may all=
ow an active

>>>> attacker attempts to connect to the server and try differe=
nt keys.

>>>> For example, limited entropy may be provided by using a sh=
ort PSK in

>>>> which

>>>> case an attacker may perform a brute-force attack. Another=
 example

>>>> includes the use of a PSK=C2=A0 chosen by a human which th=
us may be exposed

>>>> to

>>>> dictionary attacks.</t>

>>>>

>>>> NEW:

>>>> <t>Pre-Shared Keys security relies on its associated=
 entropy, and it is

>>>> RECOMMENDED to follow <xref target=3D"4086"/&=
gt; to ensure the PSK has enough

>>>> entropy. Possible reasons for low entropy includes PSK cho=
sen by humans or

>>>> PSK of small length as well as using random generators wit=
h limited entropy.

>>>> </t>

>>>>

>>>> <t>PSK of limited entropy may allow an attacker to t=
est different PSK

>>>> values against a valid output such as master secret or any=
 output derived

>>>> from it. In this document, the master secret is generated =
using the PSK as

>>>> well as the ECDHE shared secret. The use of ECDHE limits t=
he possibilities

>>>> of passive eavesdropping attackers, as the ECDHE shared se=
cret is not

>>>> expected to be derived from the observed ECDH parameters. =
As a result,

>>>> passive eavesdropping is unlikely to happen, and the colle=
ction of all

>>>> necessary material relies on an active attack.

>>>> An active attacker may collect the necessary material by s=
etting a TLS

>>>> session as a client with the legitimate server. One PSK is=
 tested for each

>>>> session, and a match occurs when key exchange succeeds. On=
 the other hand,

>>>> an active attacker may also consider gathering the necessa=
ry information for

>>>> offline computation. One way consists in getting a legitim=
ate client to

>>>> establish a connection with the attacker. It is also assum=
ed that the client

>>>> will accept the ECDH parameters authenticated by the attac=
ker's private key

>>>> and finally returns the Finished message authenticating th=
e exchange. The

>>>> attacker will be then in possession of all the necessary i=
nformation to

>>>> perform a brute force attack.</t>

>>>

>>>

>>> Is there a reason to not just point directly to the 4279 secur=
ity

>>> considerations?

>>

>>

>> No, basically I tried to complete the previous text that missed th=
e

>> offline use case. The current version just point to 4279, without =
having the

>> above text. If you think the text above is clarifying I can add it=
 as well.

>>>

>>> -

>>>>

>>>>

>>>>>

>>>>>

>>>>> -------------------------------------------------=
---------------------

>>>>> COMMENT:

>>>>> -------------------------------------------------=
---------------------

>>>>>

>>>>> The citations to TLS 1.3 still seem pretty muddled. I =
think you

>>>>> should just stop referencing and discussing 1.3.

>>>>

>>>>

>>>> My understanding of your comment is that mentioning TLS 1.=
3 to further

>>>> insisting that the code point are not valid for TLS 1.3 is=
 confusing. I

>>>> propose to:

>>>>

>>>> Explicitly mention the TLS version in the title:

>>>>

>>>> OLD title:

>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Trans=
port Layer

>>>> Security (TLS)

>>>>

>>>> NEW title:

>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Trans=
port Layer

>>>> Security (TLS)

>>>>

>>>> OLD Introduction:

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0The cipher

>>>>=C2=A0 =C2=A0 suites are defined for version 1.2 of the Tra=
nsport Layer Security

>>>>=C2=A0 =C2=A0 (TLS) [RFC5246] protocol, version 1.2 of the =
Datagram Transport Layer

>>>>=C2=A0 =C2=A0 Security (DTLS) protocol [RFC6347], as well a=
s version 1.3 of TLS

>>>>=C2=A0 =C2=A0 [I-D.ietf-tls-tls13].

>>>>

>>>> NEW introduction

>>>>

>>>> The cipher

>>>>=C2=A0 =C2=A0 suites are defined for version 1.2 of the Tra=
nsport Layer Security

>>>>=C2=A0 =C2=A0 (TLS) [RFC5246] protocol, version 1.2 of the =
Datagram Transport Layer

>>>>=C2=A0 =C2=A0 Security (DTLS) protocol [RFC6347].

>>>>

>>>>

>>>> I suggest to keep the following text of the introduction:<=
br>
>>>>

>>>>

>>>> AEAD algorithms that combine encryption and integrity prot=
ection are

>>>>=C2=A0 =C2=A0 strongly recommended for (D)TLS [RFC7525] and=
 non-AEAD algorithms are

>>>>=C2=A0 =C2=A0 forbidden to use in TLS 1.3 [I-D.ietf-tls-tls=
13].=C2=A0 The AEAD

>>>>=C2=A0 =C2=A0 algorithms considered in this document are AE=
S-GCM and AES-CCM.=C2=A0 The

>>>>=C2=A0 =C2=A0 use of AES-GCM in TLS is defined in [RFC5288]=
 and the use of AES-CCM

>>>>=C2=A0 =C2=A0 is defined in [RFC6655].

>>>

>>>

>>> Yes, this seems fine.

>>>

>>>

>>>>

>>>> I suggest to keep the following text of the Applicable ver=
sions

>>>> sections, as I believe the section discusses the cipher su=
ites against all

>>>> existing TLS versions. In addition, it also justifies some=
what that we only

>>>> defined cipher suites that are compatible with TLS1.3.

>>>>

>>>>=C2=A0 =C2=A0 TLS version 1.3 and later negotiate these fea=
tures in a different

>>>>=C2=A0 =C2=A0 manner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separat=
es authentication and cipher

>>>>=C2=A0 =C2=A0 suite negotiation [I-D.ietf-tls-tls13] Sectio=
n 1.2.=C2=A0 TLS 1.3 supports

>>>>=C2=A0 =C2=A0 PSK with ECDHE key exchange and the cipher su=
ites

>>>>=C2=A0 =C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA38=
4,

>>>>=C2=A0 =C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_=
SHA256 are part of the

>>>>=C2=A0 =C2=A0 specification.=C2=A0 As a result, TLS 1.3 and=
 higher versions, negotiate

>>>>=C2=A0 =C2=A0 and support these cipher suites in a differen=
t way.

>>>

>>>

>>> OK.

>>>

>>>>

>>>> I suggest to remove the reference to TLS1.3 in the securit=
y

>>>> considerations

>>>>

>>>> OLD

>>>>

>>>>=C2=A0 The security considerations in TLS 1.2 [RFC5246], DT=
LS 1.2 [RFC6347],

>>>>=C2=A0 =C2=A0 TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5=
489], AES-GCM [RFC5288],

>>>>=C2=A0 =C2=A0 and AES-CCM [RFC6655] apply to this document =
as well.

>>>>

>>>> NEW

>>>>

>>>>=C2=A0 The security considerations in TLS 1.2 [RFC5246], DT=
LS 1.2 [RFC6347],

>>>>=C2=A0 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [=
RFC6655] apply

>>>>=C2=A0 to this document as well.

>>>>>

>>>>>

>>>>> S 2.

>>>>> I'm not sure that the discussion of the PRF is hel=
pful here in

>>>>> mandating the non-use of these cipher suites with TLS =
1.1 and

>>>>> below.

>>>>

>>>>

>>>> I find the text useful as it gives an idea why even introd=
ucing AEAD in

>>>> TLS version lower than 1.2 is a bad idea, so I would prefe=
r to keep it. The

>>>> text has been changed to

>>>>

>>>> OLD:

>>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_=
PSK.

>>>>

>>>> NEW:

>>>> As such,=C2=A0 all ECDHE_PSK

>>>> ciphers, including those defined outside this document, SH=
OULD NOT be

>>>> negotiated in TLS versions prior to 1.2.

>>>

>>>

>>> I don't think you should be levying a new normative requir=
ement like this

>>> for other ciphers

>>> i this document

>>

>>

>> Consideration for other ciphers has been removed. The requirement =
is

>> limited to the ciphers of the document. The new text is:

>>

>> As such, all ECDHE_PSK ciphers, including those defined in this do=
cument,

>> SHOULD NOT be

>> negotiated in TLS versions prior to 1.2.

>>>

>>>

>>> -Ek

>>> r

>>>

>>

>

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls

>





--94eb2c1cdb3c7f5ccb055045958f--


From nobody Wed May 24 07:30:50 2017
Return-Path: 
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 68D1E129B46 for ; Wed, 24 May 2017 07:30:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 O6kAa6uf885W for ; Wed, 24 May 2017 07:30:47 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id C1927129B64 for ; Wed, 24 May 2017 07:30:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1E1D621775; Wed, 24 May 2017 17:30:45 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Dam_-_yBxJEr; Wed, 24 May 2017 17:30:44 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id BCEBB21C; Wed, 24 May 2017 17:30:44 +0300 (EEST)
Date: Wed, 24 May 2017 17:30:42 +0300
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Cc: Eric Rescorla , "tls@ietf.org" 
Message-ID: <20170524143042.GA31858@LK-Perkele-V2.elisa-laajakaista.fi>
References:      <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>  <071fb4df-56e6-d82a-87de-3db084235021@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <071fb4df-56e6-d82a-87de-3db084235021@akamai.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 14:30:49 -0000

On Wed, May 24, 2017 at 08:50:07AM -0500, Benjamin Kaduk wrote:
> On 05/21/2017 05:47 PM, Eric Rescorla wrote:
> >
> >
> > On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara
> > > wrote:
> >
> >     On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
> >      
> >
> >     - Clients MUST NOT use the same ticket multiple times for 0-RTT.
> >
> >
> > I don't understand the purpose of this requirement. As you note below,
> > servers are ultimately responsible for enforcing it, and it's not clear to
> > me why clients obeying it makes life easier for the server.
> >
> 
> I think it's just an attempt to make clear what the client behavior
> should be.  It's like when we say that implementations MUST NOT put more
> than one extension of the same type in a given extension block.  The
> peer has to validate received messages, but the local implementation has
> to know to not generate them, either.

There's also quite a bit of difference between:

- MUST NOT do X
- MUST NOT do X, MUST abort with Y if X is done.

As the second requires receiver to detect X, which can be hard. E.g.,
detecting arbitrary duplicated extension is definitely not trivial.
 
E.g., for duplicate extensions, my implementation only validates the
known extensions. As consequence, unknown extensions in offers can
appear multiple times without detection (e.g., two copies of extension
35 in ClientHello). It is done that way to limit resource usage:
Checking a small list of extensions is easy, checking 64k of those is
less so.

> >
> >     - Servers MUST NOT accept the same ticket with the same binder
> >     multiple
> >       times for 0-RTT (if any part of ClientHello covered by binder is
> >       different, one can assume binders are different). This holds even
> >       across servers (i.e., if server1 accepts 0-RTT with ticket X and
> >       binder Y, then server2 can not accept 0-RTT with ticket X and binder
> >       Y).
> >
> >
> > I assume that what you have in mind here is that the server would know
> > which tickets it was authoritative for anti-replay and would simply reject
> > 0-RTT if it wasn't authoritative? This seems like it would
> > significantly cut
> > down on mass replays, though it would of course still make
> > application-level
> > replay a problem.
> >
> 
> Right, this would bring replays down from the millions hypothesized for
> the weak time-based thing to more like tens, which is kind of in the
> regime that we are currently in with (at least some) application behavior.

Actually, even tens of replays at TLS level is quite dangerous,
especially if to different servers (bad information leaks via cache
attacks).

> > I'm happy to write this up as part of the first two techniques. I'd be 
> > interested in hearing from others in the WG what they think about:
> >
> 
> I think it's worth writing up the most-secure scheme(s) we know of, to
> give us some concrete text to digest and decide if we can live with.

However, every scheme that isn't the most-secure (tied 1st place) that
has been proposed so far is too insecure.

> > 1. Requiring it.
> > 2. Whether they still want to retain the stateless technique.
> >
> 
> If we think we can require it and have it actually stick, that seems
> like the safest plan.  The results of this discussion leave me uneasy
> with a scheme that permits millions of replays, even if there is not
> something concrete that I definitely object to.  As DKG (almost) said,
> "we're designing a security protocol, not an easy-to-implement
> protocol". 

There is major difference about how hard TLS 1.3 is to _implement_, and
how hard it is to _use_.

Most serious TLS 1.3 implementations will be written by experts.
Additionally, the protocol avoids using constructs that are almost
impossible to implement properly (e.g., good riddance TLS blockmode).

Whereas most applications using TLS will not be written by security
experts. And the protocols they implement are not designed for side-
channel resistance in implementations.

> Another crazy idea would be to just say that servers MUST limit the use
> of a single binder to at most 100 times, with the usual case being just
> once, to allow for alternative designs that have weaker distributed
> consensus requirements (but still describe these current two methods as
> examples of ways to do so).

You actually need strong distributed consensus about all accepted
0-RTT here.


-Ilari


From nobody Wed May 24 08:04:06 2017
Return-Path: 
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 21C3D128B37 for ; Wed, 24 May 2017 08:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 Llz22jDLQcP2 for ; Wed, 24 May 2017 08:03:53 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B3F1293D6 for ; Wed, 24 May 2017 08:03:53 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id m17so140676196pfg.3 for ; Wed, 24 May 2017 08:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GjvWcvqKNcG8G12aCKaSiP+Trcj9IfD2lSxKVcsn5eU=; b=G6tI+os0oP94fk1F9awDmqJcwLBlKezwmYzHSsveyTGUixoxvhqqxErOUvRkNi0etr 2Rqv1bYWx+N/LxbcGRHIHkDqUdOzqShAhJNBJaIWYaRjoHHDHt/VCwiT8swo6dLtDGNG GtJvR2g99zDfN+aTD68mMyGpJBYfLWKECfDEKGSDtHxndMFKiRa/RoB32nmhlXwdbQgS ObZmG3HfvHLZZDfaUkt1MqGLL9eSmKm8EMUdywcHoscum7g3onrh9+FOi6c4DkafSe9g yLdYLtvovRjmi8W6FNdr73VfPUvmEnaNeqJrTOxEr6XSzUM0KiZBuH3vys1RIzBSlrhp aouw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GjvWcvqKNcG8G12aCKaSiP+Trcj9IfD2lSxKVcsn5eU=; b=i/1BGZStO/ic0ESE2nL827MnOhXACY2p+sJHYJS5n3kDXR6Vr8fLWH7Yy/6OtOyzXp MwWkbanxLcpxWJVMlBfaacIF1tq4TvvLI01s2Upjrkx/fFMJsUEQMNDZpbkm4KDKc2gy 4/fOOVcLGIw75Rc1G1wWSRnYyDsY/p4I4IPo5+TV/HMpE1oE2rC5hafzastkpDOf1rJe 5WwvIdGwD3L1jiOYnKHtrCZuxSdTG6eTF1/jqNaHamfDacFx16orhPH25rJcnFMHsnz5 WX3AXU2AIDlobyILle975TxCRx6urSgGiF8RId+znB46DBzolLdDayTeSbpgXephmKSf WWrA==
X-Gm-Message-State: AODbwcDogmwX7qjiQLKkBIH4GOOuoX1azo2zHOcbs3n89KyMCuF+JGsR n5lFVcB4bbPvxUFdItHVf/IVm67UdMWO
X-Received: by 10.84.162.204 with SMTP id o12mr43425730plg.23.1495638232791; Wed, 24 May 2017 08:03:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.177.204 with HTTP; Wed, 24 May 2017 08:03:32 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>      
From: Joseph Salowey 
Date: Wed, 24 May 2017 08:03:32 -0700
Message-ID: 
To: Daniel Migault 
Cc: Martin Thomson , Eric Rescorla ,  tls-chairs , The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1483a0941ad805504669a0"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:03:58 -0000

--94eb2c1483a0941ad805504669a0
Content-Type: text/plain; charset="UTF-8"

Hi Daniel,

Thanks for putting this revision together.  The original text in draft 4
went beyond the scope of what should be in the document (I was too hasty in
my review of the document and discussion on the list).   Your current
proposal is an improvement, but it still discusses behavior that could
either conflict with other documents or discusses behavior that is not in
scope.

My suggestion is to replace section 4 with the following paragraph (I think
this is similar to what Martin suggests):

"The cipher suites defined in this document MUST NOT be negotiated for any
version of (D)TLS other than TLS 1.2.  Servers MUST NOT select one of these
cipher suites when selecting TLS version other than TLS 1.2.  A client MUST
treat the selection of these cipher suites in combination with a different
version of TLS as an error and generate a fatal 'illegal_parameter' TLS
alert."

I think it would also be OK to add the following to point readers to
equivalent ciphers in 1.3.  Here is some suggested text that could go in
the revised section 4:

"Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to support
equivalent functionality in TLS 1.3 [TLS 1.3]."

Thanks,

Joe


On Wed, May 24, 2017 at 7:04 AM, Daniel Migault  wrote:

> Hi Martin,
>
> Thank you for your review. Some comment were about text in the
> applicability section. I think I agree with you that this section details
> and clarifies  the following sentence of the previous section:  """ The
> assigned code points can only be used for TLS 1.2.""". Most of the text of
> this section has been added in order to address comments, thus in order to
> make this section helpful for many readers, I prefer to keep most of the
> text you mentioned as not useful.
>
> Please see inline for more detail responses and let me know if that
> address your comments.
>
> Yours,
> Daniel
>
> On Wed, May 24, 2017 at 12:09 AM, Martin Thomson  > wrote:
>
>> Hi Daniel,
>>
>> This removes the offending text.
>>
>> This is incorrect:
>>
>> > Clients MUST NOT offer one of these cipher suites with a (D)TLS version
>> that differs from TLS 1.2.
>>
>> It should be possible to offer these when attempting to negotiate TLS
>> 1.3.  The server simply cannot negotiate these cipher suites if it
>> chooses to use 1.3.  I'd remove that sentence (and the one following
>> it, since it's redundant with the first sentence of the paragraph).
>>
>> My understanding is that you suggest to remove "Clients MUST NOT offer
> one ..." for the following reasons:
>
> A) it is redundant with the first sentence of the paragraph: "The cipher
> suites defined in this document MUST NOT be negotiated ...".  This sentence
> clarifies on the client side what "MUST NOT be negotiated" means, and the
> same is done for the server side. If we provide clarification for the
> server side, I would prefer to keep a clarification for the client side as
> well.
>
> B) It is not true as TLS1.3 enables these cipher suites to be negotiated
> with TLS1.3. In the text cipher suites stands for the cipher suites code
> points of the IANA registry.  Maybe we can have a better wording. However I
> believe the next paragraph clarifies that TLS1.3 negotiates these ciphers
> suites in a different way. Would the following wording address your
> comment. If so I will update the section to remove the confusion.
>
> "Clients MUST NOT offer one of the cipher suites code points defined in
> the document with a (D)TLS version that differs from TLS 1.2."
>
> The text in question is:
> """
>    The cipher suites defined in this document MUST NOT be negotiated for
>    any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
>    of these cipher suites with a (D)TLS version that differs from TLS
>    1.2.  Servers MUST NOT select one of these cipher suites with a TLS
>    version that differs from TLS 1.2.  A client MUST treat the selection
>    of these cipher suites in combination with a version of TLS as an
>    error and generate a fatal 'illegal_parameter' TLS alert.
>
> """
>
>
>> As others have noted, the paragraph about TLS 1.3 isn't helpful and
>> should be removed.
>>
>>
> Suggestion to remove TLS1.3 related text was to clarify that the cipher
> suites were only defined for TLS1.2. Unless I missed something we have
> removed most of the text that could cause confusion. On the other hand,
> TLS1.3 has been designed, and we also have received comments to position
> the defined cipher suites toward TLS1.3 as we do fro TLS1.0 and TLS1.1.
> This is the intent of the remaining text mentioning TLS1.3.
>
> In the applicable version section, the text for TLS1.3 is intended to
> clarify why the cipher suites are restricted to TLS1.2. I believe this is
> useful for readers not so familiar with TLS1.3 that may not be aware of how
> TLS1.3 negotiate ciphers. My personal opinion is that it might be better to
> have it explicit rather than implicit, and I would prefer to keep the text
> below:
>
> """
>    TLS version 1.3 and later negotiate these features in a different
>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
>    suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
>    PSK with ECDHE key exchange and the cipher suites
>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
>    specification.  As a result, TLS 1.3 and higher versions, negotiate
>    and support these cipher suites in a different way.
>
> """
>
>
>
>
>> This:
>>
>> > In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
>> [RFC4346] split the pre-master into two  parts.  The PRF results from
>> mixing the two pseudorandom streams with distinct hash functions (MD5 and
>> SHA-1) by exclusive-ORing them together.
>>
>> You mean TLS 1.1 rather than 1.2.  But as with the former paragraph,
>> talking about the limitations of TLS versions that you explicitly
>> don't support isn't useful.  Remove this paragraph also.
>>
>>
> Yes that is TLS1.1. I updated it. I believe the text is useful as it
> provides a clear justification on why it should not be used on TLS version
> lower than 1.2. More specifically, previous version do not support AEAD,
> but this may not prevent someone using AEAD with these versions. The reason
> provided is not AEAD related but PSK related. I believe it is useful to
> explicitly justify why the cipher suites defined in the document should not
> be used with previous TLS versions. The text has bee suggested by the
> secdir and I would prefer to keep it, unless there is a strong willingness
> to remove it.
>
>
>> Nits:
>> s/pre-master(| secret)/premaster secret/g
>>
>
> Corrected: The text only have premaster secret.
>
>
>> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>> means to use AEAD_AES_128_GCM (and the same for the other
>> ciphersuites).  I mention this because the order in which the AEAD
>> algorithms are mentioned is different to the order of the ciphersuites
>> in the list.
>>
>>
> Unless I miss your comment, I believe the section 3 already addresses it.
> If not please let me knoe what text you would like to see.
>
> """
> 3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites
>
>    The cipher suites defined in this document are based on the AES-GCM
>    and AES-CCM Authenticated Encryption with Associated Data (AEAD)
>    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
>    defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].
>
> """
>
>>
>> On 24 May 2017 at 12:37, Daniel Migault 
>> wrote:
>> > re-sending with the version 05 but removing the diff to be under the
>> 100 KB
>> > limit.
>> > Yours,
>> > Daniel
>> >
>> > On Tue, May 23, 2017 at 9:28 PM, Daniel Migault
>> >  wrote:
>> >>
>> >> Hi Eric,
>> >>
>> >> Thank you for the feed backs. The version 05 contains all text changes
>> you
>> >> agreed. In addition, the text explaining dictionary/brute force has
>> been
>> >> removed and replace by a reference to 4279. The recommendation
>> regarding to
>> >> all PSK ciphers has been limited to the one of the document.  Please
>> see
>> >> inline for more details.
>> >>
>> >> For some reasons I am not able to validate the submission of version
>> 05. I
>> >> have attached the diff with version 04 as well as the locally generated
>> >> version 05.
>> >>
>> >> Yours,
>> >> Daniel
>> >>
>> >> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault
>> >>>  wrote:
>> >>>>
>> >>>> Hi Eric,
>> >>>>
>> >>>> Thank you for your reviews. Please see my responses inline. If you
>> agree
>> >>>> with the text I will update the draft.
>> >>>>
>> >>>> Yours,
>> >>>> Daniel
>> >>>>
>> >>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla 
>> wrote:
>> >>>>>
>> >>>>> Eric Rescorla has entered the following ballot position for
>> >>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>> >>>>>
>> >>>>> When responding, please keep the subject line intact and reply to
>> all
>> >>>>> email addresses included in the To and CC lines. (Feel free to cut
>> this
>> >>>>> introductory paragraph, however.)
>> >>>>>
>> >>>>>
>> >>>>> Please refer to
>> >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> >>>>> for more information about IESG DISCUSS and COMMENT positions.
>> >>>>>
>> >>>>>
>> >>>>> The document, along with other ballot positions, can be found here:
>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ----------
>> >>>>> DISCUSS:
>> >>>>> ------------------------------------------------------------
>> ----------
>> >>>>>
>> >>>>> The following text appears to have been added in -04
>> >>>>>
>> >>>>>    A server receiving a ClientHello and a client_version indicating
>> >>>>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites
>> from
>> >>>>>    this document in ClientHello.cipher_suites can safely assume that
>> >>>>> the
>> >>>>>    client supports TLS 1.2 and is willing to use it.  The server
>> MUST
>> >>>>>    NOT negotiate these cipher suites with TLS protocol versions
>> earlier
>> >>>>>    than TLS 1.2.  Not requiring clients to indicate their support
>> for
>> >>>>>    TLS 1.2 cipher suites exclusively through
>> ClientHello.client_hello
>> >>>>>    improves the interoperability in the installed base and use of
>> TLS
>> >>>>>    1.2 AEAD cipher suites without upsetting the installed base of
>> >>>>>    version-intolerant TLS servers, results in more TLS handshakes
>> >>>>>    succeeding and obviates fallback mechanisms.
>> >>>>>
>> >>>>> This is a major technical change from -03, which, AFAIK, prohibited
>> >>>>> the server from negotiating these algorithms with TLS 1.1 and below
>> >>>>> and maintained the usual TLS version 1.2 negotiation rules.
>> >>>>>
>> >>>>> This is a very material technical change. I don't consider it wise,
>> >>>>> but in any case it would absolutely need WG consensus, which I
>> >>>>> don't believe that it has given the recent introduction.
>> >>>>
>> >>>>
>> >>>> I agree that the text is a technical change, and that it may not be
>> >>>> appropriated to do so now. The reason I included it was that it was
>> conform
>> >>>> to the previous text, but I agree that implicit assumption of
>> version 1.2
>> >>>> may need some additional discussion especially regarding RFC5246
>> Appendix E.
>> >>>> Unless you prefer further discussion I assume the text below address
>> your
>> >>>> concern.
>> >>>>
>> >>>> The cipher suites defined in this document MUST NOT be negotiated
>> for
>> >>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one
>> of
>> >>>> these cipher suites with a (D)TLS version that differs from TLS 1.2.
>> Servers
>> >>>> MUST NOT select one of these cipher suites with a TLS version that
>> differs
>> >>>> from TLS 1.2. A client MUST treat the selection of these cipher
>> suites in
>> >>>> combination with a version of TLS as an error and generate a fatal
>> >>>> 'illegal_parameter' TLS alert. 
>> >>>
>> >>>
>> >>> Yes, this seems fine
>> >>>
>> >>>
>> >>>>> The discussion of dictionary attacks here seems inferior to that
>> >>>>> in 4279. In particular, you only need to actively attack one
>> >>>>> connection to capture the data you need for a brute force attack
>> >>>>> despite the text there referring to trying "different keys".
>> >>>>> Please correct that.
>> >>>>>
>> >>>> I believe the text below address your concern:
>> >>>>
>> >>>> OLD:
>> >>>> Use of Pre-Shared Keys of limited entropy may allow an active
>> >>>> attacker attempts to connect to the server and try different keys.
>> >>>> For example, limited entropy may be provided by using a short PSK in
>> >>>> which
>> >>>> case an attacker may perform a brute-force attack. Another example
>> >>>> includes the use of a PSK  chosen by a human which thus may be
>> exposed
>> >>>> to
>> >>>> dictionary attacks.
>> >>>>
>> >>>> NEW:
>> >>>> Pre-Shared Keys security relies on its associated entropy, and it
>> is
>> >>>> RECOMMENDED to follow  to ensure the PSK has
>> enough
>> >>>> entropy. Possible reasons for low entropy includes PSK chosen by
>> humans or
>> >>>> PSK of small length as well as using random generators with limited
>> entropy.
>> >>>> 
>> >>>>
>> >>>> PSK of limited entropy may allow an attacker to test different PSK
>> >>>> values against a valid output such as master secret or any output
>> derived
>> >>>> from it. In this document, the master secret is generated using the
>> PSK as
>> >>>> well as the ECDHE shared secret. The use of ECDHE limits the
>> possibilities
>> >>>> of passive eavesdropping attackers, as the ECDHE shared secret is not
>> >>>> expected to be derived from the observed ECDH parameters. As a
>> result,
>> >>>> passive eavesdropping is unlikely to happen, and the collection of
>> all
>> >>>> necessary material relies on an active attack.
>> >>>> An active attacker may collect the necessary material by setting a
>> TLS
>> >>>> session as a client with the legitimate server. One PSK is tested
>> for each
>> >>>> session, and a match occurs when key exchange succeeds. On the other
>> hand,
>> >>>> an active attacker may also consider gathering the necessary
>> information for
>> >>>> offline computation. One way consists in getting a legitimate client
>> to
>> >>>> establish a connection with the attacker. It is also assumed that
>> the client
>> >>>> will accept the ECDH parameters authenticated by the attacker's
>> private key
>> >>>> and finally returns the Finished message authenticating the
>> exchange. The
>> >>>> attacker will be then in possession of all the necessary information
>> to
>> >>>> perform a brute force attack.
>> >>>
>> >>>
>> >>> Is there a reason to not just point directly to the 4279 security
>> >>> considerations?
>> >>
>> >>
>> >> No, basically I tried to complete the previous text that missed the
>> >> offline use case. The current version just point to 4279, without
>> having the
>> >> above text. If you think the text above is clarifying I can add it as
>> well.
>> >>>
>> >>> -
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ----------
>> >>>>> COMMENT:
>> >>>>> ------------------------------------------------------------
>> ----------
>> >>>>>
>> >>>>> The citations to TLS 1.3 still seem pretty muddled. I think you
>> >>>>> should just stop referencing and discussing 1.3.
>> >>>>
>> >>>>
>> >>>> My understanding of your comment is that mentioning TLS 1.3 to
>> further
>> >>>> insisting that the code point are not valid for TLS 1.3 is
>> confusing. I
>> >>>> propose to:
>> >>>>
>> >>>> Explicitly mention the TLS version in the title:
>> >>>>
>> >>>> OLD title:
>> >>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>> >>>> Security (TLS)
>> >>>>
>> >>>> NEW title:
>> >>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>> >>>> Security (TLS)
>> >>>>
>> >>>> OLD Introduction:
>> >>>>
>> >>>>     The cipher
>> >>>>    suites are defined for version 1.2 of the Transport Layer Security
>> >>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport
>> Layer
>> >>>>    Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>> >>>>    [I-D.ietf-tls-tls13].
>> >>>>
>> >>>> NEW introduction
>> >>>>
>> >>>> The cipher
>> >>>>    suites are defined for version 1.2 of the Transport Layer Security
>> >>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport
>> Layer
>> >>>>    Security (DTLS) protocol [RFC6347].
>> >>>>
>> >>>>
>> >>>> I suggest to keep the following text of the introduction:
>> >>>>
>> >>>>
>> >>>> AEAD algorithms that combine encryption and integrity protection are
>> >>>>    strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms
>> are
>> >>>>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].  The AEAD
>> >>>>    algorithms considered in this document are AES-GCM and AES-CCM.
>> The
>> >>>>    use of AES-GCM in TLS is defined in [RFC5288] and the use of
>> AES-CCM
>> >>>>    is defined in [RFC6655].
>> >>>
>> >>>
>> >>> Yes, this seems fine.
>> >>>
>> >>>
>> >>>>
>> >>>> I suggest to keep the following text of the Applicable versions
>> >>>> sections, as I believe the section discusses the cipher suites
>> against all
>> >>>> existing TLS versions. In addition, it also justifies somewhat that
>> we only
>> >>>> defined cipher suites that are compatible with TLS1.3.
>> >>>>
>> >>>>    TLS version 1.3 and later negotiate these features in a different
>> >>>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and
>> cipher
>> >>>>    suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3
>> supports
>> >>>>    PSK with ECDHE key exchange and the cipher suites
>> >>>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>> >>>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of
>> the
>> >>>>    specification.  As a result, TLS 1.3 and higher versions,
>> negotiate
>> >>>>    and support these cipher suites in a different way.
>> >>>
>> >>>
>> >>> OK.
>> >>>
>> >>>>
>> >>>> I suggest to remove the reference to TLS1.3 in the security
>> >>>> considerations
>> >>>>
>> >>>> OLD
>> >>>>
>> >>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2
>> [RFC6347],
>> >>>>    TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM
>> [RFC5288],
>> >>>>    and AES-CCM [RFC6655] apply to this document as well.
>> >>>>
>> >>>> NEW
>> >>>>
>> >>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2
>> [RFC6347],
>> >>>>  ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [RFC6655] apply
>> >>>>  to this document as well.
>> >>>>>
>> >>>>>
>> >>>>> S 2.
>> >>>>> I'm not sure that the discussion of the PRF is helpful here in
>> >>>>> mandating the non-use of these cipher suites with TLS 1.1 and
>> >>>>> below.
>> >>>>
>> >>>>
>> >>>> I find the text useful as it gives an idea why even introducing AEAD
>> in
>> >>>> TLS version lower than 1.2 is a bad idea, so I would prefer to keep
>> it. The
>> >>>> text has been changed to
>> >>>>
>> >>>> OLD:
>> >>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
>> >>>>
>> >>>> NEW:
>> >>>> As such,  all ECDHE_PSK
>> >>>> ciphers, including those defined outside this document, SHOULD NOT be
>> >>>> negotiated in TLS versions prior to 1.2.
>> >>>
>> >>>
>> >>> I don't think you should be levying a new normative requirement like
>> this
>> >>> for other ciphers
>> >>> i this document
>> >>
>> >>
>> >> Consideration for other ciphers has been removed. The requirement is
>> >> limited to the ciphers of the document. The new text is:
>> >>
>> >> As such, all ECDHE_PSK ciphers, including those defined in this
>> document,
>> >> SHOULD NOT be
>> >> negotiated in TLS versions prior to 1.2.
>> >>>
>> >>>
>> >>> -Ek
>> >>> r
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>
>

--94eb2c1483a0941ad805504669a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Daniel,

Thanks for putting this re=
vision together.=C2=A0 The original text in draft 4 went beyond the scope o=
f what should be in the document (I was too hasty in my review of the docum=
ent and discussion on the list). =C2=A0 Your current proposal is an improve=
ment, but it still discusses behavior that could either conflict with other=
 documents or discusses behavior that is not in scope.=C2=A0=C2=A0

My suggestion =
is to replace section 4 with the following paragraph (I think this is simil=
ar to what Martin suggests):

=
"The cipher suites defined in this=
 document MUST NOT be negotiated for any version of (D)TLS other than TLS 1=
.2.=C2=A0 Servers MUST NOT select one of these cipher suites when selecting=
 TLS version other than TLS 1.2.=C2=A0 A client MUST treat the selection of=
 these cipher suites in combination with a different version of TLS as an e=
rror and generate a fatal 'illegal_parameter' TLS alert."=C2=
=A0

I think it would also be OK to add the follow=
ing to point readers to equivalent ciphers in 1.3.=C2=A0 Here is some sugge=
sted text that could go in the revised section 4:

"Cipher suites TLS_AES_128_GCM_SHA256, =
TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256=
 are used to support equivalent functionality in TLS 1.3 [TLS 1.3]."

Thanks,

Joe


On Wed, May 24, 2017 at 7:04 AM, Daniel Migault <daniel.migau=
lt@ericsson.com> wrote:
Hi Martin, 

Th=
ank you for your review. Some comment were about text in the applicability =
section. I think I agree with you that this section details and clarifies=
=C2=A0 the following sentence of the previous section:=C2=A0 ""&q=
uot;   The assigned code points can only be used for TLS 1.2.""&q=
uot;. Most of the text of this section has been added in order to address c=
omments, thus in order to make this section helpful for many readers, I pre=
fer to keep most of the text you mentioned as not useful. 

Please se=
e inline for more detail responses and let me know if that address your com=
ments.

Yours, 
Daniel

On Wed, May 24, 2017 at 12:09 AM, Martin=
 Thomson <martin.thomson@gmail.com> wrote:
Hi Daniel,



This removes the offending text.



This is incorrect:



> Clients MUST NOT offer one of these cipher suites with a (D)TLS versio=
n that differs from TLS 1.2.



It should be possible to offer these when attempting to negotiate TL=
S

1.3.=C2=A0 The server simply cannot negotiate these cipher suites if it

chooses to use 1.3.=C2=A0 I'd remove that sentence (and the one followi=
ng

it, since it's redundant with the first sentence of the paragraph).


My understanding is that you suggest to remove=
 "Clients MUST NOT offer one ..." for the following reasons:
<=
br>A)
 it is redundant with the first sentence of the paragraph: "The cipher=
=20
suites defined in this document MUST NOT be negotiated ...".=C2=A0 Thi=
s=20
sentence clarifies on the client side what "MUST NOT be negotiated&quo=
t;=20
means, and the same is done for the server side. If we provide=20
clarification for the server side, I would prefer to keep a=20
clarification for the client side as well.=C2=A0 

B)
 It is not true as TLS1.3 enables these cipher suites to be negotiated=20
with TLS1.3. In the text cipher suites stands for the cipher suites code
 points of the IANA registry.=C2=A0 Maybe we can have a better wording.=20
However I believe the next paragraph clarifies that TLS1.3 negotiates=20
these ciphers suites in a different way. Would the following wording addres=
s your comment. If so I will update the section to remove the confusion.
"Clients MUST NOT offer one of the cipher suite=
s code points defined in the document with a (D)TLS version that differs fr=
om TLS 1.2."

The text in question is:
"""
=
=C2=A0=C2=A0 The cipher suites defined in this document MUST NOT be negotia=
ted for
=C2=A0=C2=A0 any version of (D)TLS other than TLS 1.2.=C2=A0 Cli=
ents MUST NOT offer one
=C2=A0=C2=A0 of these cipher suites with a (D)TL=
S version that differs from TLS
=C2=A0=C2=A0 1.2.=C2=A0 Servers MUST NOT=
 select one of these cipher suites with a TLS
=C2=A0=C2=A0 version that =
differs from TLS 1.2.=C2=A0 A client MUST treat the selection
=C2=A0=C2=
=A0 of these cipher suites in combination with a version of TLS as an
=
=C2=A0=C2=A0 error and generate a fatal 'illegal_parameter' TLS ale=
rt.

"""
=C2=A0

As others have noted, the paragraph about TLS 1.3 isn't helpful and

should be removed.



Suggestion to remove TLS1.3 related te=
xt was to clarify that the cipher suites were only defined for TLS1.2. Unle=
ss I missed something we have removed most of the text that could cause con=
fusion. On the other hand, TLS1.3 has been designed, and we also have recei=
ved comments to position the defined cipher suites toward TLS1.3 as we do f=
ro TLS1.0 and TLS1.1. This is the intent of the remaining text mentioning T=
LS1.3. 

In the applicable ver=
sion section, the text for TLS1.3 is intended to clarify why the cipher sui=
tes are restricted to TLS1.2. I believe this is useful for  readers not so =
familiar with TLS1.3 that may not be aware of how TLS1.3=20
negotiate ciphers. My personal opinion is that it might be better to have i=
t explicit rather than implicit, and I would prefer to keep the text below:=


"""
=C2=A0=C2=A0 TLS versi=
on 1.3 and later negotiate these features in a different
=C2=A0=C2=A0 ma=
nner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
=
=C2=A0=C2=A0 suite negotiation [I-D.ietf-tls-tls13] Section 1.2.=C2=A0 TLS =
1.3 supports
=C2=A0=C2=A0 PSK with ECDHE key exchange and the cipher sui=
tes
=C2=A0=C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
=C2=
=A0=C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of t=
he
=C2=A0=C2=A0 specification.=C2=A0 As a result, TLS 1.3 and higher ver=
sions, negotiate
=C2=A0=C2=A0 and support these cipher suites in a diffe=
rent way.

""" 
=C2=A0

=C2=A0

This:



> In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2 [RF=
C4346] split the pre-master into two=C2=A0 parts.=C2=A0 The PRF results fro=
m mixing the two pseudorandom streams with distinct hash functions (MD5 and=
 SHA-1) by exclusive-ORing them together.



You mean TLS 1.1 rather than 1.2.=C2=A0 But as with the former paragraph,
talking about the limitations of TLS versions that you explicitly

don't support isn't useful.=C2=A0 Remove this paragraph also.



Yes that is TLS1.1. I updated it. I believ=
e the text is useful as it provides a clear justification on why it should =
not be used on TLS version lower than 1.2. More specifically, previous vers=
ion do not support AEAD, but this may not prevent someone using AEAD with t=
hese versions. The reason provided is not AEAD related but PSK related. I b=
elieve it is useful to explicitly justify why the cipher suites defined in =
the document should not be used with previous TLS versions. The text has be=
e suggested by the secdir and I would prefer to keep it, unless there is a =
strong willingness to remove it. =C2=A0 =C2=A0 
=C2=A0 

Nits:

s/pre-master(| secret)/premaster secret/g

Corrected: The text only have premaster secret. =C2=A0 
=C2=A0
=


You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA25=
6

means to use AEAD_AES_128_GCM (and the same for the other

ciphersuites).=C2=A0 I mention this because the order in which the AEAD

algorithms are mentioned is different to the order of the ciphersuites

in the list.




=

Unless I miss your comment, I believe the section 3 already addresses =
it. If not please let me knoe what text you would like to see. 
=C2=A0
"""
3.=C2=A0 ECDHE_PSK with AES-GCM and AES-=
CCM Cipher Suites

=C2=A0=C2=A0 The cipher suites defined in this doc=
ument are based on the AES-GCM
=C2=A0=C2=A0 and AES-CCM Authenticated En=
cryption with Associated Data (AEAD)
=C2=A0=C2=A0 algorithms AEAD_AES_12=
8_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
=C2=A0=C2=A0 defined in [RF=
C5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].

""&qu=
ot;=C2=A0 



On 24 May 2017 at 12:37, Daniel Migault <daniel.migault@ericsson.com> wrote=
:

> re-sending with the version 05 but removing the diff to be under the 1=
00 KB

> limit.

> Yours,

> Daniel

>

> On Tue, May 23, 2017 at 9:28 PM, Daniel Migault

> <d=
aniel.migault@ericsson.com> wrote:

>>

>> Hi Eric,

>>

>> Thank you for the feed backs. The version 05 contains all text cha=
nges you

>> agreed. In addition, the text explaining dictionary/brute force ha=
s been

>> removed and replace by a reference to 4279. The recommendation reg=
arding to

>> all PSK ciphers has been limited to the one of the document.=C2=A0=
 Please see

>> inline for more details.

>>

>> For some reasons I am not able to validate the submission of versi=
on 05. I

>> have attached the diff with version 04 as well as the locally gene=
rated

>> version 05.

>>

>> Yours,

>> Daniel

>>

>> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>>

>>>

>>>

>>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault

>>> <daniel.migault@ericsson.com> wrote:

>>>>

>>>> Hi Eric,

>>>>

>>>> Thank you for your reviews. Please see my responses inline=
. If you agree

>>>> with the text I will update the draft.

>>>>

>>>> Yours,

>>>> Daniel

>>>>

>>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>>>>

>>>>> Eric Rescorla has entered the following ballot positio=
n for

>>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss

>>>>>

>>>>> When responding, please keep the subject line intact a=
nd reply to all

>>>>> email addresses included in the To and CC lines. (Feel=
 free to cut this

>>>>> introductory paragraph, however.)

>>>>>

>>>>>

>>>>> Please refer to

>>>>> https://www.ietf.org/i=
esg/statement/discuss-criteria.html

>>>>> for more information about IESG DISCUSS and COMMENT po=
sitions.

>>>>>

>>>>>

>>>>> The document, along with other ballot positions, can b=
e found here:

>>>>> https://datatrac=
ker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

>>>>>

>>>>>

>>>>>

>>>>> -------------------------------------------------=
---------------------

>>>>> DISCUSS:

>>>>> -------------------------------------------------=
---------------------

>>>>>

>>>>> The following text appears to have been added in -04
>>>>>

>>>>>=C2=A0 =C2=A0 A server receiving a ClientHello and a cl=
ient_version indicating

>>>>>=C2=A0 =C2=A0 (3,1) "TLS 1.0" or (3,2) "=
TLS 1.1" and any of the cipher suites from

>>>>>=C2=A0 =C2=A0 this document in ClientHello.cipher_suite=
s can safely assume that

>>>>> the

>>>>>=C2=A0 =C2=A0 client supports TLS 1.2 and is willing to=
 use it.=C2=A0 The server MUST

>>>>>=C2=A0 =C2=A0 NOT negotiate these cipher suites with TL=
S protocol versions earlier

>>>>>=C2=A0 =C2=A0 than TLS 1.2.=C2=A0 Not requiring clients=
 to indicate their support for

>>>>>=C2=A0 =C2=A0 TLS 1.2 cipher suites exclusively through=
 ClientHello.client_hello

>>>>>=C2=A0 =C2=A0 improves the interoperability in the inst=
alled base and use of TLS

>>>>>=C2=A0 =C2=A0 1.2 AEAD cipher suites without upsetting =
the installed base of

>>>>>=C2=A0 =C2=A0 version-intolerant TLS servers, results i=
n more TLS handshakes

>>>>>=C2=A0 =C2=A0 succeeding and obviates fallback mechanis=
ms.

>>>>>

>>>>> This is a major technical change from -03, which, AFAI=
K, prohibited

>>>>> the server from negotiating these algorithms with TLS =
1.1 and below

>>>>> and maintained the usual TLS version 1.2 negotiation r=
ules.

>>>>>

>>>>> This is a very material technical change. I don't =
consider it wise,

>>>>> but in any case it would absolutely need WG consensus,=
 which I

>>>>> don't believe that it has given the recent introdu=
ction.

>>>>

>>>>

>>>> I agree that the text is a technical change, and that it m=
ay not be

>>>> appropriated to do so now. The reason I included it was th=
at it was conform

>>>> to the previous text, but I agree that implicit assumption=
 of version 1.2

>>>> may need some additional discussion especially regarding R=
FC5246 Appendix E.

>>>> Unless you prefer further discussion I assume the text bel=
ow address your

>>>> concern.

>>>>

>>>> <t>The cipher suites defined in this document MUST N=
OT be negotiated for

>>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT=
 offer one of

>>>> these cipher suites with a (D)TLS version that differs fro=
m TLS 1.2. Servers

>>>> MUST NOT select one of these cipher suites with a TLS vers=
ion that differs

>>>> from TLS 1.2. A client MUST treat the selection of these c=
ipher suites in

>>>> combination with a version of TLS as an error and generate=
 a fatal

>>>> 'illegal_parameter' TLS alert. </t>

>>>

>>>

>>> Yes, this seems fine

>>>

>>>

>>>>> The discussion of dictionary attacks here seems inferi=
or to that

>>>>> in 4279. In particular, you only need to actively atta=
ck one

>>>>> connection to capture the data you need for a brute fo=
rce attack

>>>>> despite the text there referring to trying "diffe=
rent keys".

>>>>> Please correct that.

>>>>>

>>>> I believe the text below address your concern:

>>>>

>>>> OLD:

>>>> <t>Use of Pre-Shared Keys of limited entropy may all=
ow an active

>>>> attacker attempts to connect to the server and try differe=
nt keys.

>>>> For example, limited entropy may be provided by using a sh=
ort PSK in

>>>> which

>>>> case an attacker may perform a brute-force attack. Another=
 example

>>>> includes the use of a PSK=C2=A0 chosen by a human which th=
us may be exposed

>>>> to

>>>> dictionary attacks.</t>

>>>>

>>>> NEW:

>>>> <t>Pre-Shared Keys security relies on its associated=
 entropy, and it is

>>>> RECOMMENDED to follow <xref target=3D"4086"/&=
gt; to ensure the PSK has enough

>>>> entropy. Possible reasons for low entropy includes PSK cho=
sen by humans or

>>>> PSK of small length as well as using random generators wit=
h limited entropy.

>>>> </t>

>>>>

>>>> <t>PSK of limited entropy may allow an attacker to t=
est different PSK

>>>> values against a valid output such as master secret or any=
 output derived

>>>> from it. In this document, the master secret is generated =
using the PSK as

>>>> well as the ECDHE shared secret. The use of ECDHE limits t=
he possibilities

>>>> of passive eavesdropping attackers, as the ECDHE shared se=
cret is not

>>>> expected to be derived from the observed ECDH parameters. =
As a result,

>>>> passive eavesdropping is unlikely to happen, and the colle=
ction of all

>>>> necessary material relies on an active attack.

>>>> An active attacker may collect the necessary material by s=
etting a TLS

>>>> session as a client with the legitimate server. One PSK is=
 tested for each

>>>> session, and a match occurs when key exchange succeeds. On=
 the other hand,

>>>> an active attacker may also consider gathering the necessa=
ry information for

>>>> offline computation. One way consists in getting a legitim=
ate client to

>>>> establish a connection with the attacker. It is also assum=
ed that the client

>>>> will accept the ECDH parameters authenticated by the attac=
ker's private key

>>>> and finally returns the Finished message authenticating th=
e exchange. The

>>>> attacker will be then in possession of all the necessary i=
nformation to

>>>> perform a brute force attack.</t>

>>>

>>>

>>> Is there a reason to not just point directly to the 4279 secur=
ity

>>> considerations?

>>

>>

>> No, basically I tried to complete the previous text that missed th=
e

>> offline use case. The current version just point to 4279, without =
having the

>> above text. If you think the text above is clarifying I can add it=
 as well.

>>>

>>> -

>>>>

>>>>

>>>>>

>>>>>

>>>>> -------------------------------------------------=
---------------------

>>>>> COMMENT:

>>>>> -------------------------------------------------=
---------------------

>>>>>

>>>>> The citations to TLS 1.3 still seem pretty muddled. I =
think you

>>>>> should just stop referencing and discussing 1.3.

>>>>

>>>>

>>>> My understanding of your comment is that mentioning TLS 1.=
3 to further

>>>> insisting that the code point are not valid for TLS 1.3 is=
 confusing. I

>>>> propose to:

>>>>

>>>> Explicitly mention the TLS version in the title:

>>>>

>>>> OLD title:

>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Trans=
port Layer

>>>> Security (TLS)

>>>>

>>>> NEW title:

>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Trans=
port Layer

>>>> Security (TLS)

>>>>

>>>> OLD Introduction:

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0The cipher

>>>>=C2=A0 =C2=A0 suites are defined for version 1.2 of the Tra=
nsport Layer Security

>>>>=C2=A0 =C2=A0 (TLS) [RFC5246] protocol, version 1.2 of the =
Datagram Transport Layer

>>>>=C2=A0 =C2=A0 Security (DTLS) protocol [RFC6347], as well a=
s version 1.3 of TLS

>>>>=C2=A0 =C2=A0 [I-D.ietf-tls-tls13].

>>>>

>>>> NEW introduction

>>>>

>>>> The cipher

>>>>=C2=A0 =C2=A0 suites are defined for version 1.2 of the Tra=
nsport Layer Security

>>>>=C2=A0 =C2=A0 (TLS) [RFC5246] protocol, version 1.2 of the =
Datagram Transport Layer

>>>>=C2=A0 =C2=A0 Security (DTLS) protocol [RFC6347].

>>>>

>>>>

>>>> I suggest to keep the following text of the introduction:<=
br>
>>>>

>>>>

>>>> AEAD algorithms that combine encryption and integrity prot=
ection are

>>>>=C2=A0 =C2=A0 strongly recommended for (D)TLS [RFC7525] and=
 non-AEAD algorithms are

>>>>=C2=A0 =C2=A0 forbidden to use in TLS 1.3 [I-D.ietf-tls-tls=
13].=C2=A0 The AEAD

>>>>=C2=A0 =C2=A0 algorithms considered in this document are AE=
S-GCM and AES-CCM.=C2=A0 The

>>>>=C2=A0 =C2=A0 use of AES-GCM in TLS is defined in [RFC5288]=
 and the use of AES-CCM

>>>>=C2=A0 =C2=A0 is defined in [RFC6655].

>>>

>>>

>>> Yes, this seems fine.

>>>

>>>

>>>>

>>>> I suggest to keep the following text of the Applicable ver=
sions

>>>> sections, as I believe the section discusses the cipher su=
ites against all

>>>> existing TLS versions. In addition, it also justifies some=
what that we only

>>>> defined cipher suites that are compatible with TLS1.3.

>>>>

>>>>=C2=A0 =C2=A0 TLS version 1.3 and later negotiate these fea=
tures in a different

>>>>=C2=A0 =C2=A0 manner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separat=
es authentication and cipher

>>>>=C2=A0 =C2=A0 suite negotiation [I-D.ietf-tls-tls13] Sectio=
n 1.2.=C2=A0 TLS 1.3 supports

>>>>=C2=A0 =C2=A0 PSK with ECDHE key exchange and the cipher su=
ites

>>>>=C2=A0 =C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA38=
4,

>>>>=C2=A0 =C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_=
SHA256 are part of the

>>>>=C2=A0 =C2=A0 specification.=C2=A0 As a result, TLS 1.3 and=
 higher versions, negotiate

>>>>=C2=A0 =C2=A0 and support these cipher suites in a differen=
t way.

>>>

>>>

>>> OK.

>>>

>>>>

>>>> I suggest to remove the reference to TLS1.3 in the securit=
y

>>>> considerations

>>>>

>>>> OLD

>>>>

>>>>=C2=A0 The security considerations in TLS 1.2 [RFC5246], DT=
LS 1.2 [RFC6347],

>>>>=C2=A0 =C2=A0 TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5=
489], AES-GCM [RFC5288],

>>>>=C2=A0 =C2=A0 and AES-CCM [RFC6655] apply to this document =
as well.

>>>>

>>>> NEW

>>>>

>>>>=C2=A0 The security considerations in TLS 1.2 [RFC5246], DT=
LS 1.2 [RFC6347],

>>>>=C2=A0 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [=
RFC6655] apply

>>>>=C2=A0 to this document as well.

>>>>>

>>>>>

>>>>> S 2.

>>>>> I'm not sure that the discussion of the PRF is hel=
pful here in

>>>>> mandating the non-use of these cipher suites with TLS =
1.1 and

>>>>> below.

>>>>

>>>>

>>>> I find the text useful as it gives an idea why even introd=
ucing AEAD in

>>>> TLS version lower than 1.2 is a bad idea, so I would prefe=
r to keep it. The

>>>> text has been changed to

>>>>

>>>> OLD:

>>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_=
PSK.

>>>>

>>>> NEW:

>>>> As such,=C2=A0 all ECDHE_PSK

>>>> ciphers, including those defined outside this document, SH=
OULD NOT be

>>>> negotiated in TLS versions prior to 1.2.

>>>

>>>

>>> I don't think you should be levying a new normative requir=
ement like this

>>> for other ciphers

>>> i this document

>>

>>

>> Consideration for other ciphers has been removed. The requirement =
is

>> limited to the ciphers of the document. The new text is:

>>

>> As such, all ECDHE_PSK ciphers, including those defined in this do=
cument,

>> SHOULD NOT be

>> negotiated in TLS versions prior to 1.2.

>>>

>>>

>>> -Ek

>>> r

>>>

>>

>

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls

>







--94eb2c1483a0941ad805504669a0--


From nobody Wed May 24 08:16:09 2017
Return-Path: 
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 840EC1293E8; Wed, 24 May 2017 08:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=eZyZpoQn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OG7HUFVv
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 f9ML4novpkcW; Wed, 24 May 2017 08:16:00 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D760128ACA; Wed, 24 May 2017 08:16:00 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 092F020B7E; Wed, 24 May 2017 11:15:59 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 24 May 2017 11:15:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FACxpPwPJEeI64eihl 4Q9cHDtuPyuRsBYhS/nAj6UOk=; b=eZyZpoQnX+qw5WCLguJ5vbJMRNynL1q4Fl 3/9ITBsodhclOk0Ugx7T/aenrxq4eaugadQo8w3sZPh1DHHMAqE0fFOd+1udAXk1 yIgGE5dOP7PmvPL7L/yUZZWc7JsPuBRSXY55uObPc4U7HTICEmBiTqYyimsyjBmC zws7DifB+BEwqqFPgmvl5wi9QsgYdW/JeC5pq6DcQwfdijq4rzzxxpQq7ssUEwzI zOSuXAcBQp+7hm5NBKDKRMpshViWzjPCUFpZlEadIFHKIUw4VhuY1hK4mKLEzbWb bcQRvsJfj5mmKoGPjUvneApwOnA7I3dKcLZqQj52LbSZ2kZTbgZQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=FACxpPwPJEeI64eihl4Q9cHDtuPyuRsBYhS/nAj6UOk=; b=OG7HUFVv PxXmUBSMuaDUGwHE/VCUe6VGFSxbXgZAze6FYsR5CM/uq9e1SrYpB1nX9cpltiNu UWKRH3CO46/IDzO2jolt9FqGkWcqsM2MfB+lA7oXWybfY+8Zy1jG54jumM2G03kX DpBMynr0KdUlhGLY4ST6/6geaDcMMVWjCqWZB8Qzynyiaithv2AkJCD+Vokv+8rI XQLC+ALm6TQVwUILj1+Fbwv+Ol6gQNXuPWAkeWfPGoWM6z/2lgyn7tkjyeOMCBLc myhA6WkFZBqAS2LIWVEhvOZv63jYUofgRDeLO0/QiWsVLY8E5vEXVPsXV8nGiXjt BbG6c2IkaLePaA==
X-ME-Sender: 
X-Sasl-enc: pVLsqN0P8qQ14/rns7nTGWzSqIEfBg2Nllbw2EOHSsn9 1495638958
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 16BED7E808; Wed, 24 May 2017 11:15:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: <149523380739.28567.9584998643479497589@ietfa.amsl.com>
Date: Wed, 24 May 2017 11:15:56 -0400
Cc: "gen-art >> General area reviewing team" , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <34EDA6D1-71BA-4E4C-BB9F-5E8FD05786D9@cooperw.in>
References: <149523380739.28567.9584998643479497589@ietfa.amsl.com>
To: Dan Romascanu 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:16:02 -0000

Dan, thank you for your reviews of this document and thanks to the =
authors for providing clarifications. I have balloted No Objection.

Alissa

> On May 19, 2017, at 6:43 PM, Dan Romascanu  wrote:
>=20
> Reviewer: Dan Romascanu
> Review result: Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>=20
> For more information, please see the FAQ at
>=20
> .
>=20
> Document: draft-ietf-tls-ecdhe-psk-aead-??
> Reviewer: Dan Romascanu
> Review Date: 2017-05-19
> IETF LC End Date: 2017-05-18
> IESG Telechat date: 2017-05-25
>=20
> Summary:
>=20
> This is a straight-forward and clear document that defines several new
> cipher suites for the Transport Layer Security (TLS) protocol version
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> with Pre-Shared Key (ECDHE_PSK) key exchange together with the
> Authenticated Encryption with Associated Data (AEAD) algorithms
> AES-GCM and AES-CCM. The document is well written and I appreciate the
> effort to clarify in the Introduction the context, what was missing,
> and why the document is necessary. One issue raised in my initial
> review for draft-03 was addressed, discussed and draft-04 includes
> useful clarification text.=20
>=20
> The document is Ready
>=20
> Major issues:
>=20
> Minor issues:
>=20
> Nits/editorial comments:=20
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Wed May 24 08:32:49 2017
Return-Path: 
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 574C812EB0D for ; Wed, 24 May 2017 08:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level: 
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 qKiPuO_O060z for ; Wed, 24 May 2017 08:32:36 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0940612EB0A for ; Wed, 24 May 2017 08:32:36 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id l74so91022235ywe.2 for ; Wed, 24 May 2017 08:32:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mWnk5ZJewVfH/xTJBc8jDV0vGTDP0KnRHMjJXRg7EJY=; b=XBHav5/B5thILCWJbpTmuvHVAmW1ueEAL5dkCKd40AqcCAf08NdXPQ8tDyyTgnMp7e vP+5FhDLYQnK+bJEr15+hjZ6Q/C6QEmUfZ6fhb56o7fgSmzSoBAuAMQ74HWtrPNQXiDy XvtZqk+DmVhfFYs/hRkOkjTExYF2PdnX6q0h0ky98OGb9H54gp3LcdWRk4X/X+fmFxtJ Q1aTfJ2nUXKgf21b3PVFNgA3DK4tl643GevVs5+yZzA+fUKdD0ym6WxtFFoDTcqxTXrV LSxMgydCAQ3+UBTuBSW420UQ90cjrkEvGM7Q53+rvLTyNoBvZhrbFJMXJYKHUBe3QsK+ 2UFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mWnk5ZJewVfH/xTJBc8jDV0vGTDP0KnRHMjJXRg7EJY=; b=d965y8DvOw+mD47PrH3ekNmXYT+Rr+fIgt03JnLLlbkq0UPxMnS00eSSIE2GWPcDDp 46WPPTGKYk+i3pp1Xd2wOqMYRkkKTcN3pK9qdh7hiLa+P5VKz8tLDKWUSbqksS24M3m/ 0Uo3hF7MlXQAaOMMyQ6CTX/t2oba8LjK1jh3X9sMEYLlgImNY32pGNdZAiEgS2wVR38k qFD4Jjyc8vBknt7XNq1wKIXMLCzQADyvzOKc9JdtsmGdwbQkpUbWxkl+UPrOw9kC60tA qGWQnWr2d7x39R15tgNThzsTxMrsWhVw8gPPs5g+9WHmXQw42+2KePoYDKj56XPV3sjk S+cA==
X-Gm-Message-State: AODbwcA+XynmoF1fGcoDamN/wLP8CQOxJYyWqvOMZD7w5nRUSD8l4aXI f4htSYqeArEOUD8UCk/u6qSWALjy8Ldp
X-Received: by 10.129.96.69 with SMTP id u66mr30648341ywb.241.1495639955134; Wed, 24 May 2017 08:32:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Wed, 24 May 2017 08:32:34 -0700 (PDT)
In-Reply-To: <20170524143042.GA31858@LK-Perkele-V2.elisa-laajakaista.fi>
References:      <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>  <071fb4df-56e6-d82a-87de-3db084235021@akamai.com> <20170524143042.GA31858@LK-Perkele-V2.elisa-laajakaista.fi>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 24 May 2017 08:32:34 -0700
Message-ID: 
To: Ilari Liusvaara 
Cc: Benjamin Kaduk , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11471c003d533b055046d096"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:32:41 -0000

--001a11471c003d533b055046d096
Content-Type: text/plain; charset="UTF-8"

On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara 
wrote:
>
> > Right, this would bring replays down from the millions hypothesized for
> > the weak time-based thing to more like tens, which is kind of in the
> > regime that we are currently in with (at least some) application
> behavior.
>
> Actually, even tens of replays at TLS level is quite dangerous,
> especially if to different servers (bad information leaks via cache
> attacks).
>

It hard stops replays, but does nothing about retries, and I think that's
ok. The client is in much more control of retries, and it's similar (if not
identical) to what can happen today with an interrupted TCP or TLS
connection. If a client permits hundreds, or millions of forced retries, I
think that's more appropriately handled at the client/application level,
but keep in mind there are typically seconds between the retries and the
rate of attack is slow.

Replays are when an attacker can send the same data at-will and it's
completely unknown to the client, it can happen out of band over different
network connectivity, in a very short and sharp interval of time, possibly
even to different server endpoints, and can be used by attackers to gather
information. These I think need to be mitigated at the TLS level; and
should be hard-stopped.

> Another crazy idea would be to just say that servers MUST limit the use
> > of a single binder to at most 100 times, with the usual case being just
> > once, to allow for alternative designs that have weaker distributed
> > consensus requirements (but still describe these current two methods as
> > examples of ways to do so).
>
> You actually need strong distributed consensus about all accepted
> 0-RTT here.
>

This pattern doesn't need strong consensus. If you have 10 servers, you
could give each 10 goes at the ticket, and let each exhaust its 10 attempts
without any coordination or consensus. You likely won't get to "exactly
100", but you will get to "at most 100 times".

But the inner critical section would be inherently more complicated.  For
the at most once case we need to a critical section that performs an
exclusive-read-and-delete atomically. It's a mutex lock or a clever
construction of atomic instructions.  For "at most N" we now need to
perform a decrement and write in the critical section, and it becomes more
like a semaphore.

It's probably not a pattern that's worth the trade-offs.

-- 
Colm

--001a11471c003d533b055046d096
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:

> Right, this would bring replays down from the millions hypothesized fo=
r

> the weak time-based thing to more like tens, which is kind of in the
> regime that we are currently in with (at least some) application behav=
ior.



Actually, even tens of replays at TLS level is quite dangerous,

especially if to different servers (bad information leaks via cache

attacks).

It hard stops replays, but do=
es nothing about retries, and I think that's ok. The client is in much =
more control of retries, and it's similar (if not identical) to what ca=
n happen today with an interrupted TCP or TLS connection. If a client permi=
ts hundreds, or millions of forced retries, I think that's more appropr=
iately handled at the client/application level, but keep in mind there are =
typically seconds between the retries and the rate of attack is slow.=C2=A0=


Replays are when an attacker can send the same da=
ta at-will and it's completely unknown to the client, it can happen out=
 of band over different network connectivity, in a very short and sharp int=
erval of time, possibly even to different server endpoints, and can be used=
 by attackers to gather information. These I think need to be mitigated at =
the TLS level; and should be hard-stopped.=C2=A0


> Another crazy idea would be to just say that servers MUST limit the us=
e

> of a single binder to at most 100 times, with the usual case being jus=
t

> once, to allow for alternative designs that have weaker distributed
> consensus requirements (but still describe these current two methods a=
s

> examples of ways to do so).



You actually need strong distributed consensus about all accepted
0-RTT here.

This pattern doesn't ne=
ed strong consensus. If you have 10 servers, you could give each 10 goes at=
 the ticket, and let each exhaust its 10 attempts without any coordination =
or consensus. You likely won't get to "exactly 100", but you =
will get to "at most 100 times".=C2=A0

B=
ut the inner critical section would be inherently more complicated.=C2=A0 F=
or the at most once case we need to a critical section that performs an exc=
lusive-read-and-delete atomically. It's a mutex lock or a clever constr=
uction of atomic instructions.=C2=A0 For "at most N" we now need =
to perform a decrement and write in the critical section, and it becomes mo=
re like a semaphore.=C2=A0

It's probably not a=
 pattern that's worth the trade-offs.=C2=A0

-=
- 
Col=
m




--001a11471c003d533b055046d096--


From nobody Wed May 24 08:59:36 2017
Return-Path: 
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 3B03812946F; Wed, 24 May 2017 08:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hee5lj4vdXFc; Wed, 24 May 2017 08:59:30 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5506127011; Wed, 24 May 2017 08:59:29 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id a5so56604373lfh.2; Wed, 24 May 2017 08:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AKkUKPlHlY+7TkGn1QAcx87IKnM88ueIDY2AsVtXLYA=; b=CAESolledilAfjh7iUxgpXcOGg0utlfGsfeI/FrAcUgcUL8y+OEgcLt7toJ/9oZg+r qhactRLqSMwNU23u92s0eGzh0GogmBlpx0G17gnwObT5BBoEGuCteJQ3Jqrrin07wFyp uFenrwirv2liDsQh54oorDkpFy/dvVuEWAtfQywaV2HXO+4KQndCUTj1/PQXTD4a7Hnq 9rhRWYn6QCS9JhsEYC3S7KjerJ8e7Z/hep0UQD1hjt71UGB38mPnBGheiLi2WSBhWzJ2 OObYVLj9oxy8b13ej4OSAtBHmCByoqcDYsIKMlyYYv3jIowo7oh9FOSCN39M3OkDG5mH Wycg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AKkUKPlHlY+7TkGn1QAcx87IKnM88ueIDY2AsVtXLYA=; b=t8X8iTD9p5s//omzsC/qL7f2kIMPvRLvbRejPeFrqigp/le+XtlSflxQSbKu+DSNHL aqjXP+YGlZ8c9y3g1GwdL8/v0Z+b74NP2yzXf/xVcUzTfG3lrY9OiqEcnVbnr2f6jCDr 0EIjjoSodqlzAVUA06gcRA4SGBoWmk6KWnRMTkv5nofBwxgPXZ85ewtFAeYWTdPL6roi AVc/D5qNlVI8QNK1v6fm2N4NM3kGdAL6tXtJYSycO0u3dX4QSkz+xOaCk00bebuHEbZw GQh6QGIj2uYWEiu09a9nZP1td5fI6oWIGndlpWpbuhZNQ6EJgcufgXMOSmyZ4dPlUqyv UFYQ==
X-Gm-Message-State: AODbwcDBugyEiAB9eEOPSDEr+M6usOaqg1C3TQyZsmfM8a01ljADh8xr yGv0BXPNtve7dz9D301efzegVC+Py4Og
X-Received: by 10.25.104.5 with SMTP id d5mr10652566lfc.147.1495641567966; Wed, 24 May 2017 08:59:27 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Wed, 24 May 2017 08:59:27 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>       
From: Daniel Migault 
Date: Wed, 24 May 2017 11:59:27 -0400
X-Google-Sender-Auth: w-cxFBOs2QAfmhlSBIvkDTqoNgI
Message-ID: 
To: Joseph Salowey 
Cc: Martin Thomson , Eric Rescorla ,  tls-chairs , The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="f403045e589c5ec17b0550473008"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:59:35 -0000

--f403045e589c5ec17b0550473008
Content-Type: text/plain; charset="UTF-8"

Hi,

Thank Joe for the clarification. I removed section 4 and instead have the
following section 3. This is the version 06.

I will post it as soon as the datatracker allows me to submit a new
version, so please let me know if that address all concerns.

Yours,
Daniel

3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites

   The cipher suites defined in this document are based on the AES-GCM
   and AES-CCM Authenticated Encryption with Associated Data (AEAD)
   algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
   defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].

   Messages and premaster secret construction in this document are
   defined in [RFC5489].  The ServerKeyExchange and ClientKeyExchange
   messages are used and the premaster secret is computed as for the
   ECDHE_PSK key exchange.  The elliptic curve parameters used in in the
   Diffie-Hellman parameters are negotiated using extensions defined in
   [I-D.ietf-tls-rfc4492bis].

   For TLS 1.2, the following cipher suites are defined:

   TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD,0xTBD};
   TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD,0xTBD};
   TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD,0xTBD};
   TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD,0xTBD};

   The assigned code points can only be used for TLS 1.2.

   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].



On Wed, May 24, 2017 at 11:03 AM, Joseph Salowey  wrote:

> Hi Daniel,
>
> Thanks for putting this revision together.  The original text in draft 4
> went beyond the scope of what should be in the document (I was too hasty in
> my review of the document and discussion on the list).   Your current
> proposal is an improvement, but it still discusses behavior that could
> either conflict with other documents or discusses behavior that is not in
> scope.
>
> My suggestion is to replace section 4 with the following paragraph (I
> think this is similar to what Martin suggests):
>
> "The cipher suites defined in this document MUST NOT be negotiated for any
> version of (D)TLS other than TLS 1.2.  Servers MUST NOT select one of these
> cipher suites when selecting TLS version other than TLS 1.2.  A client MUST
> treat the selection of these cipher suites in combination with a different
> version of TLS as an error and generate a fatal 'illegal_parameter' TLS
> alert."
>
> I think it would also be OK to add the following to point readers to
> equivalent ciphers in 1.3.  Here is some suggested text that could go in
> the revised section 4:
>
> "Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
> TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to support
> equivalent functionality in TLS 1.3 [TLS 1.3]."
>
> Thanks,
>
> Joe
>
>
> On Wed, May 24, 2017 at 7:04 AM, Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
>> Hi Martin,
>>
>> Thank you for your review. Some comment were about text in the
>> applicability section. I think I agree with you that this section details
>> and clarifies  the following sentence of the previous section:  """ The
>> assigned code points can only be used for TLS 1.2.""". Most of the text of
>> this section has been added in order to address comments, thus in order to
>> make this section helpful for many readers, I prefer to keep most of the
>> text you mentioned as not useful.
>>
>> Please see inline for more detail responses and let me know if that
>> address your comments.
>>
>> Yours,
>> Daniel
>>
>> On Wed, May 24, 2017 at 12:09 AM, Martin Thomson <
>> martin.thomson@gmail.com> wrote:
>>
>>> Hi Daniel,
>>>
>>> This removes the offending text.
>>>
>>> This is incorrect:
>>>
>>> > Clients MUST NOT offer one of these cipher suites with a (D)TLS
>>> version that differs from TLS 1.2.
>>>
>>> It should be possible to offer these when attempting to negotiate TLS
>>> 1.3.  The server simply cannot negotiate these cipher suites if it
>>> chooses to use 1.3.  I'd remove that sentence (and the one following
>>> it, since it's redundant with the first sentence of the paragraph).
>>>
>>> My understanding is that you suggest to remove "Clients MUST NOT offer
>> one ..." for the following reasons:
>>
>> A) it is redundant with the first sentence of the paragraph: "The cipher
>> suites defined in this document MUST NOT be negotiated ...".  This sentence
>> clarifies on the client side what "MUST NOT be negotiated" means, and the
>> same is done for the server side. If we provide clarification for the
>> server side, I would prefer to keep a clarification for the client side as
>> well.
>>
>> B) It is not true as TLS1.3 enables these cipher suites to be negotiated
>> with TLS1.3. In the text cipher suites stands for the cipher suites code
>> points of the IANA registry.  Maybe we can have a better wording. However I
>> believe the next paragraph clarifies that TLS1.3 negotiates these ciphers
>> suites in a different way. Would the following wording address your
>> comment. If so I will update the section to remove the confusion.
>>
>> "Clients MUST NOT offer one of the cipher suites code points defined in
>> the document with a (D)TLS version that differs from TLS 1.2."
>>
>> The text in question is:
>> """
>>    The cipher suites defined in this document MUST NOT be negotiated for
>>    any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
>>    of these cipher suites with a (D)TLS version that differs from TLS
>>    1.2.  Servers MUST NOT select one of these cipher suites with a TLS
>>    version that differs from TLS 1.2.  A client MUST treat the selection
>>    of these cipher suites in combination with a version of TLS as an
>>    error and generate a fatal 'illegal_parameter' TLS alert.
>>
>> """
>>
>>
>>> As others have noted, the paragraph about TLS 1.3 isn't helpful and
>>> should be removed.
>>>
>>>
>> Suggestion to remove TLS1.3 related text was to clarify that the cipher
>> suites were only defined for TLS1.2. Unless I missed something we have
>> removed most of the text that could cause confusion. On the other hand,
>> TLS1.3 has been designed, and we also have received comments to position
>> the defined cipher suites toward TLS1.3 as we do fro TLS1.0 and TLS1.1.
>> This is the intent of the remaining text mentioning TLS1.3.
>>
>> In the applicable version section, the text for TLS1.3 is intended to
>> clarify why the cipher suites are restricted to TLS1.2. I believe this is
>> useful for readers not so familiar with TLS1.3 that may not be aware of how
>> TLS1.3 negotiate ciphers. My personal opinion is that it might be better to
>> have it explicit rather than implicit, and I would prefer to keep the text
>> below:
>>
>> """
>>    TLS version 1.3 and later negotiate these features in a different
>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
>>    suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
>>    PSK with ECDHE key exchange and the cipher suites
>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
>>    specification.  As a result, TLS 1.3 and higher versions, negotiate
>>    and support these cipher suites in a different way.
>>
>> """
>>
>>
>>
>>
>>> This:
>>>
>>> > In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
>>> [RFC4346] split the pre-master into two  parts.  The PRF results from
>>> mixing the two pseudorandom streams with distinct hash functions (MD5 and
>>> SHA-1) by exclusive-ORing them together.
>>>
>>> You mean TLS 1.1 rather than 1.2.  But as with the former paragraph,
>>> talking about the limitations of TLS versions that you explicitly
>>> don't support isn't useful.  Remove this paragraph also.
>>>
>>>
>> Yes that is TLS1.1. I updated it. I believe the text is useful as it
>> provides a clear justification on why it should not be used on TLS version
>> lower than 1.2. More specifically, previous version do not support AEAD,
>> but this may not prevent someone using AEAD with these versions. The reason
>> provided is not AEAD related but PSK related. I believe it is useful to
>> explicitly justify why the cipher suites defined in the document should not
>> be used with previous TLS versions. The text has bee suggested by the
>> secdir and I would prefer to keep it, unless there is a strong willingness
>> to remove it.
>>
>>
>>> Nits:
>>> s/pre-master(| secret)/premaster secret/g
>>>
>>
>> Corrected: The text only have premaster secret.
>>
>>
>>> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>>> means to use AEAD_AES_128_GCM (and the same for the other
>>> ciphersuites).  I mention this because the order in which the AEAD
>>> algorithms are mentioned is different to the order of the ciphersuites
>>> in the list.
>>>
>>>
>> Unless I miss your comment, I believe the section 3 already addresses it.
>> If not please let me knoe what text you would like to see.
>>
>> """
>> 3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites
>>
>>    The cipher suites defined in this document are based on the AES-GCM
>>    and AES-CCM Authenticated Encryption with Associated Data (AEAD)
>>    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
>>    defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].
>>
>> """
>>
>>>
>>> On 24 May 2017 at 12:37, Daniel Migault 
>>> wrote:
>>> > re-sending with the version 05 but removing the diff to be under the
>>> 100 KB
>>> > limit.
>>> > Yours,
>>> > Daniel
>>> >
>>> > On Tue, May 23, 2017 at 9:28 PM, Daniel Migault
>>> >  wrote:
>>> >>
>>> >> Hi Eric,
>>> >>
>>> >> Thank you for the feed backs. The version 05 contains all text
>>> changes you
>>> >> agreed. In addition, the text explaining dictionary/brute force has
>>> been
>>> >> removed and replace by a reference to 4279. The recommendation
>>> regarding to
>>> >> all PSK ciphers has been limited to the one of the document.  Please
>>> see
>>> >> inline for more details.
>>> >>
>>> >> For some reasons I am not able to validate the submission of version
>>> 05. I
>>> >> have attached the diff with version 04 as well as the locally
>>> generated
>>> >> version 05.
>>> >>
>>> >> Yours,
>>> >> Daniel
>>> >>
>>> >> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault
>>> >>>  wrote:
>>> >>>>
>>> >>>> Hi Eric,
>>> >>>>
>>> >>>> Thank you for your reviews. Please see my responses inline. If you
>>> agree
>>> >>>> with the text I will update the draft.
>>> >>>>
>>> >>>> Yours,
>>> >>>> Daniel
>>> >>>>
>>> >>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla 
>>> wrote:
>>> >>>>>
>>> >>>>> Eric Rescorla has entered the following ballot position for
>>> >>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>>> >>>>>
>>> >>>>> When responding, please keep the subject line intact and reply to
>>> all
>>> >>>>> email addresses included in the To and CC lines. (Feel free to cut
>>> this
>>> >>>>> introductory paragraph, however.)
>>> >>>>>
>>> >>>>>
>>> >>>>> Please refer to
>>> >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> >>>>> for more information about IESG DISCUSS and COMMENT positions.
>>> >>>>>
>>> >>>>>
>>> >>>>> The document, along with other ballot positions, can be found here:
>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ------------------------------------------------------------
>>> ----------
>>> >>>>> DISCUSS:
>>> >>>>> ------------------------------------------------------------
>>> ----------
>>> >>>>>
>>> >>>>> The following text appears to have been added in -04
>>> >>>>>
>>> >>>>>    A server receiving a ClientHello and a client_version indicating
>>> >>>>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites
>>> from
>>> >>>>>    this document in ClientHello.cipher_suites can safely assume
>>> that
>>> >>>>> the
>>> >>>>>    client supports TLS 1.2 and is willing to use it.  The server
>>> MUST
>>> >>>>>    NOT negotiate these cipher suites with TLS protocol versions
>>> earlier
>>> >>>>>    than TLS 1.2.  Not requiring clients to indicate their support
>>> for
>>> >>>>>    TLS 1.2 cipher suites exclusively through
>>> ClientHello.client_hello
>>> >>>>>    improves the interoperability in the installed base and use of
>>> TLS
>>> >>>>>    1.2 AEAD cipher suites without upsetting the installed base of
>>> >>>>>    version-intolerant TLS servers, results in more TLS handshakes
>>> >>>>>    succeeding and obviates fallback mechanisms.
>>> >>>>>
>>> >>>>> This is a major technical change from -03, which, AFAIK, prohibited
>>> >>>>> the server from negotiating these algorithms with TLS 1.1 and below
>>> >>>>> and maintained the usual TLS version 1.2 negotiation rules.
>>> >>>>>
>>> >>>>> This is a very material technical change. I don't consider it wise,
>>> >>>>> but in any case it would absolutely need WG consensus, which I
>>> >>>>> don't believe that it has given the recent introduction.
>>> >>>>
>>> >>>>
>>> >>>> I agree that the text is a technical change, and that it may not be
>>> >>>> appropriated to do so now. The reason I included it was that it was
>>> conform
>>> >>>> to the previous text, but I agree that implicit assumption of
>>> version 1.2
>>> >>>> may need some additional discussion especially regarding RFC5246
>>> Appendix E.
>>> >>>> Unless you prefer further discussion I assume the text below
>>> address your
>>> >>>> concern.
>>> >>>>
>>> >>>> The cipher suites defined in this document MUST NOT be
>>> negotiated for
>>> >>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer
>>> one of
>>> >>>> these cipher suites with a (D)TLS version that differs from TLS
>>> 1.2. Servers
>>> >>>> MUST NOT select one of these cipher suites with a TLS version that
>>> differs
>>> >>>> from TLS 1.2. A client MUST treat the selection of these cipher
>>> suites in
>>> >>>> combination with a version of TLS as an error and generate a fatal
>>> >>>> 'illegal_parameter' TLS alert. 
>>> >>>
>>> >>>
>>> >>> Yes, this seems fine
>>> >>>
>>> >>>
>>> >>>>> The discussion of dictionary attacks here seems inferior to that
>>> >>>>> in 4279. In particular, you only need to actively attack one
>>> >>>>> connection to capture the data you need for a brute force attack
>>> >>>>> despite the text there referring to trying "different keys".
>>> >>>>> Please correct that.
>>> >>>>>
>>> >>>> I believe the text below address your concern:
>>> >>>>
>>> >>>> OLD:
>>> >>>> Use of Pre-Shared Keys of limited entropy may allow an active
>>> >>>> attacker attempts to connect to the server and try different keys.
>>> >>>> For example, limited entropy may be provided by using a short PSK in
>>> >>>> which
>>> >>>> case an attacker may perform a brute-force attack. Another example
>>> >>>> includes the use of a PSK  chosen by a human which thus may be
>>> exposed
>>> >>>> to
>>> >>>> dictionary attacks.
>>> >>>>
>>> >>>> NEW:
>>> >>>> Pre-Shared Keys security relies on its associated entropy, and
>>> it is
>>> >>>> RECOMMENDED to follow  to ensure the PSK has
>>> enough
>>> >>>> entropy. Possible reasons for low entropy includes PSK chosen by
>>> humans or
>>> >>>> PSK of small length as well as using random generators with limited
>>> entropy.
>>> >>>> 
>>> >>>>
>>> >>>> PSK of limited entropy may allow an attacker to test different
>>> PSK
>>> >>>> values against a valid output such as master secret or any output
>>> derived
>>> >>>> from it. In this document, the master secret is generated using the
>>> PSK as
>>> >>>> well as the ECDHE shared secret. The use of ECDHE limits the
>>> possibilities
>>> >>>> of passive eavesdropping attackers, as the ECDHE shared secret is
>>> not
>>> >>>> expected to be derived from the observed ECDH parameters. As a
>>> result,
>>> >>>> passive eavesdropping is unlikely to happen, and the collection of
>>> all
>>> >>>> necessary material relies on an active attack.
>>> >>>> An active attacker may collect the necessary material by setting a
>>> TLS
>>> >>>> session as a client with the legitimate server. One PSK is tested
>>> for each
>>> >>>> session, and a match occurs when key exchange succeeds. On the
>>> other hand,
>>> >>>> an active attacker may also consider gathering the necessary
>>> information for
>>> >>>> offline computation. One way consists in getting a legitimate
>>> client to
>>> >>>> establish a connection with the attacker. It is also assumed that
>>> the client
>>> >>>> will accept the ECDH parameters authenticated by the attacker's
>>> private key
>>> >>>> and finally returns the Finished message authenticating the
>>> exchange. The
>>> >>>> attacker will be then in possession of all the necessary
>>> information to
>>> >>>> perform a brute force attack.
>>> >>>
>>> >>>
>>> >>> Is there a reason to not just point directly to the 4279 security
>>> >>> considerations?
>>> >>
>>> >>
>>> >> No, basically I tried to complete the previous text that missed the
>>> >> offline use case. The current version just point to 4279, without
>>> having the
>>> >> above text. If you think the text above is clarifying I can add it as
>>> well.
>>> >>>
>>> >>> -
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ------------------------------------------------------------
>>> ----------
>>> >>>>> COMMENT:
>>> >>>>> ------------------------------------------------------------
>>> ----------
>>> >>>>>
>>> >>>>> The citations to TLS 1.3 still seem pretty muddled. I think you
>>> >>>>> should just stop referencing and discussing 1.3.
>>> >>>>
>>> >>>>
>>> >>>> My understanding of your comment is that mentioning TLS 1.3 to
>>> further
>>> >>>> insisting that the code point are not valid for TLS 1.3 is
>>> confusing. I
>>> >>>> propose to:
>>> >>>>
>>> >>>> Explicitly mention the TLS version in the title:
>>> >>>>
>>> >>>> OLD title:
>>> >>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>>> >>>> Security (TLS)
>>> >>>>
>>> >>>> NEW title:
>>> >>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>>> >>>> Security (TLS)
>>> >>>>
>>> >>>> OLD Introduction:
>>> >>>>
>>> >>>>     The cipher
>>> >>>>    suites are defined for version 1.2 of the Transport Layer
>>> Security
>>> >>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport
>>> Layer
>>> >>>>    Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>>> >>>>    [I-D.ietf-tls-tls13].
>>> >>>>
>>> >>>> NEW introduction
>>> >>>>
>>> >>>> The cipher
>>> >>>>    suites are defined for version 1.2 of the Transport Layer
>>> Security
>>> >>>>    (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport
>>> Layer
>>> >>>>    Security (DTLS) protocol [RFC6347].
>>> >>>>
>>> >>>>
>>> >>>> I suggest to keep the following text of the introduction:
>>> >>>>
>>> >>>>
>>> >>>> AEAD algorithms that combine encryption and integrity protection are
>>> >>>>    strongly recommended for (D)TLS [RFC7525] and non-AEAD
>>> algorithms are
>>> >>>>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].  The AEAD
>>> >>>>    algorithms considered in this document are AES-GCM and AES-CCM.
>>> The
>>> >>>>    use of AES-GCM in TLS is defined in [RFC5288] and the use of
>>> AES-CCM
>>> >>>>    is defined in [RFC6655].
>>> >>>
>>> >>>
>>> >>> Yes, this seems fine.
>>> >>>
>>> >>>
>>> >>>>
>>> >>>> I suggest to keep the following text of the Applicable versions
>>> >>>> sections, as I believe the section discusses the cipher suites
>>> against all
>>> >>>> existing TLS versions. In addition, it also justifies somewhat that
>>> we only
>>> >>>> defined cipher suites that are compatible with TLS1.3.
>>> >>>>
>>> >>>>    TLS version 1.3 and later negotiate these features in a different
>>> >>>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and
>>> cipher
>>> >>>>    suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3
>>> supports
>>> >>>>    PSK with ECDHE key exchange and the cipher suites
>>> >>>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>> >>>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of
>>> the
>>> >>>>    specification.  As a result, TLS 1.3 and higher versions,
>>> negotiate
>>> >>>>    and support these cipher suites in a different way.
>>> >>>
>>> >>>
>>> >>> OK.
>>> >>>
>>> >>>>
>>> >>>> I suggest to remove the reference to TLS1.3 in the security
>>> >>>> considerations
>>> >>>>
>>> >>>> OLD
>>> >>>>
>>> >>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2
>>> [RFC6347],
>>> >>>>    TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM
>>> [RFC5288],
>>> >>>>    and AES-CCM [RFC6655] apply to this document as well.
>>> >>>>
>>> >>>> NEW
>>> >>>>
>>> >>>>  The security considerations in TLS 1.2 [RFC5246], DTLS 1.2
>>> [RFC6347],
>>> >>>>  ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [RFC6655] apply
>>> >>>>  to this document as well.
>>> >>>>>
>>> >>>>>
>>> >>>>> S 2.
>>> >>>>> I'm not sure that the discussion of the PRF is helpful here in
>>> >>>>> mandating the non-use of these cipher suites with TLS 1.1 and
>>> >>>>> below.
>>> >>>>
>>> >>>>
>>> >>>> I find the text useful as it gives an idea why even introducing
>>> AEAD in
>>> >>>> TLS version lower than 1.2 is a bad idea, so I would prefer to keep
>>> it. The
>>> >>>> text has been changed to
>>> >>>>
>>> >>>> OLD:
>>> >>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
>>> >>>>
>>> >>>> NEW:
>>> >>>> As such,  all ECDHE_PSK
>>> >>>> ciphers, including those defined outside this document, SHOULD NOT
>>> be
>>> >>>> negotiated in TLS versions prior to 1.2.
>>> >>>
>>> >>>
>>> >>> I don't think you should be levying a new normative requirement like
>>> this
>>> >>> for other ciphers
>>> >>> i this document
>>> >>
>>> >>
>>> >> Consideration for other ciphers has been removed. The requirement is
>>> >> limited to the ciphers of the document. The new text is:
>>> >>
>>> >> As such, all ECDHE_PSK ciphers, including those defined in this
>>> document,
>>> >> SHOULD NOT be
>>> >> negotiated in TLS versions prior to 1.2.
>>> >>>
>>> >>>
>>> >>> -Ek
>>> >>> r
>>> >>>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > TLS mailing list
>>> > TLS@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/tls
>>> >
>>>
>>
>>
>

--f403045e589c5ec17b0550473008
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, 

Thank Joe for the clarifi=
cation. I removed section 4 and instead have the following section 3. This =
is the version 06. 

I will post it as soon as the datatracker allows=
 me to submit a new version, so please let me know if that address all conc=
erns. 

Yours, 
Daniel

3.=
=C2=A0 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites

=C2=A0=C2=A0=
 The cipher suites defined in this document are based on the AES-GCM
=C2=
=A0=C2=A0 and AES-CCM Authenticated Encryption with Associated Data (AEAD)<=
br>=C2=A0=C2=A0 algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_=
128_CCM
=C2=A0=C2=A0 defined in [RFC5116], and AEAD_AES_128_CCM_8 define=
d in [RFC6655].

=C2=A0=C2=A0 Messages and premaster secret construct=
ion in this document are
=C2=A0=C2=A0 defined in [RFC5489].=C2=A0 The Se=
rverKeyExchange and ClientKeyExchange
=C2=A0=C2=A0 messages are used and=
 the premaster secret is computed as for the
=C2=A0=C2=A0 ECDHE_PSK key =
exchange.=C2=A0 The elliptic curve parameters used in in the
=C2=A0=C2=
=A0 Diffie-Hellman parameters are negotiated using extensions defined in=C2=A0=C2=A0 [I-D.ietf-tls-rfc4492bis].

=C2=A0=C2=A0 For TLS 1.2, t=
he following cipher suites are defined:

=C2=A0=C2=A0 TLS_ECDHE_PSK_W=
ITH_AES_128_GCM_SHA256=C2=A0=C2=A0 =3D {0xTBD,0xTBD};
=C2=A0=C2=A0 TLS_E=
CDHE_PSK_WITH_AES_256_GCM_SHA384=C2=A0=C2=A0 =3D {0xTBD,0xTBD};
=C2=A0=
=C2=A0 TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD,0xTBD};
=C2=A0=
=C2=A0 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256=C2=A0=C2=A0 =3D {0xTBD,0xTBD};=


=C2=A0=C2=A0 The assigned code points can only be used for TLS 1.2.=


=C2=A0=C2=A0 The cipher suites defined in this document MUST NOT be=
 negotiated for
=C2=A0=C2=A0 any version of (D)TLS other than TLS 1.2.=
=C2=A0 Servers MUST NOT select
=C2=A0=C2=A0 one of these cipher suites w=
hen selecting TLS version other than TLS
=C2=A0=C2=A0 1.2.=C2=A0 A clien=
t MUST treat the selection of these cipher suites in
=C2=A0=C2=A0 combin=
ation with a different version of TLS as an error and generate
=C2=A0=C2=
=A0 a fatal 'illegal_parameter' TLS alert.

=C2=A0=C2=A0 Ciph=
er suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
=C2=A0=C2=A0 T=
LS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
=C2=A0=C2=
=A0 support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].


On Wed, May 24, 2017 at 11:03 AM, Joseph Salowey <joe@sal=
owey.net> wrote:
Hi Daniel,

Thanks for putting this revision t=
ogether.=C2=A0 The original text in draft 4 went beyond the scope of what s=
hould be in the document (I was too hasty in my review of the document and =
discussion on the list). =C2=A0 Your current proposal is an improvement, bu=
t it still discusses behavior that could either conflict with other documen=
ts or discusses behavior that is not in scope.=C2=A0=C2=A0

My suggestion is to r=
eplace section 4 with the following paragraph (I think this is similar to w=
hat Martin suggests):

"The cipher suites defined in this docume=
nt MUST NOT be negotiated for any version of (D)TLS other than TLS 1.2.=C2=
=A0 Servers MUST NOT select one of these cipher suites when selecting TLS v=
ersion other than TLS 1.2.=C2=A0 A client MUST treat the selection of these=
 cipher suites in combination with a different version of TLS as an error a=
nd generate a fatal 'illegal_parameter' TLS alert."=C2=A0

I think it would also be OK to add the following to p=
oint readers to equivalent ciphers in 1.3.=C2=A0 Here is some suggested tex=
t that could go in the revised section 4:

"Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_=
256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are use=
d to support equivalent functionality in TLS 1.3 [TLS 1.3]."
Thanks,

Joe


On Wed, May 24, 2017 at 7:04 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Martin,=
 

Thank you for your review. Some comment were about text in t=
he applicability section. I think I agree with you that this section detail=
s and clarifies=C2=A0 the following sentence of the previous section:=C2=A0=
 """   The assigned code points can only be used for TLS 1.2=
.""". Most of the text of this section has been added in ord=
er to address comments, thus in order to make this section helpful for many=
 readers, I prefer to keep most of the text you mentioned as not useful. 
Please see inline for more detail responses and let me know if that a=
ddress your comments.

Yours, 
Daniel
On W=
ed, May 24, 2017 at 12:09 AM, Martin Thomson <martin.thomson@gmail=
.com> wrote:
Hi Daniel,



This removes the offending text.



This is incorrect:



> Clients MUST NOT offer one of these cipher suites with a (D)TLS versio=
n that differs from TLS 1.2.



It should be possible to offer these when attempting to negotiate TL=
S

1.3.=C2=A0 The server simply cannot negotiate these cipher suites if it

chooses to use 1.3.=C2=A0 I'd remove that sentence (and the one followi=
ng

it, since it's redundant with the first sentence of the paragraph).


My understanding is that you suggest to remove=
 "Clients MUST NOT offer one ..." for the following reasons:
<=
br>A)
 it is redundant with the first sentence of the paragraph: "The cipher=
=20
suites defined in this document MUST NOT be negotiated ...".=C2=A0 Thi=
s=20
sentence clarifies on the client side what "MUST NOT be negotiated&quo=
t;=20
means, and the same is done for the server side. If we provide=20
clarification for the server side, I would prefer to keep a=20
clarification for the client side as well.=C2=A0 

B)
 It is not true as TLS1.3 enables these cipher suites to be negotiated=20
with TLS1.3. In the text cipher suites stands for the cipher suites code
 points of the IANA registry.=C2=A0 Maybe we can have a better wording.=20
However I believe the next paragraph clarifies that TLS1.3 negotiates=20
these ciphers suites in a different way. Would the following wording addres=
s your comment. If so I will update the section to remove the confusion.
"Clients MUST NOT offer on=
e of the cipher suites code points defined in the document with a (D)TLS ve=
rsion that differs from TLS 1.2."

The text in question=
 is:
"""
=C2=A0=C2=A0 The cipher suites def=
ined in this document MUST NOT be negotiated for
=C2=A0=C2=A0 any versio=
n of (D)TLS other than TLS 1.2.=C2=A0 Clients MUST NOT offer one
=C2=A0=
=C2=A0 of these cipher suites with a (D)TLS version that differs from TLS=C2=A0=C2=A0 1.2.=C2=A0 Servers MUST NOT select one of these cipher suite=
s with a TLS
=C2=A0=C2=A0 version that differs from TLS 1.2.=C2=A0 A cli=
ent MUST treat the selection
=C2=A0=C2=A0 of these cipher suites in comb=
ination with a version of TLS as an
=C2=A0=C2=A0 error and generate a fa=
tal 'illegal_parameter' TLS alert.

"""
=C2=
=A0

As others have noted, the paragraph about TLS 1.3 isn't helpful and

should be removed.



Suggestion to remove TLS1.3 related te=
xt was to clarify that the cipher suites were only defined for TLS1.2. Unle=
ss I missed something we have removed most of the text that could cause con=
fusion. On the other hand, TLS1.3 has been designed, and we also have recei=
ved comments to position the defined cipher suites toward TLS1.3 as we do f=
ro TLS1.0 and TLS1.1. This is the intent of the remaining text mentioning T=
LS1.3. 

In the applicable ver=
sion section, the text for TLS1.3 is intended to clarify why the cipher sui=
tes are restricted to TLS1.2. I believe this is useful for  readers not so =
familiar with TLS1.3 that may not be aware of how TLS1.3=20
negotiate ciphers. My personal opinion is that it might be better to have i=
t explicit rather than implicit, and I would prefer to keep the text below:=


"""
=
=C2=A0=C2=A0 TLS version 1.3 and later negotiate these features in a differ=
ent
=C2=A0=C2=A0 manner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separates authent=
ication and cipher
=C2=A0=C2=A0 suite negotiation [I-D.ietf-tls-tls13] S=
ection 1.2.=C2=A0 TLS 1.3 supports
=C2=A0=C2=A0 PSK with ECDHE key excha=
nge and the cipher suites
=C2=A0=C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_2=
56_GCM_SHA384,
=C2=A0=C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM=
_SHA256 are part of the
=C2=A0=C2=A0 specification.=C2=A0 As a result, T=
LS 1.3 and higher versions, negotiate
=C2=A0=C2=A0 and support these cip=
her suites in a different way.

""" 
=C2=A0
=C2=A0

This:



> In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2 [RF=
C4346] split the pre-master into two=C2=A0 parts.=C2=A0 The PRF results fro=
m mixing the two pseudorandom streams with distinct hash functions (MD5 and=
 SHA-1) by exclusive-ORing them together.



You mean TLS 1.1 rather than 1.2.=C2=A0 But as with the former paragraph,
talking about the limitations of TLS versions that you explicitly

don't support isn't useful.=C2=A0 Remove this paragraph also.



Yes that is TLS1.1. I updated it. I believ=
e the text is useful as it provides a clear justification on why it should =
not be used on TLS version lower than 1.2. More specifically, previous vers=
ion do not support AEAD, but this may not prevent someone using AEAD with t=
hese versions. The reason provided is not AEAD related but PSK related. I b=
elieve it is useful to explicitly justify why the cipher suites defined in =
the document should not be used with previous TLS versions. The text has be=
e suggested by the secdir and I would prefer to keep it, unless there is a =
strong willingness to remove it. =C2=A0 =C2=A0 
=C2=A0 

Nits:

s/pre-master(| secret)/premaster secret/g

Corrected: The text only have premaster secret. =C2=A0 
=C2=A0

You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA25=
6

means to use AEAD_AES_128_GCM (and the same for the other

ciphersuites).=C2=A0 I mention this because the order in which the AEAD

algorithms are mentioned is different to the order of the ciphersuites

in the list.



<=
div>
Unless I miss your comment, I believe the section=
 3 already addresses it. If not please let me knoe what text you would like=
 to see. 
=C2=A0
"""
3.=C2=A0 ECDHE_PSK =
with AES-GCM and AES-CCM Cipher Suites

=C2=A0=C2=A0 The cipher suite=
s defined in this document are based on the AES-GCM
=C2=A0=C2=A0 and AES=
-CCM Authenticated Encryption with Associated Data (AEAD)
=C2=A0=C2=A0 a=
lgorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
=C2=A0=
=C2=A0 defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].
"""=C2=A0 



On 24 May 2017 at 12:37, Daniel Migault <daniel.migault@ericsson.com> wrote=
:

> re-sending with the version 05 but removing the diff to be under the 1=
00 KB

> limit.

> Yours,

> Daniel

>

> On Tue, May 23, 2017 at 9:28 PM, Daniel Migault

> <d=
aniel.migault@ericsson.com> wrote:

>>

>> Hi Eric,

>>

>> Thank you for the feed backs. The version 05 contains all text cha=
nges you

>> agreed. In addition, the text explaining dictionary/brute force ha=
s been

>> removed and replace by a reference to 4279. The recommendation reg=
arding to

>> all PSK ciphers has been limited to the one of the document.=C2=A0=
 Please see

>> inline for more details.

>>

>> For some reasons I am not able to validate the submission of versi=
on 05. I

>> have attached the diff with version 04 as well as the locally gene=
rated

>> version 05.

>>

>> Yours,

>> Daniel

>>

>> On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>>

>>>

>>>

>>> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault

>>> <daniel.migault@ericsson.com> wrote:

>>>>

>>>> Hi Eric,

>>>>

>>>> Thank you for your reviews. Please see my responses inline=
. If you agree

>>>> with the text I will update the draft.

>>>>

>>>> Yours,

>>>> Daniel

>>>>

>>>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>>>>>

>>>>> Eric Rescorla has entered the following ballot positio=
n for

>>>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss

>>>>>

>>>>> When responding, please keep the subject line intact a=
nd reply to all

>>>>> email addresses included in the To and CC lines. (Feel=
 free to cut this

>>>>> introductory paragraph, however.)

>>>>>

>>>>>

>>>>> Please refer to

>>>>> https://www.ietf.org/i=
esg/statement/discuss-criteria.html

>>>>> for more information about IESG DISCUSS and COMMENT po=
sitions.

>>>>>

>>>>>

>>>>> The document, along with other ballot positions, can b=
e found here:

>>>>> https://datatrac=
ker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

>>>>>

>>>>>

>>>>>

>>>>> -------------------------------------------------=
---------------------

>>>>> DISCUSS:

>>>>> -------------------------------------------------=
---------------------

>>>>>

>>>>> The following text appears to have been added in -04
>>>>>

>>>>>=C2=A0 =C2=A0 A server receiving a ClientHello and a cl=
ient_version indicating

>>>>>=C2=A0 =C2=A0 (3,1) "TLS 1.0" or (3,2) "=
TLS 1.1" and any of the cipher suites from

>>>>>=C2=A0 =C2=A0 this document in ClientHello.cipher_suite=
s can safely assume that

>>>>> the

>>>>>=C2=A0 =C2=A0 client supports TLS 1.2 and is willing to=
 use it.=C2=A0 The server MUST

>>>>>=C2=A0 =C2=A0 NOT negotiate these cipher suites with TL=
S protocol versions earlier

>>>>>=C2=A0 =C2=A0 than TLS 1.2.=C2=A0 Not requiring clients=
 to indicate their support for

>>>>>=C2=A0 =C2=A0 TLS 1.2 cipher suites exclusively through=
 ClientHello.client_hello

>>>>>=C2=A0 =C2=A0 improves the interoperability in the inst=
alled base and use of TLS

>>>>>=C2=A0 =C2=A0 1.2 AEAD cipher suites without upsetting =
the installed base of

>>>>>=C2=A0 =C2=A0 version-intolerant TLS servers, results i=
n more TLS handshakes

>>>>>=C2=A0 =C2=A0 succeeding and obviates fallback mechanis=
ms.

>>>>>

>>>>> This is a major technical change from -03, which, AFAI=
K, prohibited

>>>>> the server from negotiating these algorithms with TLS =
1.1 and below

>>>>> and maintained the usual TLS version 1.2 negotiation r=
ules.

>>>>>

>>>>> This is a very material technical change. I don't =
consider it wise,

>>>>> but in any case it would absolutely need WG consensus,=
 which I

>>>>> don't believe that it has given the recent introdu=
ction.

>>>>

>>>>

>>>> I agree that the text is a technical change, and that it m=
ay not be

>>>> appropriated to do so now. The reason I included it was th=
at it was conform

>>>> to the previous text, but I agree that implicit assumption=
 of version 1.2

>>>> may need some additional discussion especially regarding R=
FC5246 Appendix E.

>>>> Unless you prefer further discussion I assume the text bel=
ow address your

>>>> concern.

>>>>

>>>> <t>The cipher suites defined in this document MUST N=
OT be negotiated for

>>>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT=
 offer one of

>>>> these cipher suites with a (D)TLS version that differs fro=
m TLS 1.2. Servers

>>>> MUST NOT select one of these cipher suites with a TLS vers=
ion that differs

>>>> from TLS 1.2. A client MUST treat the selection of these c=
ipher suites in

>>>> combination with a version of TLS as an error and generate=
 a fatal

>>>> 'illegal_parameter' TLS alert. </t>

>>>

>>>

>>> Yes, this seems fine

>>>

>>>

>>>>> The discussion of dictionary attacks here seems inferi=
or to that

>>>>> in 4279. In particular, you only need to actively atta=
ck one

>>>>> connection to capture the data you need for a brute fo=
rce attack

>>>>> despite the text there referring to trying "diffe=
rent keys".

>>>>> Please correct that.

>>>>>

>>>> I believe the text below address your concern:

>>>>

>>>> OLD:

>>>> <t>Use of Pre-Shared Keys of limited entropy may all=
ow an active

>>>> attacker attempts to connect to the server and try differe=
nt keys.

>>>> For example, limited entropy may be provided by using a sh=
ort PSK in

>>>> which

>>>> case an attacker may perform a brute-force attack. Another=
 example

>>>> includes the use of a PSK=C2=A0 chosen by a human which th=
us may be exposed

>>>> to

>>>> dictionary attacks.</t>

>>>>

>>>> NEW:

>>>> <t>Pre-Shared Keys security relies on its associated=
 entropy, and it is

>>>> RECOMMENDED to follow <xref target=3D"4086"/&=
gt; to ensure the PSK has enough

>>>> entropy. Possible reasons for low entropy includes PSK cho=
sen by humans or

>>>> PSK of small length as well as using random generators wit=
h limited entropy.

>>>> </t>

>>>>

>>>> <t>PSK of limited entropy may allow an attacker to t=
est different PSK

>>>> values against a valid output such as master secret or any=
 output derived

>>>> from it. In this document, the master secret is generated =
using the PSK as

>>>> well as the ECDHE shared secret. The use of ECDHE limits t=
he possibilities

>>>> of passive eavesdropping attackers, as the ECDHE shared se=
cret is not

>>>> expected to be derived from the observed ECDH parameters. =
As a result,

>>>> passive eavesdropping is unlikely to happen, and the colle=
ction of all

>>>> necessary material relies on an active attack.

>>>> An active attacker may collect the necessary material by s=
etting a TLS

>>>> session as a client with the legitimate server. One PSK is=
 tested for each

>>>> session, and a match occurs when key exchange succeeds. On=
 the other hand,

>>>> an active attacker may also consider gathering the necessa=
ry information for

>>>> offline computation. One way consists in getting a legitim=
ate client to

>>>> establish a connection with the attacker. It is also assum=
ed that the client

>>>> will accept the ECDH parameters authenticated by the attac=
ker's private key

>>>> and finally returns the Finished message authenticating th=
e exchange. The

>>>> attacker will be then in possession of all the necessary i=
nformation to

>>>> perform a brute force attack.</t>

>>>

>>>

>>> Is there a reason to not just point directly to the 4279 secur=
ity

>>> considerations?

>>

>>

>> No, basically I tried to complete the previous text that missed th=
e

>> offline use case. The current version just point to 4279, without =
having the

>> above text. If you think the text above is clarifying I can add it=
 as well.

>>>

>>> -

>>>>

>>>>

>>>>>

>>>>>

>>>>> -------------------------------------------------=
---------------------

>>>>> COMMENT:

>>>>> -------------------------------------------------=
---------------------

>>>>>

>>>>> The citations to TLS 1.3 still seem pretty muddled. I =
think you

>>>>> should just stop referencing and discussing 1.3.

>>>>

>>>>

>>>> My understanding of your comment is that mentioning TLS 1.=
3 to further

>>>> insisting that the code point are not valid for TLS 1.3 is=
 confusing. I

>>>> propose to:

>>>>

>>>> Explicitly mention the TLS version in the title:

>>>>

>>>> OLD title:

>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Trans=
port Layer

>>>> Security (TLS)

>>>>

>>>> NEW title:

>>>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Trans=
port Layer

>>>> Security (TLS)

>>>>

>>>> OLD Introduction:

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0The cipher

>>>>=C2=A0 =C2=A0 suites are defined for version 1.2 of the Tra=
nsport Layer Security

>>>>=C2=A0 =C2=A0 (TLS) [RFC5246] protocol, version 1.2 of the =
Datagram Transport Layer

>>>>=C2=A0 =C2=A0 Security (DTLS) protocol [RFC6347], as well a=
s version 1.3 of TLS

>>>>=C2=A0 =C2=A0 [I-D.ietf-tls-tls13].

>>>>

>>>> NEW introduction

>>>>

>>>> The cipher

>>>>=C2=A0 =C2=A0 suites are defined for version 1.2 of the Tra=
nsport Layer Security

>>>>=C2=A0 =C2=A0 (TLS) [RFC5246] protocol, version 1.2 of the =
Datagram Transport Layer

>>>>=C2=A0 =C2=A0 Security (DTLS) protocol [RFC6347].

>>>>

>>>>

>>>> I suggest to keep the following text of the introduction:<=
br>
>>>>

>>>>

>>>> AEAD algorithms that combine encryption and integrity prot=
ection are

>>>>=C2=A0 =C2=A0 strongly recommended for (D)TLS [RFC7525] and=
 non-AEAD algorithms are

>>>>=C2=A0 =C2=A0 forbidden to use in TLS 1.3 [I-D.ietf-tls-tls=
13].=C2=A0 The AEAD

>>>>=C2=A0 =C2=A0 algorithms considered in this document are AE=
S-GCM and AES-CCM.=C2=A0 The

>>>>=C2=A0 =C2=A0 use of AES-GCM in TLS is defined in [RFC5288]=
 and the use of AES-CCM

>>>>=C2=A0 =C2=A0 is defined in [RFC6655].

>>>

>>>

>>> Yes, this seems fine.

>>>

>>>

>>>>

>>>> I suggest to keep the following text of the Applicable ver=
sions

>>>> sections, as I believe the section discusses the cipher su=
ites against all

>>>> existing TLS versions. In addition, it also justifies some=
what that we only

>>>> defined cipher suites that are compatible with TLS1.3.

>>>>

>>>>=C2=A0 =C2=A0 TLS version 1.3 and later negotiate these fea=
tures in a different

>>>>=C2=A0 =C2=A0 manner.=C2=A0 Unlike TLS 1.2, TLS 1.3 separat=
es authentication and cipher

>>>>=C2=A0 =C2=A0 suite negotiation [I-D.ietf-tls-tls13] Sectio=
n 1.2.=C2=A0 TLS 1.3 supports

>>>>=C2=A0 =C2=A0 PSK with ECDHE key exchange and the cipher su=
ites

>>>>=C2=A0 =C2=A0 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA38=
4,

>>>>=C2=A0 =C2=A0 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_=
SHA256 are part of the

>>>>=C2=A0 =C2=A0 specification.=C2=A0 As a result, TLS 1.3 and=
 higher versions, negotiate

>>>>=C2=A0 =C2=A0 and support these cipher suites in a differen=
t way.

>>>

>>>

>>> OK.

>>>

>>>>

>>>> I suggest to remove the reference to TLS1.3 in the securit=
y

>>>> considerations

>>>>

>>>> OLD

>>>>

>>>>=C2=A0 The security considerations in TLS 1.2 [RFC5246], DT=
LS 1.2 [RFC6347],

>>>>=C2=A0 =C2=A0 TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5=
489], AES-GCM [RFC5288],

>>>>=C2=A0 =C2=A0 and AES-CCM [RFC6655] apply to this document =
as well.

>>>>

>>>> NEW

>>>>

>>>>=C2=A0 The security considerations in TLS 1.2 [RFC5246], DT=
LS 1.2 [RFC6347],

>>>>=C2=A0 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],and AES-CCM [=
RFC6655] apply

>>>>=C2=A0 to this document as well.

>>>>>

>>>>>

>>>>> S 2.

>>>>> I'm not sure that the discussion of the PRF is hel=
pful here in

>>>>> mandating the non-use of these cipher suites with TLS =
1.1 and

>>>>> below.

>>>>

>>>>

>>>> I find the text useful as it gives an idea why even introd=
ucing AEAD in

>>>> TLS version lower than 1.2 is a bad idea, so I would prefe=
r to keep it. The

>>>> text has been changed to

>>>>

>>>> OLD:

>>>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_=
PSK.

>>>>

>>>> NEW:

>>>> As such,=C2=A0 all ECDHE_PSK

>>>> ciphers, including those defined outside this document, SH=
OULD NOT be

>>>> negotiated in TLS versions prior to 1.2.

>>>

>>>

>>> I don't think you should be levying a new normative requir=
ement like this

>>> for other ciphers

>>> i this document

>>

>>

>> Consideration for other ciphers has been removed. The requirement =
is

>> limited to the ciphers of the document. The new text is:

>>

>> As such, all ECDHE_PSK ciphers, including those defined in this do=
cument,

>> SHOULD NOT be

>> negotiated in TLS versions prior to 1.2.

>>>

>>>

>>> -Ek

>>> r

>>>

>>

>

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls

>









--f403045e589c5ec17b0550473008--


From nobody Wed May 24 10:04:46 2017
Return-Path: 
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 67414126BFD for ; Wed, 24 May 2017 10:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 2QcXre9ejiUz for ; Wed, 24 May 2017 10:04:43 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C651200CF for ; Wed, 24 May 2017 10:04:43 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4OGksOX010521; Wed, 24 May 2017 18:04:41 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=jOKrhVRP1ex2khmXlhpSqpFjjbtI70/uoJREc6V5DoM=; b=FYMRcFeccJAJGCi6xseybe7nvNg1zbiXuT2nkXJ+EZAB2GCzq1zpcXpc33R6B4Hue3VM k4o5AVB3prHhmbqBsQXfl+1Q7zxtvvTk453Prf0T1bkZmpb9fj+QWP/hsT/i6jzb83KA TMnpiDWt97yLh9B3+6OZOxFMmrVnfGSiVSTiwj9UbeieDWzzxYl6MEy4jOUwCSmDczIv wYeUM2UuwTkOMnnoNShqnWSx8d9sTtJTk7GRHoUB7BmTWBPZARitovISLXn7mobYSWx4 4jQZh5LL5sRH2dEdw+MzPTl1GrfWM75nTB5E3wT0R5f+q8ZVa78Mr8guj8hThA6Pk2tk qg== 
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2anbc892a4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 May 2017 18:04:40 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4OGkEOo016522; Wed, 24 May 2017 13:04:39 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ajh4vgpw0-1; Wed, 24 May 2017 13:04:39 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 2B0DA80052; Wed, 24 May 2017 11:04:39 -0600 (MDT)
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Ilari Liusvaara 
Cc: "tls@ietf.org" 
References:      <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi>  <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi>  <071fb4df-56e6-d82a-87de-3db084235021@akamai.com> <20170524143042.GA31858@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Benjamin Kaduk 
Message-ID: 
Date: Wed, 24 May 2017 12:04:38 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------853C99B0D8B95E6ECB8DD4F7"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-24_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705240081
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-24_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705240081
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 17:04:44 -0000

This is a multi-part message in MIME format.
--------------853C99B0D8B95E6ECB8DD4F7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 05/24/2017 10:32 AM, Colm MacCárthaigh wrote:
>
>     > Another crazy idea would be to just say that servers MUST limit
>     the use
>     > of a single binder to at most 100 times, with the usual case
>     being just
>     > once, to allow for alternative designs that have weaker distributed
>     > consensus requirements (but still describe these current two
>     methods as
>     > examples of ways to do so).
>
>     You actually need strong distributed consensus about all accepted
>     0-RTT here.
>
>
> This pattern doesn't need strong consensus. If you have 10 servers,
> you could give each 10 goes at the ticket, and let each exhaust its 10
> attempts without any coordination or consensus. You likely won't get
> to "exactly 100", but you will get to "at most 100 times". 
>

Or (up to) 100 servers and give each server just one crack at the
ticket, which is perhaps more plausible to implement sanely.

> But the inner critical section would be inherently more complicated. 
> For the at most once case we need to a critical section that performs
> an exclusive-read-and-delete atomically. It's a mutex lock or a clever
> construction of atomic instructions.  For "at most N" we now need to
> perform a decrement and write in the critical section, and it becomes
> more like a semaphore. 
>
> It's probably not a pattern that's worth the trade-offs. 
>

That particular decrement-based design is not worth the trade-off,
definitely, but I doubt it's the only scheme that could meet the stated
requirement.  Something that attempts to access a global single-use data
structure but has some failure tolerance for that operation, and some
plausible story for bounding how often that can happen, say (like
stopping accepting 0-RTT at all on that server for 10 seconds once a
threshold level of errors occurs).

But, as indicated by the "crazy idea" prefix, I am not actually pushing
for this scheme.

-Ben

--------------853C99B0D8B95E6ECB8DD4F7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 05/24/2017 10:32 AM, Colm MacCárthaigh wrote:

    

      

        

            > Another crazy idea would be to just say that servers
            MUST limit the use

            > of a single binder to at most 100 times, with the usual
            case being just

            > once, to allow for alternative designs that have weaker
            distributed

            > consensus requirements (but still describe these
            current two methods as

            > examples of ways to do so).

            

          You actually need strong distributed consensus about
          all accepted

          0-RTT here.

        

        


        

        
This pattern doesn't need strong consensus. If you have 10
          servers, you could give each 10 goes at the ticket, and let
          each exhaust its 10 attempts without any coordination or
          consensus. You likely won't get to "exactly 100", but you will
          get to "at most 100 times". 

        


        

      

    

    

    Or (up to) 100 servers and give each server just one crack at the
    ticket, which is perhaps more plausible to implement sanely.

    

    

      

        
But the inner critical section would be inherently more
          complicated.  For the at most once case we need to a critical
          section that performs an exclusive-read-and-delete atomically.
          It's a mutex lock or a clever construction of atomic
          instructions.  For "at most N" we now need to perform a
          decrement and write in the critical section, and it becomes
          more like a semaphore. 

        


        

        
It's probably not a pattern that's worth the trade-offs. 

      

      


      

    

    

    That particular decrement-based design is not worth the trade-off,
    definitely, but I doubt it's the only scheme that could meet the
    stated requirement.  Something that attempts to access a global
    single-use data structure but has some failure tolerance for that
    operation, and some plausible story for bounding how often that can
    happen, say (like stopping accepting 0-RTT at all on that server for
    10 seconds once a threshold level of errors occurs).

    

    But, as indicated by the "crazy idea" prefix, I am not actually
    pushing for this scheme.

    

    -Ben

  


--------------853C99B0D8B95E6ECB8DD4F7--


From nobody Wed May 24 10:24:36 2017
Return-Path: 
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 A52BD1286AB; Tue, 23 May 2017 19:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Level: 
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d5UDz4APBIz7; Tue, 23 May 2017 19:28:23 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9442129421; Tue, 23 May 2017 19:28:19 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id m18so59604008lfj.0; Tue, 23 May 2017 19:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=55oL7xsTTNiQyWrvt4+Uw/+XV0yUi1hgzFP+qhC0ElE=; b=VboTdfb4p47I9xMdfjstTNT651VVTaOuag+UhAj5766Z4HpR2jo/OiAsl7mBz3sLbk 2vTZc/srODePnTz5PzkpWtkCk4pxLUYaCkmuUfntKJRk4SGEOLCbxqg8rfKa9S9ioDnI Y3qpoGAD6jAhOvIDwYuWFfTn5eJ1DY6OBSkXw2QRjY/KHTvkWcpo6S1SHRR0fWw9tv21 Smqsvd4El/bH7btfVtfgz9T0bhhJMNfvvwCAE01I6Wygixy8lJrSIcEoPvbj5D6LlSK0 3MDydfV68d7Jz/3Mhu22qaoheaxfe7xMVeNRx+pk7iI7lIhhY5Vr+bO9Yw9A4Up+Xplh dyOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=55oL7xsTTNiQyWrvt4+Uw/+XV0yUi1hgzFP+qhC0ElE=; b=Zovh44g4vBCyh8qbk1TRwmzAj46b1dD9KkfEzzK71mCRwCybLJXABWdu+B7AxbsbzX H77Li5Z/BRmEpCOsQ/HZ2PQQbztVqCRHEB2KXpV3z/CC6JzL/+B1HBf2YGR0OOLnjdzB ZfREEBRFYhn+l1vUsOE2nsagVoexzDRvu7euF1rUI7gGbtJ8DDAvH8NWf7kWniAQjHeS mDDmZ1MDj5FPtBmQRW7yVFWoyamEbGr3hw7v+TrcSV1ZXOKSs4Q/d0Wpebo78zzTpe7c 7Ri0rCiwRNaSpnABHj8zFumTbDnsggTnVfB183lkTW/eT3QV1wG3FEE+AE7F8HBN09tL Mjyg==
X-Gm-Message-State: AODbwcCFaygumDnJY+ZV6CumtLPLJ8q2JtiHMfQuRwcxPTWj8hiaT9Nh iNhP+pThPP7ySdHtVfnkickZvJa7eQ==
X-Received: by 10.25.208.14 with SMTP id h14mr7217363lfg.174.1495592897992; Tue, 23 May 2017 19:28:17 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Tue, 23 May 2017 19:28:16 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>  
From: Daniel Migault 
Date: Tue, 23 May 2017 21:28:16 -0500
X-Google-Sender-Auth: Dcp-CV-SR387m-2xLtb7OEexjes
Message-ID: 
To: Eric Rescorla 
Cc: The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org,  Joseph Salowey , tls-chairs , tls 
Content-Type: multipart/mixed; boundary="001a11412d3c6a2d4705503bdba6"
Archived-At: 
X-Mailman-Approved-At: Wed, 24 May 2017 10:24:35 -0700
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 02:28:28 -0000

--001a11412d3c6a2d4705503bdba6
Content-Type: multipart/alternative; boundary="001a11412d3c6a2d4205503bdba4"

--001a11412d3c6a2d4205503bdba4
Content-Type: text/plain; charset="UTF-8"

Hi Eric,

Thank you for the feed backs. The version 05 contains all text changes you
agreed. In addition, the text explaining dictionary/brute force has been
removed and replace by a reference to 4279. The recommendation regarding to
all PSK ciphers has been limited to the one of the document.  Please see
inline for more details.

For some reasons I am not able to validate the submission of version 05. I
have attached the diff with version 04 as well as the locally generated
version 05.

Yours,
Daniel

On Tue, May 23, 2017 at 7:40 PM, Eric Rescorla  wrote:

>
>
> On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
>> Hi Eric,
>>
>> Thank you for your reviews. Please see my responses inline. If you agree
>> with the text I will update the draft.
>>
>> Yours,
>> Daniel
>>
>> On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla  wrote:
>>
>>> Eric Rescorla has entered the following ballot position for
>>> draft-ietf-tls-ecdhe-psk-aead-04: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/stat
>>> ement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> The following text appears to have been added in -04
>>>
>>>    A server receiving a ClientHello and a client_version indicating
>>>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>>>    this document in ClientHello.cipher_suites can safely assume that
>>> the
>>>    client supports TLS 1.2 and is willing to use it.  The server MUST
>>>    NOT negotiate these cipher suites with TLS protocol versions earlier
>>>    than TLS 1.2.  Not requiring clients to indicate their support for
>>>    TLS 1.2 cipher suites exclusively through ClientHello.client_hello
>>>    improves the interoperability in the installed base and use of TLS
>>>    1.2 AEAD cipher suites without upsetting the installed base of
>>>    version-intolerant TLS servers, results in more TLS handshakes
>>>    succeeding and obviates fallback mechanisms.
>>>
>>> This is a major technical change from -03, which, AFAIK, prohibited
>>> the server from negotiating these algorithms with TLS 1.1 and below
>>> and maintained the usual TLS version 1.2 negotiation rules.
>>>
>>> This is a very material technical change. I don't consider it wise,
>>> but in any case it would absolutely need WG consensus, which I
>>> don't believe that it has given the recent introduction.
>>>
>>
>> I agree that the text is a technical change, and that it may not be
>> appropriated to do so now. The reason I included it was that it was conform
>> to the previous text, but I agree that implicit assumption of version 1.2
>> may need some additional discussion especially regarding RFC5246 Appendix
>> E. Unless you prefer further discussion I assume the text below address
>> your concern.
>>
>> The cipher suites defined in this document MUST NOT be negotiated for
>> any version of (D)TLS other than TLS 1.2. Clients MUST NOT offer one of
>> these cipher suites with a (D)TLS version that differs from TLS 1.2.
>> Servers MUST NOT select one of these cipher suites with a TLS version that
>> differs from TLS 1.2. A client MUST treat the selection of these cipher
>> suites in combination with a version of TLS as an error and generate a
>> fatal 'illegal_parameter' TLS alert. 
>>
>
> Yes, this seems fine
>
>
> The discussion of dictionary attacks here seems inferior to that
>>> in 4279. In particular, you only need to actively attack one
>>> connection to capture the data you need for a brute force attack
>>> despite the text there referring to trying "different keys".
>>> Please correct that.
>>>
>>> I believe the text below address your concern:
>>
>> OLD:
>> Use of Pre-Shared Keys of limited entropy may allow an active
>> attacker attempts to connect to the server and try different keys.
>> For example, limited entropy may be provided by using a short PSK in which
>> case an attacker may perform a brute-force attack. Another example
>> includes the use of a PSK  chosen by a human which thus may be exposed to
>> dictionary attacks.
>>
>> NEW:
>> Pre-Shared Keys security relies on its associated entropy, and it is
>> RECOMMENDED to follow  to ensure the PSK has enough
>> entropy. Possible reasons for low entropy includes PSK chosen by humans or
>> PSK of small length as well as using random generators with limited
>> entropy. 
>>
>> PSK of limited entropy may allow an attacker to test different PSK
>> values against a valid output such as master secret or any output derived
>> from it. In this document, the master secret is generated using the PSK as
>> well as the ECDHE shared secret. The use of ECDHE limits the possibilities
>> of passive eavesdropping attackers, as the ECDHE shared secret is not
>> expected to be derived from the observed ECDH parameters. As a result,
>> passive eavesdropping is unlikely to happen, and the collection of all
>> necessary material relies on an active attack.
>> An active attacker may collect the necessary material by setting a TLS
>> session as a client with the legitimate server. One PSK is tested for each
>> session, and a match occurs when key exchange succeeds. On the other hand,
>> an active attacker may also consider gathering the necessary information
>> for offline computation. One way consists in getting a legitimate client to
>> establish a connection with the attacker. It is also assumed that the
>> client will accept the ECDH parameters authenticated by the attacker's
>> private key and finally returns the Finished message authenticating the
>> exchange. The attacker will be then in possession of all the necessary
>> information to perform a brute force attack.
>>
>
> Is there a reason to not just point directly to the 4279 security
> considerations?
>

No, basically I tried to complete the previous text that missed the offline
use case. The current version just point to 4279, without having the above
text. If you think the text above is clarifying I can add it as well.

> -
>
>>
>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> The citations to TLS 1.3 still seem pretty muddled. I think you
>>> should just stop referencing and discussing 1.3.
>>>
>>
>> My understanding of your comment is that mentioning TLS 1.3 to further
>> insisting that the code point are not valid for TLS 1.3 is confusing. I
>> propose to:
>>
>> Explicitly mention the TLS version in the title:
>>
>> OLD title:
>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>> Security (TLS)
>>
>> NEW title:
>> ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
>> Security (TLS)
>>
>> OLD Introduction:
>>
>>     The cipher
>>    suites are defined for version 1.2 of the Transport Layer Security
>>    (TLS) [RFC5246 ] protocol, version 1.2 of the Datagram Transport Layer
>>    Security (DTLS) protocol [RFC6347 ], as well as version 1.3 of TLS
>>    [I-D.ietf-tls-tls13 ].
>>
>> NEW introduction
>>
>> The cipher
>>    suites are defined for version 1.2 of the Transport Layer Security
>>    (TLS) [RFC5246 ] protocol, version 1.2 of the Datagram Transport Layer
>>    Security (DTLS) protocol [RFC6347 ].
>>
>>
>> I suggest to keep the following text of the introduction:
>>
>>
>> AEAD algorithms that combine encryption and integrity protection are
>>    strongly recommended for (D)TLS [RFC7525 ] and non-AEAD algorithms are
>>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13 ].  The AEAD
>>    algorithms considered in this document are AES-GCM and AES-CCM.  The
>>    use of AES-GCM in TLS is defined in [RFC5288 ] and the use of AES-CCM
>>    is defined in [RFC6655 ].
>>
>>
> Yes, this seems fine.
>
>
>
>> I suggest to keep the following text of the Applicable versions sections,
>> as I believe the section discusses the cipher suites against all existing
>> TLS versions. In addition, it also justifies somewhat that we only defined
>> cipher suites that are compatible with TLS1.3.
>>
>>    TLS version 1.3 and later negotiate these features in a different
>>    manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
>>    suite negotiation [I-D.ietf-tls-tls13 ] Section 1.2 .  TLS 1.3 supports
>>    PSK with ECDHE key exchange and the cipher suites
>>    TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
>>    specification.  As a result, TLS 1.3 and higher versions, negotiate
>>    and support these cipher suites in a different way.
>>
>>
> OK.
>
>
>> I suggest to remove the reference to TLS1.3 in the security considerations
>>
>> OLD
>>
>>  The security considerations in TLS 1.2 [RFC5246 ], DTLS 1.2 [RFC6347 ],
>>    TLS 1.3 [I-D.ietf-tls-tls13 ], ECDHE_PSK [RFC5489 ], AES-GCM [RFC5288 ],
>>    and AES-CCM [RFC6655 ] apply to this document as well.
>>
>> NEW
>>
>>  The security considerations in TLS 1.2 [RFC5246 ], DTLS 1.2 [RFC6347 ],
>>  ECDHE_PSK [RFC5489 ], AES-GCM [RFC5288 ],and AES-CCM [RFC6655 ] apply
>>  to this document as well.
>>
>>
>>> S 2.
>>> I'm not sure that the discussion of the PRF is helpful here in
>>> mandating the non-use of these cipher suites with TLS 1.1 and
>>> below.
>>>
>>
>> I find the text useful as it gives an idea why even introducing AEAD in
>> TLS version lower than 1.2 is a bad idea, so I would prefer to keep it. The
>> text has been changed to
>>
>> OLD:
>> As such TLS 1.0 and TLS 1.1 should not be used with ECDHE_PSK.
>>
>> NEW:
>> As such,  all ECDHE_PSK
>> ciphers, including those defined outside this document, SHOULD NOT be
>> negotiated in TLS versions prior to 1.2.
>>
>
> I don't think you should be levying a new normative requirement like this
> for other ciphers
> i this document
>

Consideration for other ciphers has been removed. The requirement is
limited to the ciphers of the document. The new text is:

As such, all ECDHE_PSK ciphers, including those defined in this document,
SHOULD NOT be
negotiated in TLS versions prior to 1.2.

>
> -Ek
> r
>
>

--001a11412d3c6a2d4205503bdba4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eric, 

Thank you for the feed ba=
cks. The version 05 contains all text changes you agreed. In addition, the =
text explaining dictionary/brute force has been removed and replace by a re=
ference to 4279. The recommendation regarding to all PSK ciphers has been l=
imited to the one of the document.=C2=A0 Please see=C2=A0 inline for more d=
etails.

<=
div>For some reasons I am not=
 able to validate the submission of version 05. I have attached the diff wi=
th version 04 as well as the locally generated version 05. 

<=
/div>Yours, 
Daniel

On Tue, May 2=
3, 2017 at 7:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, May 24, 2017 at 6:00 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Eric=
, 

Thank you for your reviews. Please see my responses inline.=
 If you agree with the text I will update the draft.

Yours, 
Daniel

On Mon, May 22, 2017 at 10:11 PM, Eri=
c Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the following ballot positio=
n for

draft-ietf-tls-ecdhe-psk-aead-04: Discuss



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/s=
tatement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc=
/draft-ietf-tls-ecdhe-psk-aead/







-----------------------------------------------------------------=
-----

DISCUSS:

-----------------------------------------------------------------=
-----



The following text appears to have been added in -04



=C2=A0 =C2=A0A server receiving a ClientHello and a client_version indicati=
ng

=C2=A0 =C2=A0(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any=
 of the cipher suites from

=C2=A0 =C2=A0this document in ClientHello.cipher_suites can safely assume t=
hat

the

=C2=A0 =C2=A0client supports TLS 1.2 and is willing to use it.=C2=A0 The se=
rver MUST

=C2=A0 =C2=A0NOT negotiate these cipher suites with TLS protocol versions e=
arlier

=C2=A0 =C2=A0than TLS 1.2.=C2=A0 Not requiring clients to indicate their su=
pport for

=C2=A0 =C2=A0TLS 1.2 cipher suites exclusively through ClientHello.client_h=
ello

=C2=A0 =C2=A0improves the interoperability in the installed base and use of=
 TLS

=C2=A0 =C2=A01.2 AEAD cipher suites without upsetting the installed base of=


=C2=A0 =C2=A0version-intolerant TLS servers, results in more TLS handshakes=


=C2=A0 =C2=A0succeeding and obviates fallback mechanisms.



This is a major technical change from -03, which, AFAIK, prohibited

the server from negotiating these algorithms with TLS 1.1 and below

and maintained the usual TLS version 1.2 negotiation rules.



This is a very material technical change. I don't consider it wise,

but in any case it would absolutely need WG consensus, which I

don't believe that it has given the recent introduction.

I agree that the text is a technical chan=
ge, and that it may not be appropriated to do so now. The reason I included=
 it was that it was conform to the previous text, but I agree that implicit=
 assumption of version 1.2 may need some additional discussion especially r=
egarding RFC5246 Appendix E. Unless you prefer further discussion I assume =
the text below address your concern. =C2=A0 

<t>The cipher sui=
tes defined in this document MUST NOT be negotiated for any version of (D)T=
LS other than TLS 1.2. Clients MUST NOT offer one of these cipher suites wi=
th a (D)TLS version that differs from TLS 1.2. Servers MUST NOT select one =
of these cipher suites with a TLS version that differs from TLS 1.2. A clie=
nt MUST treat the selection of these cipher suites in combination with a ve=
rsion of TLS as an error and generate a fatal 'illegal_parameter' T=
LS alert. </t> 

Yes, this seems fine


=


The discussion of dictionary attacks here seems inferior to that

in 4279. In particular, you only need to actively attack one

connection to capture the data you need for a brute force attack

despite the text there referring to trying "different keys".

Please correct that.


I believe the text below address your concern:=


OLD:
<t>Use of Pre-Shared Keys of limited entropy may allo=
w an active
attacker attempts to connect to the server and try different=
 keys.
For example, limited entropy may be provided by using a short PSK=
 in which
case an attacker may perform a brute-force attack. Another exa=
mple
includes the use of a PSK=C2=A0 chosen by a human which thus may be=
 exposed to
dictionary attacks.</t>

NEW:
<t>Pre-Sh=
ared Keys security relies on its associated entropy, and it is RECOMMENDED =
to follow <xref target=3D"4086"/> to ensure the PSK has eno=
ugh entropy. Possible reasons for low entropy includes PSK chosen by humans=
 or PSK of small length as well as using random generators with limited ent=
ropy. </t>

<t>PSK of limited entropy may allow an attack=
er to test different PSK values against a valid output such as master secre=
t or any output derived from it. In this document, the master secret is gen=
erated using the PSK as well as the ECDHE shared secret. The use of ECDHE l=
imits the possibilities of passive eavesdropping attackers, as the ECDHE sh=
ared secret is not expected to be derived from the observed ECDH parameters=
. As a result, passive eavesdropping is unlikely to happen, and the collect=
ion of all necessary material relies on an active attack. 
An active att=
acker may collect the necessary material by setting a TLS session as a clie=
nt with the legitimate server. One PSK is tested for each session, and a ma=
tch occurs when key exchange succeeds. On the other hand, an active attacke=
r may also consider gathering the necessary information for offline computa=
tion. One way consists in getting a legitimate client to establish a connec=
tion with the attacker. It is also assumed that the client will accept the =
ECDH parameters authenticated by the attacker's private key and finally=
 returns the Finished message authenticating the exchange. The attacker wil=
l be then in possession of all the necessary information to perform a brute=
 force attack.</t>=C2=A0=C2=A0 

Is there a reason to =
not just point directly to the 4279 security considerations?

No, basically I tried to complete=
 the previous text that missed the offline use case. The current version ju=
st point to 4279, without having the above text. If you think the text abov=
e is clarifying I can add it as well.=C2=A0 =C2=A0 =C2=A0 
-
=C2=A0 



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



The citations to TLS 1.3 still seem pretty muddled. I think you

should just stop referencing and discussing 1.3.

<=
/div>
My understanding of your comment is that mentioning TLS 1.=
3 to further insisting that the code point are not valid for TLS 1.3 is con=
fusing. I propose to:

Explicitly mention the TLS version =
in the title:

OLD title:
ECDHE_PSK with AES-GCM and AE=
S-CCM Cipher Suites for Transport Layer Security (TLS)

NE=
W title:
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport =
Layer Security (TLS)
OLD Introduction:
    The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13].
NE=
W introduction

The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347]. 


I suggest to keep the following text=
 of the introduction:

AEAD algorithms that combine encryptio=
n and integrity protection are
   strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.=
ietf-tls-tls13].  The AEAD
   algorithms considered in this document are AES-GCM and AES-CCM.  The
   use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
   is defined in [RFC6655].
<=
/div>

Yes, this seems fine.

=C2=A0
I suggest to keep the=
 following text of the Applicable versions sections, as I believe the secti=
on discusses the cipher suites against all existing TLS versions. In additi=
on, it also justifies somewhat that we only defined cipher suites that are =
compatible with TLS1.3.=C2=A0 
   TLS version 1.3 and later negotiate these featu=
res in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-t=
ls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

OK.
=C2=A0
I suggest to remove the reference to TLS1.3 in the se=
curity considerations

OLD
 The security considerations in TLS 1.2 [<=
a href=3D"https://tools.ietf.org/html/rfc5246" title=3D""The Transport=
 Layer Security (TLS) Protocol Version 1.2"" target=3D"_blank">RFC5246=
], DTLS 1.2 [RFC6347],
   TLS 1.3 [I-D.ietf-tls-tls13],=
 ECDHE_PSK [RFC5489], AES-GCM [RFC5288],
   and AES-CCM [RFC6655] apply to this document as well.

NEW 
<=
pre class=3D"m_5356331867454488272gmail-m_4997153826884106269m_442933667941=
3947623m_-101311485245468505m_-6500030207053047939gmail-newpage"> The secur=
ity considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
 ECDHE_PSK [RFC5489], AE=
S-GCM [RFC=
5288],and AES-CCM [RFC6655] apply 
 to this document as well.



S 2.

I'm not sure that the discussion of the PRF is helpful here in

mandating the non-use of these cipher suites with TLS 1.1 and

below.

I find the text useful as=
 it gives an idea why even introducing AEAD in TLS version lower than 1.2 i=
s a bad idea, so I would prefer to keep it. The text has been changed to 
OLD:
As such TLS 1.0 and TLS 1.1 should not be used wit=
h ECDHE_PSK.

NEW:
As such,=C2=A0 all ECDHE_PSK=

ciphers, including those defined outside this document, SHOULD NOT benegotiated in TLS versions prior to 1.2.

I don't think you should be levying a new normat=
ive requirement like this for other ciphers
i this document
=


Consideration for other =
ciphers has been removed. The requirement is limited to the ciphers of the =
document. The new text is:

As such, all ECDHE_PSK ciphers, including=
 those defined in this document, SHOULD NOT be
negotiated in TLS version=
s prior to 1.2.
=


-Ek
=

r






--001a11412d3c6a2d4205503bdba4--

--001a11412d3c6a2d4705503bdba6
Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-tls-ecdhe-psk-aead-05.txt"
Content-Disposition: attachment; 
	filename="draft-ietf-tls-ecdhe-psk-aead-05.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_j32d8whl1

CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBKLiBNYXR0c3NvbgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEQuIE1pZ2F1bHQKSW50ZW5kZWQgc3RhdHVzOiBTdGFu
ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uCkV4cGly
ZXM6IE5vdmVtYmVyIDI0LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1h
eSAyMywgMjAxNwoKCiAgRUNESEVfUFNLIHdpdGggQUVTLUdDTSBhbmQgQUVTLUNDTSBDaXBoZXIg
U3VpdGVzIGZvciBUcmFuc3BvcnQgTGF5ZXIKICAgICAgICAgICAgICAgICAgU2VjdXJpdHkgKFRM
UykgUHJvdG9jb2wgdmVyc2lvbiAxLjIKICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXRs
cy1lY2RoZS1wc2stYWVhZC0wNQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBz
ZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNwb3J0CiAgIExheWVyIFNlY3Vy
aXR5IChUTFMpIHByb3RvY29sIHZlcnNpb24gMS4yLiAgVGhlIGNpcGhlciBzdWl0ZXMgYXJlIGFs
bAogICBiYXNlZCBvbiB0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlIERpZmZpZS1IZWxsbWFu
IHdpdGggUHJlLVNoYXJlZAogICBLZXkgKEVDREhFX1BTSykga2V5IGV4Y2hhbmdlIHRvZ2V0aGVy
IHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQKICAgRW5jcnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0
YSAoQUVBRCkgYWxnb3JpdGhtcyBBRVMtR0NNIGFuZCBBRVMtCiAgIENDTS4gIFBTSyBwcm92aWRl
cyBsaWdodCBhbmQgZWZmaWNpZW50IGF1dGhlbnRpY2F0aW9uLCBFQ0RIRSBwcm92aWRlcwogICBm
b3J3YXJkIHNlY3JlY3ksIGFuZCBBRVMtR0NNIGFuZCBBRVMtQ0NNIHByb3ZpZGVzIGVuY3J5cHRp
b24gYW5kCiAgIGludGVncml0eSBwcm90ZWN0aW9uLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAg
VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRo
IHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAg
VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry
aWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qg
b2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv
Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1
cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkK
ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyBy
ZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsg
aW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3Zl
bWJlciAyNCwgMjAxNy4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNyBJ
RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBh
dXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj
dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxh
dGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5z
ZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBk
b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMg
dGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAoK
CgpNYXR0c3NvbiAmIE1pZ2F1bHQgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI0LCAyMDE3ICAgICAg
ICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVDREhFX1BT
S19BRUFEICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTcKCgogICB0byB0aGlzIGRvY3VtZW50
LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBp
bmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv
biA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3
aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGlj
ZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIEludHJvZHVj
dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAy
CiAgIDMuICBFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMg
IC4gLiAuIC4gLiAuICAgMwogICA0LiAgQXBwbGljYWJsZSBUTFMgVmVyc2lvbnMgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlv
bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDYuICBT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuICAgNAogICA3LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgOC4xLiAgTm9ybWF0
aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog
ICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgIDYKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CgoxLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9u
CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM
IiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs
ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl
cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKMi4gIEludHJvZHVjdGlvbgoKICAg
VGhpcyBkb2N1bWVudCBkZWZpbmVzIG5ldyBjaXBoZXIgc3VpdGVzIHRoYXQgcHJvdmlkZSBQcmUt
U2hhcmVkIEtleQogICAoUFNLKSBhdXRoZW50aWNhdGlvbiwgUGVyZmVjdCBGb3J3YXJkIFNlY3Jl
Y3kgKFBGUyksIGFuZAogICBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVk
IERhdGEgKEFFQUQpLiAgVGhlIGNpcGhlcgogICBzdWl0ZXMgYXJlIGRlZmluZWQgZm9yIHZlcnNp
b24gMS4yIG9mIHRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkKICAgKFRMUykgW1JGQzUyNDZd
IHByb3RvY29sIGFuZCB2ZXJzaW9uIDEuMiBvZiB0aGUgRGF0YWdyYW0gVHJhbnNwb3J0CiAgIExh
eWVyIFNlY3VyaXR5IChEVExTKSBwcm90b2NvbCBbUkZDNjM0N10uCgogICBQcmUtU2hhcmVkIEtl
eSAoUFNLKSBBdXRoZW50aWNhdGlvbiBpcyB3aWRlbHkgdXNlZCBpbiBtYW55IHNjZW5hcmlvcy4K
ICAgT25lIGRlcGxveW1lbnQgaXMgM0dQUCBuZXR3b3JrcyB3aGVyZSBwcmUtc2hhcmVkIGtleXMg
YXJlIHVzZWQgdG8KICAgYXV0aGVudGljYXRlIGJvdGggc3Vic2NyaWJlciBhbmQgbmV0d29yay4g
IEFub3RoZXIgZGVwbG95bWVudCBpcwogICBJbnRlcm5ldCBvZiBUaGluZ3Mgd2hlcmUgUFNLIGF1
dGhlbnRpY2F0aW9uIGlzIG9mdGVuIHByZWZlcnJlZCBmb3IKICAgcGVyZm9ybWFuY2UgYW5kIGVu
ZXJneSBlZmZpY2llbmN5IHJlYXNvbnMuICBJbiBib3RoIHNjZW5hcmlvcyB0aGUKICAgZW5kcG9p
bnRzIGFyZSBvd25lZC9jb250cm9sbGVkIGJ5IGEgcGFydHkgdGhhdCBwcm92aXNpb25zIHRoZSBw
cmUtCiAgIHNoYXJlZCBrZXlzIGFuZCBtYWtlcyBzdXJlIHRoYXQgdGhleSBwcm92aWRlIGEgaGln
aCBsZXZlbCBvZiBlbnRyb3B5LgoKICAgUGVyZmVjdCBGb3J3YXJkIFNlY3JlY3kgKFBGUykgaXMg
YSBzdHJvbmdseSByZWNvbW1lbmRlZCBmZWF0dXJlIGluCiAgIHNlY3VyaXR5IHByb3RvY29sIGRl
c2lnbiBhbmQgY2FuIGJlIGFjY29tcGxpc2hlZCBieSB1c2luZyBhbgogICBlcGhlbWVyYWwgRGlm
ZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlIG1ldGhvZC4gIEVwaGVtZXJhbCBFbGxpcHRpYwogICBD
dXJ2ZSBEaWZmaWUtSGVsbG1hbiAoRUNESEUpIHByb3ZpZGVzIFBGUyB3aXRoIGV4Y2VsbGVudCBw
ZXJmb3JtYW5jZQogICBhbmQgc21hbGwga2V5IHNpemVzLiAgRUNESEUgaXMgbWFuZGF0b3J5IHRv
IGltcGxlbWVudCBpbiBib3RoIEhUVFAvMgogICBbUkZDNzU0MF0gYW5kIENvQVAgW1JGQzcyNTJd
LgoKCgpNYXR0c3NvbiAmIE1pZ2F1bHQgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI0LCAyMDE3ICAg
ICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEVDREhF
X1BTS19BRUFEICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTcKCgogICBBRUFEIGFsZ29yaXRo
bXMgdGhhdCBjb21iaW5lIGVuY3J5cHRpb24gYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGFyZQog
ICBzdHJvbmdseSByZWNvbW1lbmRlZCBmb3IgKEQpVExTIFtSRkM3NTI1XSBhbmQgbm9uLUFFQUQg
YWxnb3JpdGhtcyBhcmUKICAgZm9yYmlkZGVuIHRvIHVzZSBpbiBUTFMgMS4zIFtJLUQuaWV0Zi10
bHMtdGxzMTNdLiAgVGhlIEFFQUQKICAgYWxnb3JpdGhtcyBjb25zaWRlcmVkIGluIHRoaXMgZG9j
dW1lbnQgYXJlIEFFUy1HQ00gYW5kIEFFUy1DQ00uICBUaGUKICAgdXNlIG9mIEFFUy1HQ00gaW4g
VExTIGlzIGRlZmluZWQgaW4gW1JGQzUyODhdIGFuZCB0aGUgdXNlIG9mIEFFUy1DQ00KICAgaXMg
ZGVmaW5lZCBpbiBbUkZDNjY1NV0uCgogICBbUkZDNDI3OV0gZGVmaW5lcyBQcmUtU2hhcmVkIEtl
eSAoUFNLKSBjaXBoZXIgc3VpdGVzIGZvciBUTFMgYnV0IGRvZXMKICAgbm90IGNvbnNpZGVyIEVs
bGlwdGljIEN1cnZlIENyeXB0b2dyYXBoeS4gIFtSRkM0NDkyXSBpbnRyb2R1Y2VzCiAgIEVsbGlw
dGljIEN1cnZlIENyeXB0b2dyYXBoeSBmb3IgVExTIGJ1dCBkb2VzIG5vdCBjb25zaWRlciBQU0sK
ICAgYXV0aGVudGljYXRpb24uICBbUkZDNTQ4N10gZGVzY3JpYmVzIHRoZSB1c2Ugb2YgQUVTLUdD
TSBpbgogICBjb21iaW5hdGlvbiB3aXRoIFBTSyBhdXRoZW50aWNhdGlvbiwgYnV0IGRvZXMgbm90
IGNvbnNpZGVyIEVDREhFLgogICBbUkZDNTQ4OV0gZGVzY3JpYmVzIHRoZSB1c2Ugb2YgUFNLIGlu
IGNvbWJpbmF0aW9uIHdpdGggRUNESEUgYnV0IGRvZXMKICAgbm90IGNvbnNpZGVyIEFFUy1HQ00g
b3IgQUVTLUNDTS4KCjMuICBFQ0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhl
ciBTdWl0ZXMKCiAgIFRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBh
cmUgYmFzZWQgb24gdGhlIEFFUy1HQ00KICAgYW5kIEFFUy1DQ00gQXV0aGVudGljYXRlZCBFbmNy
eXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKQogICBhbGdvcml0aG1zIEFFQURfQUVT
XzEyOF9HQ00sIEFFQURfQUVTXzI1Nl9HQ00gYW5kIEFFQURfQUVTXzEyOF9DQ00KICAgZGVmaW5l
ZCBpbiBbUkZDNTExNl0sIGFuZCBBRUFEX0FFU18xMjhfQ0NNXzggZGVmaW5lZCBpbiBbUkZDNjY1
NV0uCgogICBNZXNzYWdlcyBhbmQgcHJlLW1hc3RlciBzZWNyZXQgY29uc3RydWN0aW9uIGluIHRo
aXMgZG9jdW1lbnQgYXJlCiAgIGRlZmluZWQgaW4gW1JGQzU0ODldLiAgVGhlIFNlcnZlcktleUV4
Y2hhbmdlIGFuZCBDbGllbnRLZXlFeGNoYW5nZQogICBtZXNzYWdlcyBhcmUgdXNlZCBhbmQgdGhl
IHByZS1tYXN0ZXIgc2VjcmV0IGlzIGNvbXB1dGVkIGFzIGZvciB0aGUKICAgRUNESEVfUFNLIGtl
eSBleGNoYW5nZS4gIFRoZSBlbGxpcHRpYyBjdXJ2ZSBwYXJhbWV0ZXJzIHVzZWQgaW4gaW4gdGhl
CiAgIERpZmZpZS1IZWxsbWFuIHBhcmFtZXRlcnMgYXJlIG5lZ290aWF0ZWQgdXNpbmcgZXh0ZW5z
aW9ucyBkZWZpbmVkIGluCiAgIFtJLUQuaWV0Zi10bHMtcmZjNDQ5MmJpc10uCgogICBGb3IgVExT
IDEuMiwgdGhlIGZvbGxvd2luZyBjaXBoZXIgc3VpdGVzIGFyZSBkZWZpbmVkOgoKICAgVExTX0VD
REhFX1BTS19XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiAgID0gezB4VEJELDB4VEJEfTsKICAgVExT
X0VDREhFX1BTS19XSVRIX0FFU18yNTZfR0NNX1NIQTM4NCAgID0gezB4VEJELDB4VEJEfTsKICAg
VExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhfQ0NNXzhfU0hBMjU2ID0gezB4VEJELDB4VEJEfTsK
ICAgVExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhfQ0NNX1NIQTI1NiAgID0gezB4VEJELDB4VEJE
fTsKCiAgIFRoZSBhc3NpZ25lZCBjb2RlIHBvaW50cyBjYW4gb25seSBiZSB1c2VkIGZvciBUTFMg
MS4yLgoKNC4gIEFwcGxpY2FibGUgVExTIFZlcnNpb25zCgogICBUaGUgY2lwaGVyIHN1aXRlcyBk
ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgTVVTVCBOT1QgYmUgbmVnb3RpYXRlZCBmb3IKICAgYW55
IHZlcnNpb24gb2YgKEQpVExTIG90aGVyIHRoYW4gVExTIDEuMi4gIENsaWVudHMgTVVTVCBOT1Qg
b2ZmZXIgb25lCiAgIG9mIHRoZXNlIGNpcGhlciBzdWl0ZXMgd2l0aCBhIChEKVRMUyB2ZXJzaW9u
IHRoYXQgZGlmZmVycyBmcm9tIFRMUwogICAxLjIuICBTZXJ2ZXJzIE1VU1QgTk9UIHNlbGVjdCBv
bmUgb2YgdGhlc2UgY2lwaGVyIHN1aXRlcyB3aXRoIGEgVExTCiAgIHZlcnNpb24gdGhhdCBkaWZm
ZXJzIGZyb20gVExTIDEuMi4gIEEgY2xpZW50IE1VU1QgdHJlYXQgdGhlIHNlbGVjdGlvbgogICBv
ZiB0aGVzZSBjaXBoZXIgc3VpdGVzIGluIGNvbWJpbmF0aW9uIHdpdGggYSB2ZXJzaW9uIG9mIFRM
UyBhcyBhbgogICBlcnJvciBhbmQgZ2VuZXJhdGUgYSBmYXRhbCAnaWxsZWdhbF9wYXJhbWV0ZXIn
IFRMUyBhbGVydC4KCgoKCk1hdHRzc29uICYgTWlnYXVsdCAgICAgIEV4cGlyZXMgTm92ZW1iZXIg
MjQsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg
ICAgICAgRUNESEVfUFNLX0FFQUQgICAgICAgICAgICAgICAgICAgICBNYXkgMjAxNwoKCiAgIFRM
UyB2ZXJzaW9uIDEuMyBhbmQgbGF0ZXIgbmVnb3RpYXRlIHRoZXNlIGZlYXR1cmVzIGluIGEgZGlm
ZmVyZW50CiAgIG1hbm5lci4gIFVubGlrZSBUTFMgMS4yLCBUTFMgMS4zIHNlcGFyYXRlcyBhdXRo
ZW50aWNhdGlvbiBhbmQgY2lwaGVyCiAgIHN1aXRlIG5lZ290aWF0aW9uIFtJLUQuaWV0Zi10bHMt
dGxzMTNdIFNlY3Rpb24gMS4yLiAgVExTIDEuMyBzdXBwb3J0cwogICBQU0sgd2l0aCBFQ0RIRSBr
ZXkgZXhjaGFuZ2UgYW5kIHRoZSBjaXBoZXIgc3VpdGVzCiAgIFRMU19BRVNfMTI4X0dDTV9TSEEy
NTYsIFRMU19BRVNfMjU2X0dDTV9TSEEzODQsCiAgIFRMU19BRVNfMTI4X0NDTV84X1NIQTI1NiBh
bmQgVExTX0FFU18xMjhfQ0NNX1NIQTI1NiBhcmUgcGFydCBvZiB0aGUKICAgc3BlY2lmaWNhdGlv
bi4gIEFzIGEgcmVzdWx0LCBUTFMgMS4zIGFuZCBoaWdoZXIgdmVyc2lvbnMsIG5lZ290aWF0ZQog
ICBhbmQgc3VwcG9ydCB0aGVzZSBjaXBoZXIgc3VpdGVzIGluIGEgZGlmZmVyZW50IHdheS4KCiAg
IFRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBtYWtlIHVzZSBvZiB0
aGUKICAgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIHdpdGggYWRkaXRpb25hbCBkYXRhIChBRUFE
KSBkZWZpbmVkIGluIFRMUwogICAxLjIgW1JGQzUyNDZdIGFuZCBEVExTIDEuMiBbUkZDNjM0N10u
ICBFYXJsaWVyIHZlcnNpb25zIG9mIFRMUyBkbyBub3QKICAgaGF2ZSBzdXBwb3J0IGZvciBBRUFE
IGFuZCBjb25zZXF1ZW50bHksIHRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4KICAgdGhpcyBk
b2N1bWVudCBNVVNUIE5PVCBiZSBuZWdvdGlhdGVkIGluIFRMUyB2ZXJzaW9ucyBwcmlvciB0byAx
LjIuCiAgIEluIGFkZGl0aW9uLCBpdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBUTFMgMS4wIFtSRkMy
MjQ2XSBhbmQgVExTIDEuMgogICBbUkZDNDM0Nl0gc3BsaXQgdGhlIHByZS1tYXN0ZXIgaW50byB0
d28gcGFydHMuICBUaGUgUFJGIHJlc3VsdHMgZnJvbQogICBtaXhpbmcgdGhlIHR3byBwc2V1ZG9y
YW5kb20gc3RyZWFtcyB3aXRoIGRpc3RpbmN0IGhhc2ggZnVuY3Rpb25zIChNRDUKICAgYW5kIFNI
QS0xKSBieSBleGNsdXNpdmUtT1JpbmcgdGhlbSB0b2dldGhlci4gIEluIHRoZSBjYXNlIG9mCiAg
IEVDREhFX1BTSyBhdXRoZW50aWNhdGlvbiwgdGhlIFBTSyBhbmQgRUNESEUgc2hhcmVkIHNlY3Jl
dCBhcmUgdHJlYXRlZAogICBieSBkaXN0aW5jdCBoYXNoIGZ1bmN0aW9uIHdpdGggZGlzdGluY3Qg
cHJvcGVydGllcy4gIFRoaXMgbWF5CiAgIGludHJvZHVjZSB2dWxuZXJhYmlsaXRpZXMgb3ZlciB0
aGUgZXhwZWN0ZWQgc2VjdXJpdHkgcHJvdmlkZWQgYnkgdGhlCiAgIGNvbnN0cnVjdGVkIHByZS1t
YXN0ZXIuICBBcyBzdWNoLCBhbGwgRUNESEVfUFNLIGNpcGhlcnMsIGluY2x1ZGluZwogICB0aG9z
ZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsIFNIT1VMRCBOT1QgYmUgbmVnb3RpYXRlZCBpbiBU
TFMKICAgdmVyc2lvbnMgcHJpb3IgdG8gMS4yLgoKNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAg
IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIG5ldyBjaXBoZXIgc3VpdGVzLCB3
aG9zZSB2YWx1ZXMKICAgaGF2ZSBiZWVuIGFzc2lnbmVkIGluIHRoZSBUTFMgQ2lwaGVyIFN1aXRl
IFJlZ2lzdHJ5IGRlZmluZWQgYnkKICAgW1JGQzUyNDZdLgoKICAgVExTX0VDREhFX1BTS19XSVRI
X0FFU18xMjhfR0NNX1NIQTI1NiAgID0gezB4VEJEOyAweFRCRH0gezB4RDAsMHgwMX07CiAgIFRM
U19FQ0RIRV9QU0tfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQgICA9IHsweFRCRDsgMHhUQkR9IHsw
eEQwLDB4MDJ9OwogICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9DQ01fOF9TSEEyNTYgPSB7
MHhUQkQ7IDB4VEJEfSB7MHhEMCwweDAzfTsKICAgVExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhf
Q0NNX1NIQTI1NiAgID0gezB4VEJEOyAweFRCRH0gezB4RDAsMHgwNX07CgogICBOT1RFIFRPIFRI
RSBSRkMgRURJVE9SOiBQTEVBU0UgUkVNT1ZFIFRISVMgUEFSQUdSQVBILiAgVGhlIGNpcGhlcgog
ICBzdWl0ZSBudW1iZXJzIGxpc3RlZCBpbiB0aGUgbGFzdCBjb2x1bW4gYXJlIG51bWJlcnMgdXNl
ZCBmb3IgY2lwaGVyCiAgIHN1aXRlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhbmQgaXQncyBz
dWdnZXN0ZWQgdGhhdCBJQU5BIHVzZSB0aGVzZQogICB2YWx1ZXMgZm9yIGFzc2lnbm1lbnQuCgo2
LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u
cyBpbiBUTFMgMS4yIFtSRkM1MjQ2XSwgRFRMUyAxLjIgW1JGQzYzNDddLAogICBQU0sgQ2lwaGVy
c3VpdGVzIGZvciBUTFMgW1JGQzQyNzldLCBFQ0RIRV9QU0sgW1JGQzU0ODldLCBBRVMtR0NNCiAg
IFtSRkM1Mjg4XSwgYW5kIEFFUy1DQ00gW1JGQzY2NTVdIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQg
YXMgd2VsbC4KCgoKCgpNYXR0c3NvbiAmIE1pZ2F1bHQgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI0
LCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg
ICAgIEVDREhFX1BTS19BRUFEICAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTcKCgogICBBbGwg
dGhlIGNpcGhlciBzdWl0ZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IHByb3ZpZGUKICAgY29u
ZmlkZW50aWFsaXR5LCBtdXR1YWwgYXV0aGVudGljYXRpb24sIGFuZCBmb3J3YXJkIHNlY3JlY3ku
ICBUaGUKICAgQUVTLTEyOCBjaXBoZXIgc3VpdGVzIHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBh
bmQgdGhlIEFFUy0yNTYgY2lwaGVyCiAgIHN1aXRlcyBwcm92aWRlIGF0IGxlYXN0IDE5Mi1iaXQg
c2VjdXJpdHkuICBIb3dldmVyLCBBRVNfMTI4X0NDTV84CiAgIG9ubHkgcHJvdmlkZXMgNjQtYml0
IHNlY3VyaXR5IGFnYWluc3QgbWVzc2FnZSBmb3JnZXJ5LgoKICAgVGhlIFByZS1TaGFyZWQgS2V5
cyB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBNVVNUIGhhdmUgYSBzZWN1cml0eQogICBsZXZlbCBl
cXVhbCBvciBoaWdoZXIgdGhhbiB0aGUgY2lwaGVyIHN1aXRlIHVzZWQsIGkuZS4sIGF0IGxlYXN0
CiAgIDEyOC1iaXQgZm9yIHRoZSBBRVMtMTI4IGNpcGhlciBzdWl0ZXMgYW5kIGF0IGxlYXN0IDE5
Mi1iaXQgZm9yIHRoZQogICBBRVMtMjU2IGNpcGhlciBzdWl0ZXMuCgogICBHQ00gb3IgQ0NNIGVu
Y3J5cHRpb24gLSBldmVuIG9mIGRpZmZlcmVudCBjbGVhciB0ZXh0IC0gcmUtdXNpbmcgYQogICBu
b25jZSB3aXRoIGEgc2FtZSBrZXkgdW5kZXJtaW5lcyB0aGUgc2VjdXJpdHkgb2YgR0NNIGFuZCBD
Q00uICBBcyBhCiAgIHJlc3VsdCwgR0NNIGFuZCBDQ00gTVVTVCBvbmx5IGJlIHVzZWQgd2l0aCBh
IHN5c3RlbSBndWFyYW50ZWVpbmcKICAgbm9uY2UgdW5pcXVlbmVzcyBbUkZDNTExNl0uCgo3LiAg
QWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBJbGFy
aSBMaXVzdmFhcmEsIEVyaWMgUmVzY29ybGEsIERhbgogICBIYXJraW5zLCBSdXNzIEhvdXNsZXks
IERhbiBIYXJraW5zLCBNYXJ0aW4gVGhvbXNvbiwgTmlrb3MKICAgTWF2cm9naWFubm9wb3Vsb3Ms
IFBldGVyIERldHRtYW4sIFhpYW95aW4gTGl1LCBKb3NlcGggU2Fsb3dleSwgU2VhbgogICBUdXJu
ZXIgRGF2ZSBHYXJyZXR0LCBNYXJ0aW4gUmV4IGFuZCBLYXRobGVlbiBNb3JpYXJ0eSBmb3IgdGhl
aXIKICAgdmFsdWFibGUgY29tbWVudHMgYW5kIGZlZWRiYWNrLgoKOC4gIFJlZmVyZW5jZXMKCjgu
MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmlldGYtdGxzLXJmYzQ0OTJiaXNdCiAg
ICAgICAgICAgICAgTmlyLCBZLiwgSm9zZWZzc29uLCBTLiwgYW5kIE0uIFBlZ291cmllLUdvbm5h
cmQsICJFbGxpcHRpYwogICAgICAgICAgICAgIEN1cnZlIENyeXB0b2dyYXBoeSAoRUNDKSBDaXBo
ZXIgU3VpdGVzIGZvciBUcmFuc3BvcnQgTGF5ZXIKICAgICAgICAgICAgICBTZWN1cml0eSAoVExT
KSBWZXJzaW9ucyAxLjIgYW5kIEVhcmxpZXIiLCBkcmFmdC1pZXRmLXRscy0KICAgICAgICAgICAg
ICByZmM0NDkyYmlzLTE3ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTcuCgogICBbSS1ELmll
dGYtdGxzLXRsczEzXQogICAgICAgICAgICAgIFJlc2NvcmxhLCBFLiwgIlRoZSBUcmFuc3BvcnQg
TGF5ZXIgU2VjdXJpdHkgKFRMUykgUHJvdG9jb2wKICAgICAgICAgICAgICBWZXJzaW9uIDEuMyIs
IGRyYWZ0LWlldGYtdGxzLXRsczEzLTIwICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAg
ICBBcHJpbCAyMDE3LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3Ig
dXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi
LCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBN
YXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v
cmZjMjExOT4uCgogICBbUkZDMjI0Nl0gIERpZXJrcywgVC4gYW5kIEMuIEFsbGVuLCAiVGhlIFRM
UyBQcm90b2NvbCBWZXJzaW9uIDEuMCIsCiAgICAgICAgICAgICAgUkZDIDIyNDYsIERPSSAxMC4x
NzQ4Ny9SRkMyMjQ2LCBKYW51YXJ5IDE5OTksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZj
LWVkaXRvci5vcmcvaW5mby9yZmMyMjQ2Pi4KCgoKCk1hdHRzc29uICYgTWlnYXVsdCAgICAgIEV4
cGlyZXMgTm92ZW1iZXIgMjQsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0
LURyYWZ0ICAgICAgICAgICAgICAgRUNESEVfUFNLX0FFQUQgICAgICAgICAgICAgICAgICAgICBN
YXkgMjAxNwoKCiAgIFtSRkM0Mjc5XSAgRXJvbmVuLCBQLiwgRWQuIGFuZCBILiBUc2Nob2Zlbmln
LCBFZC4sICJQcmUtU2hhcmVkIEtleQogICAgICAgICAgICAgIENpcGhlcnN1aXRlcyBmb3IgVHJh
bnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIiwKICAgICAgICAgICAgICBSRkMgNDI3OSwgRE9J
IDEwLjE3NDg3L1JGQzQyNzksIERlY2VtYmVyIDIwMDUsCiAgICAgICAgICAgICAgPGh0dHA6Ly93
d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0Mjc5Pi4KCiAgIFtSRkM0MzQ2XSAgRGllcmtzLCBU
LiBhbmQgRS4gUmVzY29ybGEsICJUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5CiAgICAgICAg
ICAgICAgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjEiLCBSRkMgNDM0NiwKICAgICAgICAgICAg
ICBET0kgMTAuMTc0ODcvUkZDNDM0NiwgQXByaWwgMjAwNiwKICAgICAgICAgICAgICA8aHR0cDov
L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQzNDY+LgoKICAgW1JGQzUxMTZdICBNY0dyZXcs
IEQuLCAiQW4gSW50ZXJmYWNlIGFuZCBBbGdvcml0aG1zIGZvciBBdXRoZW50aWNhdGVkCiAgICAg
ICAgICAgICAgRW5jcnlwdGlvbiIsIFJGQyA1MTE2LCBET0kgMTAuMTc0ODcvUkZDNTExNiwgSmFu
dWFyeSAyMDA4LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v
cmZjNTExNj4uCgogICBbUkZDNTI0Nl0gIERpZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAiVGhl
IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQogICAgICAgICAgICAgIChUTFMpIFByb3RvY29sIFZl
cnNpb24gMS4yIiwgUkZDIDUyNDYsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzUyNDYs
IEF1Z3VzdCAyMDA4LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu
Zm8vcmZjNTI0Nj4uCgogICBbUkZDNTI4OF0gIFNhbG93ZXksIEouLCBDaG91ZGh1cnksIEEuLCBh
bmQgRC4gTWNHcmV3LCAiQUVTIEdhbG9pcwogICAgICAgICAgICAgIENvdW50ZXIgTW9kZSAoR0NN
KSBDaXBoZXIgU3VpdGVzIGZvciBUTFMiLCBSRkMgNTI4OCwKICAgICAgICAgICAgICBET0kgMTAu
MTc0ODcvUkZDNTI4OCwgQXVndXN0IDIwMDgsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZj
LWVkaXRvci5vcmcvaW5mby9yZmM1Mjg4Pi4KCiAgIFtSRkM2MzQ3XSAgUmVzY29ybGEsIEUuIGFu
ZCBOLiBNb2RhZHVndSwgIkRhdGFncmFtIFRyYW5zcG9ydCBMYXllcgogICAgICAgICAgICAgIFNl
Y3VyaXR5IFZlcnNpb24gMS4yIiwgUkZDIDYzNDcsIERPSSAxMC4xNzQ4Ny9SRkM2MzQ3LAogICAg
ICAgICAgICAgIEphbnVhcnkgMjAxMiwgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y
ZmM2MzQ3Pi4KCiAgIFtSRkM2NjU1XSAgTWNHcmV3LCBELiBhbmQgRC4gQmFpbGV5LCAiQUVTLUND
TSBDaXBoZXIgU3VpdGVzIGZvcgogICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0
eSAoVExTKSIsIFJGQyA2NjU1LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM2NjU1LCBK
dWx5IDIwMTIsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y
ZmM2NjU1Pi4KCjguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkM0NDkyXSAgQmxh
a2UtV2lsc29uLCBTLiwgQm9seWFyZCwgTi4sIEd1cHRhLCBWLiwgSGF3aywgQy4sIGFuZCBCLgog
ICAgICAgICAgICAgIE1vZWxsZXIsICJFbGxpcHRpYyBDdXJ2ZSBDcnlwdG9ncmFwaHkgKEVDQykg
Q2lwaGVyIFN1aXRlcwogICAgICAgICAgICAgIGZvciBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkg
KFRMUykiLCBSRkMgNDQ5MiwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNDQ5MiwgTWF5
IDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0
NDkyPi4KCiAgIFtSRkM1NDg3XSAgQmFkcmEsIE0uLCAiUHJlLVNoYXJlZCBLZXkgQ2lwaGVyIFN1
aXRlcyBmb3IgVExTIHdpdGggU0hBLQogICAgICAgICAgICAgIDI1Ni8zODQgYW5kIEFFUyBHYWxv
aXMgQ291bnRlciBNb2RlIiwgUkZDIDU0ODcsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JG
QzU0ODcsIE1hcmNoIDIwMDksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5v
cmcvaW5mby9yZmM1NDg3Pi4KCgoKCgoKTWF0dHNzb24gJiBNaWdhdWx0ICAgICAgRXhwaXJlcyBO
b3ZlbWJlciAyNCwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg
ICAgICAgICAgICAgICBFQ0RIRV9QU0tfQUVBRCAgICAgICAgICAgICAgICAgICAgIE1heSAyMDE3
CgoKICAgW1JGQzU0ODldICBCYWRyYSwgTS4gYW5kIEkuIEhhamplaCwgIkVDREhFX1BTSyBDaXBo
ZXIgU3VpdGVzIGZvcgogICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExT
KSIsIFJGQyA1NDg5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM1NDg5LCBNYXJjaCAy
MDA5LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTQ4
OT4uCgogICBbUkZDNzI1Ml0gIFNoZWxieSwgWi4sIEhhcnRrZSwgSy4sIGFuZCBDLiBCb3JtYW5u
LCAiVGhlIENvbnN0cmFpbmVkCiAgICAgICAgICAgICAgQXBwbGljYXRpb24gUHJvdG9jb2wgKENv
QVApIiwgUkZDIDcyNTIsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzcyNTIsIEp1bmUg
MjAxNCwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcy
NTI+LgoKICAgW1JGQzc1MjVdICBTaGVmZmVyLCBZLiwgSG9seiwgUi4sIGFuZCBQLiBTYWludC1B
bmRyZSwKICAgICAgICAgICAgICAiUmVjb21tZW5kYXRpb25zIGZvciBTZWN1cmUgVXNlIG9mIFRy
YW5zcG9ydCBMYXllcgogICAgICAgICAgICAgIFNlY3VyaXR5IChUTFMpIGFuZCBEYXRhZ3JhbSBU
cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkKICAgICAgICAgICAgICAoRFRMUykiLCBCQ1AgMTk1LCBS
RkMgNzUyNSwgRE9JIDEwLjE3NDg3L1JGQzc1MjUsIE1heQogICAgICAgICAgICAgIDIwMTUsIDxo
dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzUyNT4uCgogICBbUkZDNzU0MF0gIEJl
bHNoZSwgTS4sIFBlb24sIFIuLCBhbmQgTS4gVGhvbXNvbiwgRWQuLCAiSHlwZXJ0ZXh0CiAgICAg
ICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgVmVyc2lvbiAyIChIVFRQLzIpIiwgUkZDIDc1NDAs
CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc1NDAsIE1heSAyMDE1LAogICAgICAgICAg
ICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzU0MD4uCgpBdXRob3JzJyBB
ZGRyZXNzZXMKCiAgIEpvaG4gTWF0dHNzb24KICAgRXJpY3Nzb24gQUIKICAgU0UtMTY0IDgwIFN0
b2NraG9sbQogICBTd2VkZW4KCiAgIFBob25lOiArNDYgNzYgMTE1IDM1IDAxCiAgIEVtYWlsOiBq
b2huLm1hdHRzc29uQGVyaWNzc29uLmNvbQoKCiAgIERhbmllbCBNaWdhdWx0CiAgIEVyaWNzc29u
CiAgIDg0MDAgYm91bGV2YXJkIERlY2FyaWUKICAgTW9udHJlYWwsIFFDICAgSDRQIDJOMgogICBD
YW5hZGEKCiAgIFBob25lOiArMSA1MTQtNDUyLTIxNjAKICAgRW1haWw6IGRhbmllbC5taWdhdWx0
QGVyaWNzc29uLmNvbQoKCgoKCgoKCgoKCk1hdHRzc29uICYgTWlnYXVsdCAgICAgIEV4cGlyZXMg
Tm92ZW1iZXIgMjQsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA3XQo=
--001a11412d3c6a2d4705503bdba6
Content-Type: text/html; charset="US-ASCII"; 
	name="Diff: draft-ietf-tls-ecdhe-psk-aead-05.txt - draft-ietf-tls-ecdhe-psk-aead-04.txt.html"
Content-Disposition: attachment; 
	filename="Diff: draft-ietf-tls-ecdhe-psk-aead-05.txt - draft-ietf-tls-ecdhe-psk-aead-04.txt.html"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_j32d8wfj0

CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25h
bC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u
YWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NTogcmZjZGlmZiAgLS0+IAo8
IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRp
b25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGRlY2hhdW5hYyAzLjIuMC00LWFtZDY0ICMx
IFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3U2IHg4Nl82NCBHTlUvTGludXggLS0+IAo8IS0tIFVz
aW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjEuMSwgQVBJOiAxLjEgKEdOVSBNUEZS
IDMuMS4zLCBHTlUgTVAgNi4wLjApIC0tPiAKPCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9kaWZm
OiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjMgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvdXNyL2Jp
bi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjIgLS0+IAo8aHRtbCB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvMTk5OS94aHRtbCI+IAo8aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29u
dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIC8+IAogIDxtZXRh
IGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlwZSIgY29udGVudD0idGV4dC9jc3MiIC8+IAog
IDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wNS50eHQgLSBkcmFm
dC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wNC50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0i
dGV4dC9jc3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1
dG87IH0gCiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBm
b250LWZhbWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAu
ODZlbTt9IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7
IGZvbnQtc2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRh
bmEsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNv
bG9yOiAjRUVFOyB9IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAg
ICAuZGlmZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNr
Z3JvdW5kLWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNG
Rjg7IH0gCiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxl
dGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQt
Y29sb3I6ICNGRkI7IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAK
ICAgIC5saW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNv
bG9yOiByZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQt
YWxpZ246IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5k
LWNvbG9yOiAjQUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRERE
OyB9IAogICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5s
YmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29u
dCB7IGJhY2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dy
b3VuZC1jb2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y
OiAjOEFEOyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQt
Y29sb3I6ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogICAgc3Bhbi5oaWRlIHsgZGlzcGxheTog
bm9uZTsgY29sb3I6ICNhYWE7fSAgICBhOmhvdmVyIHNwYW4geyBkaXNwbGF5OiBpbmxpbmU7IH0g
ICAgdHIuY2hhbmdlIHsgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsgfSAKICAgIHRyLmNoYW5nZSBh
IHsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjb2xvcjogYmxhY2sgfSAKICA8L3N0eWxlPiAKICAg
ICA8c2NyaXB0Pgp2YXIgY2h1bmtfaW5kZXggPSAwOwp2YXIgb2xkX2NodW5rID0gbnVsbDsKCmZ1
bmN0aW9uIGZvcm1hdF9jaHVuayhpbmRleCkgewogICAgdmFyIHByZWZpeCA9ICJkaWZmIjsKICAg
IHZhciBzdHIgPSBpbmRleC50b1N0cmluZygpOwogICAgZm9yICh4PTA7IHg8KDQtc3RyLmxlbmd0
aCk7ICsreCkgewogICAgICAgIHByZWZpeCs9JzAnOwogICAgfQogICAgcmV0dXJuIHByZWZpeCAr
IHN0cjsKfQoKZnVuY3Rpb24gZmluZF9jaHVuayhuKXsKICAgIHJldHVybiBkb2N1bWVudC5xdWVy
eVNlbGVjdG9yKCd0cltpZCQ9IicgKyBuICsgJyJdJyk7Cn0KCmZ1bmN0aW9uIGNoYW5nZV9jaHVu
ayhvZmZzZXQpIHsKICAgIHZhciBpbmRleCA9IGNodW5rX2luZGV4ICsgb2Zmc2V0OwogICAgdmFy
IG5ld19zdHI7CiAgICB2YXIgbmV3X2NodW5rOwoKICAgIG5ld19zdHIgPSBmb3JtYXRfY2h1bmso
aW5kZXgpOwogICAgbmV3X2NodW5rID0gZmluZF9jaHVuayhuZXdfc3RyKTsKICAgIGlmICghbmV3
X2NodW5rKSB7CiAgICAgICAgcmV0dXJuOwogICAgfQogICAgaWYgKG9sZF9jaHVuaykgewogICAg
ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIiI7CiAgICB9CiAgICBvbGRfY2h1bmsgPSBu
ZXdfY2h1bms7CiAgICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIxcHggc29saWQgcmVkIjsK
ICAgIHdpbmRvdy5sb2NhdGlvbi5oYXNoID0gIiMiICsgbmV3X3N0cjsKICAgIHdpbmRvdy5zY3Jv
bGxCeSgwLC0xMDApOwogICAgY2h1bmtfaW5kZXggPSBpbmRleDsKfQoKZG9jdW1lbnQub25rZXlk
b3duID0gZnVuY3Rpb24oZSkgewogICAgc3dpdGNoIChlLmtleUNvZGUpIHsKICAgIGNhc2UgNzg6
CiAgICAgICAgY2hhbmdlX2NodW5rKDEpOwogICAgICAgIGJyZWFrOwogICAgY2FzZSA4MDoKICAg
ICAgICBjaGFuZ2VfY2h1bmsoLTEpOwogICAgICAgIGJyZWFrOwogICAgfQp9OwogICA8L3Njcmlw
dD4gCjwvaGVhZD4gCjxib2R5ID4gCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi
IGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRyIGlkPSJwYXJ0LTEiIGJnY29sb3I9Im9yYW5nZSI+PHRo
PjwvdGg+PHRoPjxhIGhyZWY9Ii9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNr
LWFlYWQtMDUudHh0IiBzdHlsZT0iY29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4m
bHQ7PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wNS50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1p
ZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wNS50eHQ8L2E+Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRo
PiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRs
cy1lY2RoZS1wc2stYWVhZC0wNC50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLXRs
cy1lY2RoZS1wc2stYWVhZC0wNC50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iL3JmY2RpZmY/dXJsMT1k
cmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wNC50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0
ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAKICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5OZXR3b3Jr
IFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4g
TWF0dHNzb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5OZXR3b3JrIFdvcmtpbmcg
R3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gTWF0dHNzb248
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gTWlnYXVsdDwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgRC4gTWlnYXVsdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEVyaWNzc29uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50
ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIEVyaWNzc29uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg
aWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IE5vdmVtYmVyIDxzcGFuIGNsYXNzPSJk
ZWxldGUiPjI0LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1heSAyMzwv
c3Bhbj4sIDIwMTc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogTm92
ZW1iZXIgPHNwYW4gY2xhc3M9Imluc2VydCI+MTksIDIwMTcgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgTWF5IDE4PC9zcGFuPiwgMjAxNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gIEVDREhFX1BTSyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1DQ00gQ2lwaGVyIFN1aXRl
cyBmb3IgVHJhbnNwb3J0IExheWVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICBF
Q0RIRV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMgZm9yIFRyYW5z
cG9ydCBMYXllcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk
PSJkaWZmMDAwMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICBTZWN1cml0eSAoVExTKSA8
c3BhbiBjbGFzcz0iZGVsZXRlIj5Qcm90b2NvbCB2ZXJzaW9uIDEuMjwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZWN1
cml0eSAoVExTKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs
ZXRlIj4gICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLTA1
PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAg
ICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLTA0
PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3Vp
dGVzIGZvciB0aGUgVHJhbnNwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
VGhpcyBkb2N1bWVudCBkZWZpbmVzIHNldmVyYWwgbmV3IGNpcGhlciBzdWl0ZXMgZm9yIHRoZSBU
cmFuc3BvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i
ZGlmZjAwMDMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgTGF5ZXIgU2VjdXJpdHkgKFRMUykgPHNwYW4gY2xhc3M9
ImRlbGV0ZSI+cHJvdG9jb2wgdmVyc2lvbiAxLjIuPC9zcGFuPiAgVGhlIGNpcGhlciBzdWl0ZXMg
YXJlIGFsbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBMYXllciBTZWN1cml0
eSAoVExTKSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wcm90b2NvbC48L3NwYW4+ICBUaGUgY2lwaGVy
IHN1aXRlcyBhcmUgYWxsIGJhc2VkIG9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg
IGJhc2VkIG9uIHRoZSBFcGhlbWVyYWwgRWxsaXB0aWMgQ3VydmUgRGlmZmllLUhlbGxtYW4gd2l0
aCBQcmUtU2hhcmVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoZSBFcGhl
bWVyYWwgRWxsaXB0aWMgQ3VydmUgRGlmZmllLUhlbGxtYW4gd2l0aCBQcmUtU2hhcmVkIEtleTwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBLZXkgKEVDREhFX1BTSykga2V5IGV4Y2hh
bmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+ICAgKEVDREhFX1BTSykga2V5IGV4Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhl
IEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g
ICBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0aG1zIEFFUy1H
Q00gYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPkFFUy08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPiAgIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBhbGdvcml0aG1z
IEFFUy1HQ00gYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFFUy1DQ00uPC9zcGFuPiAgUFNLPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIENDTS48
L3NwYW4+ICBQU0sgcHJvdmlkZXMgbGlnaHQgYW5kIGVmZmljaWVudCBhdXRoZW50aWNhdGlvbiwg
RUNESEUgcHJvdmlkZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcHJvdmlk
ZXMgbGlnaHQgYW5kIGVmZmljaWVudCBhdXRoZW50aWNhdGlvbiwgRUNESEUgcHJvdmlkZXMgZm9y
d2FyZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBmb3J3YXJkIHNlY3JlY3ksIGFu
ZCBBRVMtR0NNIGFuZCBBRVMtQ0NNIHByb3ZpZGVzIGVuY3J5cHRpb24gYW5kPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHNlY3JlY3ksIGFuZCBBRVMtR0NNIGFuZCBBRVMtQ0NN
IHByb3ZpZGVzIGVuY3J5cHRpb24gYW5kIGludGVncml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj4gICBpbnRlZ3JpdHkgcHJvdGVjdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+ICAgcHJvdGVjdGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlN0YXR1
cyBvZiBUaGlzIE1lbW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJ
bnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMg
c3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3
b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l
bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNv
IGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNl
IChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt
RHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBU
aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu
dC8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh
bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh
IG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5k
IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50
cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVw
ZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUg
dG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt
RHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJp
YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBv
dGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNCI+PHRkPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlz
IEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE5vdmVtYmVyIDxzcGFuIGNsYXNzPSJkZWxl
dGUiPjI0PC9zcGFuPiwgMjAxNy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg
VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3ZlbWJlciA8c3BhbiBjbGFzcz0i
aW5zZXJ0Ij4xOTwvc3Bhbj4sIDIwMTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmln
aHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdodCAo
YykgMjAxNyBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAxNyBJRVRGIFRy
dXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo
dHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9j
dW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg
dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv
Y3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90cnVzdGVlLmll
dGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut
aW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBk
b2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJsaWNhdGlvbiBv
ZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNz
PSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h
bGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBwYWdlIDIsIGxpbmUgMTY8c3BhbiBjbGFzcz0iaGlk
ZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBw
aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBwYWdlIDIsIGxp
bmUgMTY8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91
dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBUcnVz
dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVk
IEJTRCBMaWNlbnNlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRlc2NyaWJl
ZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAx
LiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAgIDI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxLiAgUmVxdWly
ZW1lbnRzIG5vdGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
IDI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBJbnRyb2R1Y3Rpb24gIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDIuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgMy4gIEVDREhFX1BTSyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1DQ00gQ2lwaGVy
IFN1aXRlcyAgLiAuIC4gLiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgMy4gIEVDREhFX1BTSyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1DQ00gQ2lwaGVyIFN1aXRlcyAg
LiAuIC4gLiAuIC4gICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA0LiAgQXBwbGlj
YWJsZSBUTFMgVmVyc2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
IDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA0LiAgQXBwbGljYWJsZSBUTFMg
VmVyc2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA2LiAgU2VjdXJpdHkg
Q29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxz
cGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDcuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIDcuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA4LiAgUmVmZXJlbmNlcyAg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFu
IGNsYXNzPSJkZWxldGUiPjU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+ICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9z
cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDguMS4gIE5vcm1hdGl2
ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFu
IGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg
ICAgOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Njwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+ICAgICA4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9z
cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPjEuICBSZXF1aXJlbWVudHMgbm90YXRpb248L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij4xLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uPC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi
UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwg
IlNIQUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAiU0hP
VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg
aW4gdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJTSE9VTEQiLCAiU0hP
VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzPC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0
ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtS
RkMyMTE5XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4gIEludHJvZHVjdGlv
bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuICBJbnRyb2R1Y3Rpb248L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIG5ldyBj
aXBoZXIgc3VpdGVzIHRoYXQgcHJvdmlkZSBQcmUtU2hhcmVkIEtleTwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBuZXcgY2lwaGVyIHN1aXRl
cyB0aGF0IHByb3ZpZGUgUHJlLVNoYXJlZCBLZXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIChQU0spIGF1dGhlbnRpY2F0aW9uLCBQZXJmZWN0IEZvcndhcmQgU2VjcmVjeSAoUEZTKSwg
YW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKFBTSykgYXV0aGVudGljYXRp
b24sIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IChQRlMpLCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0
YSAoQUVBRCkuICBUaGUgY2lwaGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
QXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKS4gIFRo
ZSBjaXBoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN1aXRlcyBhcmUgZGVmaW5l
ZCBmb3IgdmVyc2lvbiAxLjIgb2YgdGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eTwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHN1aXRlcyBhcmUgZGVmaW5lZCBmb3IgdmVyc2lv
biAxLjIgb2YgdGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNyI+PHRkPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAoVExT
KSBbUkZDNTI0Nl0gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+cHJvdG9jb2wgYW5kPC9zcGFuPiB2ZXJz
aW9uIDEuMiBvZiB0aGUgRGF0YWdyYW0gVHJhbnNwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPiAgIChUTFMpIFtSRkM1MjQ2XSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wcm90b2Nv
bCw8L3NwYW4+IHZlcnNpb24gMS4yIG9mIHRoZSBEYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXI8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgTGF5ZXIgU2VjdXJpdHkgKERUTFMpIHByb3Rv
Y29sIDxzcGFuIGNsYXNzPSJkZWxldGUiPltSRkM2MzQ3XS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyYmxvY2siPiAgIFNlY3VyaXR5IChEVExTKSBwcm90b2NvbCA8c3BhbiBjbGFz
cz0iaW5zZXJ0Ij5bUkZDNjM0N10sIGFzIHdlbGwgYXMgdmVyc2lvbiAxLjMgb2YgVExTPC9zcGFu
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgW0ktRC5pZXRmLXRscy10bHMxM10uPC9z
cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcmUtU2hhcmVkIEtleSAo
UFNLKSBBdXRoZW50aWNhdGlvbiBpcyB3aWRlbHkgdXNlZCBpbiBtYW55IHNjZW5hcmlvcy48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcmUtU2hhcmVkIEtleSAoUFNLKSBBdXRo
ZW50aWNhdGlvbiBpcyB3aWRlbHkgdXNlZCBpbiBtYW55IHNjZW5hcmlvcy48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIE9uZSBkZXBsb3ltZW50IGlzIDNHUFAgbmV0d29ya3Mgd2hlcmUg
cHJlLXNoYXJlZCBrZXlzIGFyZSB1c2VkIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgT25lIGRlcGxveW1lbnQgaXMgM0dQUCBuZXR3b3JrcyB3aGVyZSBwcmUtc2hhcmVkIGtl
eXMgYXJlIHVzZWQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhlbnRpY2F0
ZSBib3RoIHN1YnNjcmliZXIgYW5kIG5ldHdvcmsuICBBbm90aGVyIGRlcGxveW1lbnQgaXM8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdXRoZW50aWNhdGUgYm90aCBzdWJzY3Jp
YmVyIGFuZCBuZXR3b3JrLiAgQW5vdGhlciBkZXBsb3ltZW50IGlzPC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBJbnRlcm5ldCBvZiBUaGluZ3Mgd2hlcmUgUFNLIGF1dGhlbnRpY2F0aW9u
IGlzIG9mdGVuIHByZWZlcnJlZCBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBJbnRlcm5ldCBvZiBUaGluZ3Mgd2hlcmUgUFNLIGF1dGhlbnRpY2F0aW9uIGlzIG9mdGVuIHBy
ZWZlcnJlZCBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBlcmZvcm1hbmNlIGFu
ZCBlbmVyZ3kgZWZmaWNpZW5jeSByZWFzb25zLiAgSW4gYm90aCBzY2VuYXJpb3MgdGhlPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcGVyZm9ybWFuY2UgYW5kIGVuZXJneSBlZmZp
Y2llbmN5IHJlYXNvbnMuICBJbiBib3RoIHNjZW5hcmlvcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIGVuZHBvaW50cyBhcmUgb3duZWQvY29udHJvbGxlZCBieSBhIHBhcnR5IHRo
YXQgcHJvdmlzaW9ucyB0aGUgcHJlLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IGVuZHBvaW50cyBhcmUgb3duZWQvY29udHJvbGxlZCBieSBhIHBhcnR5IHRoYXQgcHJvdmlzaW9u
cyB0aGUgcHJlLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2hhcmVkIGtleXMgYW5k
IG1ha2VzIHN1cmUgdGhhdCB0aGV5IHByb3ZpZGUgYSBoaWdoIGxldmVsIG9mIGVudHJvcHkuPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2hhcmVkIGtleXMgYW5kIG1ha2VzIHN1
cmUgdGhhdCB0aGV5IHByb3ZpZGUgYSBoaWdoIGxldmVsIG9mIGVudHJvcHkuPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IChQRlMpIGlz
IGEgc3Ryb25nbHkgcmVjb21tZW5kZWQgZmVhdHVyZSBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IChQRlMpIGlzIGEgc3Ryb25nbHkg
cmVjb21tZW5kZWQgZmVhdHVyZSBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMyIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48
c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0zIj48ZW0+
IHBhZ2UgMywgbGluZSA0NjxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9h
PjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48
YSBocmVmPSIjcGFydC0zIj48ZW0+IHBhZ2UgMywgbGluZSA0ODxzcGFuIGNsYXNzPSJoaWRlIj4g
JnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVExTX0VDREhFX1BTS19XSVRI
X0FFU18xMjhfR0NNX1NIQTI1NiAgID0gezB4VEJELDB4VEJEfTs8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9HQ01fU0hBMjU2ICAg
PSB7MHhUQkQsMHhUQkR9OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVExTX0VDREhF
X1BTS19XSVRIX0FFU18yNTZfR0NNX1NIQTM4NCAgID0gezB4VEJELDB4VEJEfTs8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzI1Nl9HQ01f
U0hBMzg0ICAgPSB7MHhUQkQsMHhUQkR9OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
VExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhfQ0NNXzhfU0hBMjU2ID0gezB4VEJELDB4VEJEfTs8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVT
XzEyOF9DQ01fOF9TSEEyNTYgPSB7MHhUQkQsMHhUQkR9OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgVExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhfQ0NNX1NIQTI1NiAgID0gezB4VEJE
LDB4VEJEfTs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUTFNfRUNESEVfUFNL
X1dJVEhfQUVTXzEyOF9DQ01fU0hBMjU2ICAgPSB7MHhUQkQsMHhUQkR9OzwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgYXNzaWduZWQgY29kZSBwb2ludHMgY2FuIG9ubHkg
YmUgdXNlZCBmb3IgVExTIDEuMi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU
aGUgYXNzaWduZWQgY29kZSBwb2ludHMgY2FuIG9ubHkgYmUgdXNlZCBmb3IgVExTIDEuMi48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4gIEFwcGxpY2FibGUgVExTIFZlcnNpb25z
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIEFwcGxpY2FibGUgVExTIFZlcnNp
b25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBjaXBoZXIgc3VpdGVz
IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBNVVNUIE5PVCBiZSBuZWdvdGlhdGVkIGZvcjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQg
aW4gdGhpcyBkb2N1bWVudCBNVVNUIE5PVCBiZSBuZWdvdGlhdGVkIGZvcjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g
ICBhbnkgdmVyc2lvbiBvZiAoRClUTFMgb3RoZXIgdGhhbiBUTFMgMS4yLiAgPHNwYW4gY2xhc3M9
ImRlbGV0ZSI+Q2xpZW50cyBNVVNUIE5PVCBvZmZlciBvbmU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFueSB2ZXJzaW9uIG9mIChEKVRMUyBvdGhlciB0aGFuIFRM
UyAxLjIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi
PiAgIG9mIHRoZXNlIGNpcGhlciBzdWl0ZXMgd2l0aCBhIChEKVRMUyB2ZXJzaW9uIHRoYXQgZGlm
ZmVycyBmcm9tIFRMUzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIDEuMi4g
IFNlcnZlcnMgTVVTVCBOT1Qgc2VsZWN0IG9uZSBvZiB0aGVzZSBjaXBoZXIgc3VpdGVzIHdpdGgg
YSBUTFM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICB2ZXJzaW9uIHRoYXQg
ZGlmZmVycyBmcm9tIFRMUyAxLjIuICBBIGNsaWVudCBNVVNUIHRyZWF0IHRoZSBzZWxlY3Rpb248
L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBvZiB0aGVzZSBjaXBoZXIgc3Vp
dGVzIGluIGNvbWJpbmF0aW9uIHdpdGggYSB2ZXJzaW9uIG9mIFRMUyBhcyBhbjwvc3Bhbj48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGVycm9yIGFuZCBnZW5lcmF0ZSBhIGZhdGFsICdp
bGxlZ2FsX3BhcmFtZXRlcicgVExTIGFsZXJ0Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRMUyB2ZXJz
aW9uIDEuMyBhbmQgbGF0ZXIgbmVnb3RpYXRlIHRoZXNlIGZlYXR1cmVzIGluIGEgZGlmZmVyZW50
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVExTIHZlcnNpb24gMS4zIGFuZCBs
YXRlciBuZWdvdGlhdGUgdGhlc2UgZmVhdHVyZXMgaW4gYSBkaWZmZXJlbnQ8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIG1hbm5lci4gIFVubGlrZSBUTFMgMS4yLCBUTFMgMS4zIHNlcGFy
YXRlcyBhdXRoZW50aWNhdGlvbiBhbmQgY2lwaGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgbWFubmVyLiAgVW5saWtlIFRMUyAxLjIsIFRMUyAxLjMgc2VwYXJhdGVzIGF1dGhl
bnRpY2F0aW9uIGFuZCBjaXBoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN1aXRl
IG5lZ290aWF0aW9uIFtJLUQuaWV0Zi10bHMtdGxzMTNdIFNlY3Rpb24gMS4yLiAgVExTIDEuMyBz
dXBwb3J0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHN1aXRlIG5lZ290aWF0
aW9uIFtJLUQuaWV0Zi10bHMtdGxzMTNdIFNlY3Rpb24gMS4yLiAgVExTIDEuMyBzdXBwb3J0czwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNLIHdpdGggRUNESEUga2V5IGV4Y2hhbmdl
IGFuZCB0aGUgY2lwaGVyIHN1aXRlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IFBTSyB3aXRoIEVDREhFIGtleSBleGNoYW5nZSBhbmQgdGhlIGNpcGhlciBzdWl0ZXM8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRMU19BRVNfMTI4X0dDTV9TSEEyNTYsIFRMU19BRVNf
MjU2X0dDTV9TSEEzODQsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVExTX0FF
U18xMjhfR0NNX1NIQTI1NiwgVExTX0FFU18yNTZfR0NNX1NIQTM4NCw8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIFRMU19BRVNfMTI4X0NDTV84X1NIQTI1NiBhbmQgVExTX0FFU18xMjhf
Q0NNX1NIQTI1NiBhcmUgcGFydCBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBUTFNfQUVTXzEyOF9DQ01fOF9TSEEyNTYgYW5kIFRMU19BRVNfMTI4X0NDTV9TSEEyNTYg
YXJlIHBhcnQgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzcGVjaWZpY2F0
aW9uLiAgQXMgYSByZXN1bHQsIFRMUyAxLjMgYW5kIGhpZ2hlciB2ZXJzaW9ucywgbmVnb3RpYXRl
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWNhdGlvbi4gIEFzIGEg
cmVzdWx0LCBUTFMgMS4zIGFuZCBoaWdoZXIgdmVyc2lvbnMsIG5lZ290aWF0ZTwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIHN1cHBvcnQgdGhlc2UgY2lwaGVyIHN1aXRlcyBpbiBh
IGRpZmZlcmVudCB3YXkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIHN1
cHBvcnQgdGhlc2UgY2lwaGVyIHN1aXRlcyBpbiBhIGRpZmZlcmVudCB3YXkuPC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBjaXBoZXIgc3VpdGVzIGRlZmluZWQgaW4gdGhp
cyBkb2N1bWVudCBtYWtlIHVzZSBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBUaGUgY2lwaGVyIHN1aXRlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgbWFrZSB1c2Ug
b2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhdXRoZW50aWNhdGVkIGVuY3J5
cHRpb24gd2l0aCBhZGRpdGlvbmFsIGRhdGEgKEFFQUQpIGRlZmluZWQgaW4gVExTPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIHdpdGgg
YWRkaXRpb25hbCBkYXRhIChBRUFEKSBkZWZpbmVkIGluIFRMUzwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgMS4yIFtSRkM1MjQ2XSBhbmQgRFRMUyAxLjIgW1JGQzYzNDddLiAgRWFybGll
ciB2ZXJzaW9ucyBvZiBUTFMgZG8gbm90PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgMS4yIFtSRkM1MjQ2XSBhbmQgRFRMUyAxLjIgW1JGQzYzNDddLiAgRWFybGllciB2ZXJzaW9u
cyBvZiBUTFMgZG8gbm90PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBoYXZlIHN1cHBv
cnQgZm9yIEFFQUQgYW5kIGNvbnNlcXVlbnRseSwgdGhlIGNpcGhlciBzdWl0ZXMgZGVmaW5lZCBp
bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhhdmUgc3VwcG9ydCBmb3IgQUVB
RCBhbmQgY29uc2VxdWVudGx5LCB0aGUgY2lwaGVyIHN1aXRlcyBkZWZpbmVkIGluPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGlzIGRvY3VtZW50IE1VU1QgTk9UIGJlIG5lZ290aWF0
ZWQgaW4gVExTIHZlcnNpb25zIHByaW9yIHRvIDEuMi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICB0aGlzIGRvY3VtZW50IE1VU1QgTk9UIGJlIG5lZ290aWF0ZWQgaW4gVExTIHZl
cnNpb25zIHByaW9yIHRvIDEuMi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0ciBpZD0iZGlmZjAwMDkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgSW4gYWRkaXRpb24sIGl0IGlzIHdv
cnRoIG5vdGluZyB0aGF0IFRMUyAxLjAgW1JGQzIyNDZdIGFuZCA8c3BhbiBjbGFzcz0iZGVsZXRl
Ij5UTFMgMS4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJbiBh
ZGRpdGlvbiwgaXQgaXMgd29ydGggbm90aW5nIHRoYXQgVExTIDEuMCBbUkZDMjI0Nl0gYW5kIDxz
cGFuIGNsYXNzPSJpbnNlcnQiPlRMMS4yPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs
b2NrIj4gICBbUkZDNDM0Nl0gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c3BsaXQ8L3NwYW4+IHRoZSBw
cmUtbWFzdGVyIDxzcGFuIGNsYXNzPSJkZWxldGUiPmludG88L3NwYW4+IHR3byBwYXJ0cy4gIFRo
ZSBQUkYgcmVzdWx0cyBmcm9tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFtS
RkM0MzQ2XSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zcGxpdHM8L3NwYW4+IHRoZSBwcmUtbWFzdGVy
IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmluPC9zcGFuPiB0d28gcGFydHMuICBUaGUgUFJGIHJlc3Vs
dHMgZnJvbTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWl4aW5nIHRoZSB0d28gcHNl
dWRvcmFuZG9tIHN0cmVhbXMgd2l0aCBkaXN0aW5jdCBoYXNoIGZ1bmN0aW9ucyAoTUQ1PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWl4aW5nIHRoZSB0d28gcHNldWRvcmFuZG9t
IHN0cmVhbXMgd2l0aCBkaXN0aW5jdCBoYXNoIGZ1bmN0aW9ucyAoTUQ1PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBhbmQgU0hBLTEpIGJ5IGV4Y2x1c2l2ZS1PUmluZyB0aGVtIHRvZ2V0
aGVyLiAgSW4gdGhlIGNhc2Ugb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh
bmQgU0hBLTEpIGJ5IGV4Y2x1c2l2ZS1PUmluZyB0aGVtIHRvZ2V0aGVyLiAgSW4gdGhlIGNhc2Ug
b2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw
MTAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+ICAgRUNESEVfUFNLIGF1dGhlbnRpY2F0aW9uLCB0aGUgUFNLIGFuZCA8
c3BhbiBjbGFzcz0iZGVsZXRlIj5FQ0RIRSBzaGFyZWQgc2VjcmV0PC9zcGFuPiBhcmUgdHJlYXRl
ZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBFQ0RIRV9QU0sgYXV0aGVudGlj
YXRpb24sIHRoZSBQU0sgYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnByZS1tYXN0ZXI8L3NwYW4+
IGFyZSB0cmVhdGVkIGJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGJ5IGRpc3Rp
bmN0IGhhc2ggZnVuY3Rpb24gd2l0aCBkaXN0aW5jdCBwcm9wZXJ0aWVzLiAgVGhpcyBtYXk8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZGlzdGluY3QgaGFzaCBmdW5jdGlvbiB3
aXRoIGRpc3RpbmN0IHByb3BlcnRpZXMuICBUaGlzIG1heSBpbnRyb2R1Y2U8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+ICAgaW50cm9kdWNlIHZ1bG5lcmFiaWxpdGllcyBvdmVyIHRoZSBl
eHBlY3RlZCBzZWN1cml0eSBwcm92aWRlZCBieSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+ICAgdnVsbmVyYWJpbGl0aWVzIG92ZXIgdGhlIGV4cGVjdGVkIHNlY3VyaXR5IHBy
b3ZpZGVkIGJ5IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBjb25zdHJ1Y3Rl
ZCBwcmUtbWFzdGVyLiAgQXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+c3VjaCwgYWxsIEVDREhFX1BT
SyBjaXBoZXJzLCBpbmNsdWRpbmc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPiAgIGNvbnN0cnVjdGVkIHByZS1tYXN0ZXIuICBBcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5z
dWNoIFRMUyAxLjAgYW5kIFRMUyAxLjEgc2hvdWxkIG5vdCBiZTwvc3Bhbj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdGhvc2UgZGVmaW5lZDwv
c3Bhbj4gaW4gdGhpcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5kb2N1bWVudCwgU0hPVUxEPC9zcGFu
PiBOT1QgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YmUgbmVnb3RpYXRlZDwvc3Bhbj4gaW4gVExTPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHVz
ZWQgd2l0aCBFQ0RIRV9QU0suPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g
ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj52ZXJzaW9ucyBwcmlvcjwvc3Bhbj4gdG8gMS4yLjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBBIGNsaWVudCB0aGF0IG9mZmVycyB0aGUg
Y2lwaGVyIHN1aXRlcyBmcm9tIHRoaXMgZG9jdW1lbnQgaW48L3NwYW4+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj
bGFzcz0iaW5zZXJ0Ij4gICBDbGllbnRIZWxsby5jaXBoZXJfc3VpdGVzPC9zcGFuPiBpbiA8c3Bh
biBjbGFzcz0iaW5zZXJ0Ij5jb21iaW5hdGlvbiB3aXRoICgzLDEpICJUTFMgMS4wIiBvcjwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICgzLDIpICJUTFMgMS4xIiBpbiBDbGll
bnRIZWxsby5jbGllbnRfdmVyc2lvbiBNVVNUIHN1cHBvcnQgVExTIDEuMjwvc3Bhbj48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGFuZCBNVVNUIGFjY2VwdCB0aGUgc2VydmVyIHRvIG5l
Z290aWF0ZSBUTFMgMS4yIGZvciB0aGUgY3VycmVudDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz
PSJpbnNlcnQiPiAgIHNlc3Npb24uICBJZiB0aGUgY2xpZW50IGRvZXMgbm90IHN1cHBvcnQgVExT
IDEuMiBvciBpcyBub3Qgd2lsbGluZyB0bzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi
bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl
cnQiPiAgIG5lZ290aWF0ZSBUTFMgMS4yLCB0aGVuPC9zcGFuPiB0aGlzIDxzcGFuIGNsYXNzPSJp
bnNlcnQiPmNsaWVudCBNVVNUPC9zcGFuPiBOT1QgPHNwYW4gY2xhc3M9Imluc2VydCI+b2ZmZXIg
YW55IG9mIHRoZXNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgY2lwaGVy
IHN1aXRlcyB3aXRoIGEgbG93ZXIgcHJvdG9jb2wgdmVyc2lvbiB0aGFuICgzLDMpICJUTFMgMS4y
Ijwvc3Bhbj4gaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkNsaWVudEhlbGxvLmNs
aWVudF92ZXJzaW9uLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEEgc2VydmVyIHJlY2VpdmluZyBhIENsaWVu
dEhlbGxvIGFuZCBhIGNsaWVudF92ZXJzaW9uIGluZGljYXRpbmc8L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4gICAoMywxKSAiVExTIDEuMCIgb3IgKDMsMikgIlRMUyAxLjEiIGFu
ZCBhbnkgb2YgdGhlIGNpcGhlciBzdWl0ZXMgZnJvbTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz
PSJpbnNlcnQiPiAgIHRoaXMgZG9jdW1lbnQgaW4gQ2xpZW50SGVsbG8uY2lwaGVyX3N1aXRlcyBj
YW4gc2FmZWx5IGFzc3VtZSB0aGF0IHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi
bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl
cnQiPiAgIGNsaWVudCBzdXBwb3J0czwvc3Bhbj4gVExTIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEu
MiBhbmQgaXMgd2lsbGluZzwvc3Bhbj4gdG8gPHNwYW4gY2xhc3M9Imluc2VydCI+dXNlIGl0LiAg
VGhlIHNlcnZlciBNVVNUPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgTk9U
IG5lZ290aWF0ZSB0aGVzZSBjaXBoZXIgc3VpdGVzIHdpdGggVExTIHByb3RvY29sIHZlcnNpb25z
IGVhcmxpZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0aGFuIFRMUzwv
c3Bhbj4gMS4yLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+Tm90IHJlcXVpcmluZyBjbGllbnRzIHRv
IGluZGljYXRlIHRoZWlyIHN1cHBvcnQgZm9yPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu
c2VydCI+ICAgVExTIDEuMiBjaXBoZXIgc3VpdGVzIGV4Y2x1c2l2ZWx5IHRocm91Z2ggQ2xpZW50
SGVsbG8uY2xpZW50X2hlbGxvPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg
aW1wcm92ZXMgdGhlIGludGVyb3BlcmFiaWxpdHkgaW4gdGhlIGluc3RhbGxlZCBiYXNlIGFuZCB1
c2Ugb2YgVExTPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgMS4yIEFFQUQg
Y2lwaGVyIHN1aXRlcyB3aXRob3V0IHVwc2V0dGluZyB0aGUgaW5zdGFsbGVkIGJhc2Ugb2Y8L3Nw
YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB2ZXJzaW9uLWludG9sZXJhbnQgVExT
IHNlcnZlcnMsIHJlc3VsdHMgaW4gbW9yZSBUTFMgaGFuZHNoYWtlczwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz
cGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN1Y2NlZWRpbmcgYW5kIG9idmlhdGVzIGZhbGxiYWNrIG1l
Y2hhbmlzbXMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LiAgSUFO
QSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuICBJQU5B
IENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMg
ZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIG5ldyBjaXBoZXIgc3VpdGVzLCB3aG9zZSB2
YWx1ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRl
ZmluZXMgdGhlIGZvbGxvd2luZyBuZXcgY2lwaGVyIHN1aXRlcywgd2hvc2UgdmFsdWVzPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBoYXZlIGJlZW4gYXNzaWduZWQgaW4gdGhlIFRMUyBD
aXBoZXIgU3VpdGUgUmVnaXN0cnkgZGVmaW5lZCBieTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgIGhhdmUgYmVlbiBhc3NpZ25lZCBpbiB0aGUgVExTIENpcGhlciBTdWl0ZSBSZWdp
c3RyeSBkZWZpbmVkIGJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNTI0Nl0u
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzUyNDZdLjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9HQ01f
U0hBMjU2ICAgPSB7MHhUQkQ7IDB4VEJEfSB7MHhEMCwweDAxfTs8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9HQ01fU0hBMjU2ICAg
PSB7MHhUQkQ7IDB4VEJEfSB7MHhEMCwweDAxfTs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIFRMU19FQ0RIRV9QU0tfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQgICA9IHsweFRCRDsgMHhU
QkR9IHsweEQwLDB4MDJ9OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRMU19F
Q0RIRV9QU0tfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQgICA9IHsweFRCRDsgMHhUQkR9IHsweEQw
LDB4MDJ9OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVExTX0VDREhFX1BTS19XSVRI
X0FFU18xMjhfQ0NNXzhfU0hBMjU2ID0gezB4VEJEOyAweFRCRH0gezB4RDAsMHgwM307PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVExTX0VDREhFX1BTS19XSVRIX0FFU18xMjhf
Q0NNXzhfU0hBMjU2ID0gezB4VEJEOyAweFRCRH0gezB4RDAsMHgwM307PC90ZD48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9DQ01fU0hBMjU2ICAg
PSB7MHhUQkQ7IDB4VEJEfSB7MHhEMCwweDA1fTs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9DQ01fU0hBMjU2ICAgPSB7MHhUQkQ7
IDB4VEJEfSB7MHhEMCwweDA1fTs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
Tk9URSBUTyBUSEUgUkZDIEVESVRPUjogUExFQVNFIFJFTU9WRSBUSElTIFBBUkFHUkFQSC4gIFRo
ZSBjaXBoZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBOT1RFIFRPIFRIRSBS
RkMgRURJVE9SOiBQTEVBU0UgUkVNT1ZFIFRISVMgUEFSQUdSQVBILiAgVGhlIGNpcGhlcjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc3VpdGUgbnVtYmVycyBsaXN0ZWQgaW4gdGhlIGxh
c3QgY29sdW1uIGFyZSBudW1iZXJzIHVzZWQgZm9yIGNpcGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIHN1aXRlIG51bWJlcnMgbGlzdGVkIGluIHRoZSBsYXN0IGNvbHVtbiBh
cmUgbnVtYmVycyB1c2VkIGZvciBjaXBoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IHN1aXRlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhbmQgaXQncyBzdWdnZXN0ZWQgdGhhdCBJ
QU5BIHVzZSB0aGVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHN1aXRlIGlu
dGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhbmQgaXQncyBzdWdnZXN0ZWQgdGhhdCBJQU5BIHVzZSB0
aGVzZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdmFsdWVzIGZvciBhc3NpZ25tZW50
LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHZhbHVlcyBmb3IgYXNzaWdubWVu
dC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ni4gIFNlY3VyaXR5IENvbnNpZGVy
YXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIFNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBzZWN1cml0
eSBjb25zaWRlcmF0aW9ucyBpbiBUTFMgMS4yIFtSRkM1MjQ2XSwgRFRMUyAxLjIgW1JGQzYzNDdd
LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBzZWN1cml0eSBjb25zaWRl
cmF0aW9ucyBpbiBUTFMgMS4yIFtSRkM1MjQ2XSwgRFRMUyAxLjIgW1JGQzYzNDddLDwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMSI+PHRkPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs
b2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5QU0sgQ2lwaGVyc3VpdGVzIGZvcjwvc3Bhbj4g
VExTIDxzcGFuIGNsYXNzPSJkZWxldGUiPltSRkM0Mjc5XSw8L3NwYW4+IEVDREhFX1BTSyBbUkZD
NTQ4OV0sIEFFUy1HQ008L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVExTIDxz
cGFuIGNsYXNzPSJpbnNlcnQiPjEuMyBbSS1ELmlldGYtdGxzLXRsczEzXSw8L3NwYW4+IEVDREhF
X1BTSyBbUkZDNTQ4OV0sIEFFUy1HQ00gW1JGQzUyODhdLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj4gICBbUkZDNTI4OF0sIGFuZCBBRVMtQ0NNIFtSRkM2NjU1XSBhcHBseSB0byB0aGlz
IGRvY3VtZW50IGFzIHdlbGwuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFu
ZCBBRVMtQ0NNIFtSRkM2NjU1XSBhcHBseSB0byB0aGlzIGRvY3VtZW50IGFzIHdlbGwuPC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFsbCB0aGUgY2lwaGVyIHN1aXRlcyBkZWZp
bmVkIGluIHRoaXMgZG9jdW1lbnQgcHJvdmlkZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIEFsbCB0aGUgY2lwaGVyIHN1aXRlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgcHJv
dmlkZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29uZmlkZW50aWFsaXR5LCBtdXR1
YWwgYXV0aGVudGljYXRpb24sIGFuZCBmb3J3YXJkIHNlY3JlY3kuICBUaGU8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25maWRlbnRpYWxpdHksIG11dHVhbCBhdXRoZW50aWNh
dGlvbiwgYW5kIGZvcndhcmQgc2VjcmVjeS4gIFRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgQUVTLTEyOCBjaXBoZXIgc3VpdGVzIHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBhbmQg
dGhlIEFFUy0yNTYgY2lwaGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQUVT
LTEyOCBjaXBoZXIgc3VpdGVzIHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBhbmQgdGhlIEFFUy0y
NTYgY2lwaGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdWl0ZXMgcHJvdmlkZSBh
dCBsZWFzdCAxOTItYml0IHNlY3VyaXR5LiAgSG93ZXZlciwgQUVTXzEyOF9DQ01fODwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHN1aXRlcyBwcm92aWRlIGF0IGxlYXN0IDE5Mi1i
aXQgc2VjdXJpdHkuICBIb3dldmVyLCBBRVNfMTI4X0NDTV84PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBvbmx5IHByb3ZpZGVzIDY0LWJpdCBzZWN1cml0eSBhZ2FpbnN0IG1lc3NhZ2Ug
Zm9yZ2VyeS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvbmx5IHByb3ZpZGVz
IDY0LWJpdCBzZWN1cml0eSBhZ2FpbnN0IG1lc3NhZ2UgZm9yZ2VyeS48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMiI+PHRkPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2Vy
dCI+VXNlIG9mIFByZS1TaGFyZWQgS2V5cyBvZiBsaW1pdGVkIGVudHJvcHkgbWF5IGFsbG93IGFu
IGFjdGl2ZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGF0dGFja2VyIGF0
dGVtcHRzIHRvIGNvbm5lY3QgdG8gdGhlIHNlcnZlciBhbmQgdHJ5IGRpZmZlcmVudCBrZXlzLjwv
c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEZvciBleGFtcGxlLCBsaW1pdGVk
IGVudHJvcHkgbWF5IGJlIHByb3ZpZGVkIGJ5IHVzaW5nIGEgc2hvcnQgUFNLIGluPC9zcGFuPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd2hpY2ggY2FzZSBhbiBhdHRhY2tlciBtYXkg
cGVyZm9ybSBhIGJydXRlLWZvcmNlIGF0dGFjay4gIEFub3RoZXI8L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+
PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4gICBleGFtcGxlIGluY2x1ZGVzIHRoZSB1c2Ugb2YgYSBQU0sgY2hv
c2VuIGJ5IGEgaHVtYW4gd2hpY2ggdGh1cyBtYXkgYmU8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs
YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz
cz0iaW5zZXJ0Ij4gICBleHBvc2VkIHRvIGRpY3Rpb25hcnkgYXR0YWNrcy48L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgUHJl
LVNoYXJlZCBLZXlzIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uIE1VU1QgaGF2ZSBhIHNlY3VyaXR5
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIFByZS1TaGFyZWQgS2V5cyB1
c2VkIGZvciBhdXRoZW50aWNhdGlvbiBNVVNUIGhhdmUgYSBzZWN1cml0eTwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgbGV2ZWwgZXF1YWwgb3IgaGlnaGVyIHRoYW4gdGhlIGNpcGhlciBz
dWl0ZSB1c2VkLCBpLmUuLCBhdCBsZWFzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIGxldmVsIGVxdWFsIG9yIGhpZ2hlciB0aGFuIHRoZSBjaXBoZXIgc3VpdGUgdXNlZCwgaS5l
LiwgYXQgbGVhc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEyOC1iaXQgZm9yIHRo
ZSBBRVMtMTI4IGNpcGhlciBzdWl0ZXMgYW5kIGF0IGxlYXN0IDE5Mi1iaXQgZm9yIHRoZTwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEyOC1iaXQgZm9yIHRoZSBBRVMtMTI4IGNp
cGhlciBzdWl0ZXMgYW5kIGF0IGxlYXN0IDE5Mi1iaXQgZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgQUVTLTI1NiBjaXBoZXIgc3VpdGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIEFFUy0yNTYgY2lwaGVyIHN1aXRlcy48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgR0NNIG9yIENDTSBlbmNyeXB0aW9uIC0gZXZlbiBvZiBkaWZmZXJl
bnQgY2xlYXIgdGV4dCAtIHJlLXVzaW5nIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICBHQ00gb3IgQ0NNIGVuY3J5cHRpb24gLSBldmVuIG9mIGRpZmZlcmVudCBjbGVhciB0ZXh0
IC0gcmUtdXNpbmcgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm9uY2Ugd2l0aCBh
IHNhbWUga2V5IHVuZGVybWluZXMgdGhlIHNlY3VyaXR5IG9mIEdDTSBhbmQgQ0NNLiAgQXMgYTwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vbmNlIHdpdGggYSBzYW1lIGtleSB1
bmRlcm1pbmVzIHRoZSBzZWN1cml0eSBvZiBHQ00gYW5kIENDTS4gIEFzIGE8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIHJlc3VsdCwgR0NNIGFuZCBDQ00gTVVTVCBvbmx5IGJlIHVzZWQg
d2l0aCBhIHN5c3RlbSBndWFyYW50ZWVpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4gICByZXN1bHQsIEdDTSBhbmQgQ0NNIE1VU1Qgb25seSBiZSB1c2VkIHdpdGggYSBzeXN0ZW0g
Z3VhcmFudGVlaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBub25jZSB1bmlxdWVu
ZXNzIFtSRkM1MTE2XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub25jZSB1
bmlxdWVuZXNzIFtSRkM1MTE2XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90
cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2Nv
bG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNo
YW5nZXMuIDEyIGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0i
c3RhdHMiPjx0ZD48L3RkPjx0aD48aT4zMyBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90
aD48dGg+PGk+IDwvaT48L3RoPjx0aD48aT41NiBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwv
dGg+PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIi
IGNsYXNzPSJzbWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlm
ZiAxLjQ1LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0
cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRm
Lm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+
CiAgIDwvaHRtbD4K
--001a11412d3c6a2d4705503bdba6--


From nobody Wed May 24 13:13:34 2017
Return-Path: 
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 605FA127B52; Wed, 24 May 2017 13:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wBs26BcO8OtJ; Wed, 24 May 2017 13:13:26 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B710127419; Wed, 24 May 2017 13:13:25 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id a5so60104669lfh.2; Wed, 24 May 2017 13:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zp1eUfJVsE6CUyxmP97ocD/AKZ8W9acSn41sZy5nRc8=; b=JF6V58o0/Jo7+fPTgmqmBGWvENBxJ3wAPHPzmcugYM1uTDGS7wUVjOdIZIOwja60uO EV7DQChpmSpdEnvCjtzzryIj3rvHHSsXtH0d9VAsbRu1fcA4QZfOjC7LfscoqEPQz50D GuHIfALdcz+Qeg5wQnrFdPP/ucRW3pCerU9Bodx1LB/63q6RJmrPw80itKWRihuAICQF kpE5o1LHdnQAikvuJ+G8kBxWHbj8GuHrJNWuRIUfU5zCMYaL0qjwf90pSc9jl7bZW6PF 8hGyHZZ1zb0tv2vT5v1U1CJw8k0CuoXywBiORPc7VPzjkWKssMdU1k4cGKa9URbb5OI0 Rh1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zp1eUfJVsE6CUyxmP97ocD/AKZ8W9acSn41sZy5nRc8=; b=K1vEVFP6PM+oOlOj/a5tXwW8wu+qfb+kVlfnarCl4A2r+/qBFaIkFDq09GbrlN4diR O/GWAW9o/vYuzWDBQWotWveP3YWeA4j7NH05umCEtQjZFdIsBqAYoP+bBCFPkSz9Eqml rKMXXJO5vhwYT2m4Ur/qnaCTmdaaUap7tS8N4VtWXrvrL4AV7QCO7bkZ87cFuqE6jlRK 5tj6+Exf+AV6jNpk0KJ1FPv6wqI1RhaW3yYSFoB34HtZTgv3SALT6/C8u9IhbyMCXlwg Pky8LN/vbZoMn/X6KtoSaYwveUVZ16jdTK7++kOLfCRQQKhGJczQpe6mLr1yFZWW9t1Z Q9NQ==
X-Gm-Message-State: AODbwcD4jGfJbFFWd5DRXO0bpQieEsVMAihOnkAuL5Iru1NOwH51HcCn 3o37/yA8iC7rVVW7GtHT1ZFs2Z/nmg==
X-Received: by 10.25.215.198 with SMTP id q67mr8964367lfi.76.1495656803706; Wed, 24 May 2017 13:13:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Wed, 24 May 2017 13:13:23 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>      
From: Martin Thomson 
Date: Thu, 25 May 2017 06:13:23 +1000
Message-ID: 
To: Daniel Migault 
Cc: Eric Rescorla , tls-chairs , The IESG ,  tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 20:13:27 -0000

On 25 May 2017 at 00:04, Daniel Migault  wrote:

> B) It is not true as TLS1.3 enables these cipher suites to be negotiated
> with TLS1.3.

You can't negotiate the new suites with 1.3, but you can offer them in
case the server picks 1.2.

Joe's proposal fixes this and other errors.


>> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>> means to use AEAD_AES_128_GCM (and the same for the other
>> ciphersuites).  I mention this because the order in which the AEAD
>> algorithms are mentioned is different to the order of the ciphersuites
>> in the list.
>>
>
> Unless I miss your comment, I believe the section 3 already addresses it. If
> not please let me knoe what text you would like to see.
>
> """
> 3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites
>
>    The cipher suites defined in this document are based on the AES-GCM
>    and AES-CCM Authenticated Encryption with Associated Data (AEAD)
>    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
>    defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].
>
> """

You miss my comment.  This does not prevent someone from deciding that
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 should use AEAD_AES_128_CCM_8.


From nobody Wed May 24 13:50:03 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F7D127B52; Wed, 24 May 2017 13:49:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins 
To: "The IESG" 
Cc: draft-ietf-tls-ecdhe-psk-aead@ietf.org, Joseph Salowey ,  tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149565899558.8677.16612425338646271478.idtracker@ietfa.amsl.com>
Date: Wed, 24 May 2017 13:49:55 -0700
Archived-At: 
Subject: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 24 May 2017 20:49:56 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Ciphersuite drafts for TLS are usually above my pay grade, but I
understand most of EKR's Discuss, and agree with Adam's suggestion to
change the document title to "ECDHE_PSK with AES-GCM and AES-CCM Cipher
Suites for Transport Layer Security Version 1.2 (TLS 1.2)" at an absolute
minimum.



From nobody Wed May 24 14:04:03 2017
Return-Path: 
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 26037129BBD; Wed, 24 May 2017 14:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ihDx9xlU5S6q; Wed, 24 May 2017 14:03:52 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FF7128854; Wed, 24 May 2017 14:03:52 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id m17so146669358pfg.3; Wed, 24 May 2017 14:03:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vziskLflKXcg7kHgF+tbm1oRoyl8H6HPrudVF5wDbG0=; b=C8T1KNlq1pOwnN4G4gF+ugH/fDpesByHAbTcBtW9XY4dMoL6M7/1Hycybamh3fyeC4 xCNQWPEgtT/Qsv10Y5aB+BAicG+eqEUbTuxS7S4z7ziI/u2xLSs2tgyZ3blFfHvnSGe0 e4o0Y6r8XoyM30DBlLcUlBsimZPygTsXzkFGNvtVQiiHqzq8YuBx8oQBrhK6dKr5J0Ka 29Mi027Pqxb1HhVboy1rPL3YopgaYT1bhLGNhdq9Qb7OTh+RKnoR6kie6OhcnycyDYAh jYlZ486vqRCB9RgONZ9jxNCBV6M4NLtRctdX43JnFBweaSvx5LhAnV5ex1f2eOUpuqD9 uV8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vziskLflKXcg7kHgF+tbm1oRoyl8H6HPrudVF5wDbG0=; b=jGYoAhlXmglqf89qta/Stnc9wRjc4Dk4YXMyds0Aaqkmxtkdz0YK2CZ9qnvt5i8Fmh MJr6H814ZSAzVab0k2CQmEqg2+FU4IptXtVl4tWlWDa7d1QE3rScENrIBqx0bTtevhoL riyXE4slfljrnpzcnKIb/lTJMruXYeyL018MJwP7UL0GXG09i/tmM/yZRwql4gJYb1OI Yzu9M7QAbfM8H1hmop5+M6TuhgSny7T6JLr0Asvdo3Ydct4RtNPnaXiDnhw7u0l0IWS9 1oKr0yVCTl3FJQuJGNa62xDuwbxrhWL9uxMaJkDKVmvvyxCDJ5g7w7eOfMqbUIIsX7wz PMaA==
X-Gm-Message-State: AODbwcDjd/ZRcGOPyuXuI+1Hv7sL2R/GIiB7UuVwzQJ434AQ2LPW7+jv Tj+yt0/CHIEzk8TVHpY9p4ufGmBkuQ==
X-Received: by 10.98.86.207 with SMTP id h76mr39764784pfj.205.1495659831893; Wed, 24 May 2017 14:03:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Wed, 24 May 2017 14:03:11 -0700 (PDT)
In-Reply-To: <149565899558.8677.16612425338646271478.idtracker@ietfa.amsl.com>
References: <149565899558.8677.16612425338646271478.idtracker@ietfa.amsl.com>
From: Kathleen Moriarty 
Date: Wed, 24 May 2017 17:03:11 -0400
Message-ID: 
To: Spencer Dawkins 
Cc: The IESG , "" , "joe@salowey.net" ,  tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:03:54 -0000

On Wed, May 24, 2017 at 4:49 PM, Spencer Dawkins
 wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Ciphersuite drafts for TLS are usually above my pay grade, but I
> understand most of EKR's Discuss, and agree with Adam's suggestion to
> change the document title to "ECDHE_PSK with AES-GCM and AES-CCM Cipher
> Suites for Transport Layer Security Version 1.2 (TLS 1.2)" at an absolute
> minimum.

The shepherd proposed a resolution that should clear up the discuss points.
>
>



-- 

Best regards,
Kathleen


From nobody Wed May 24 14:15:29 2017
Return-Path: 
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 6693C129BC5 for ; Wed, 24 May 2017 14:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 kJ8MssChY-bu for ; Wed, 24 May 2017 14:15:26 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D009129BF5 for ; Wed, 24 May 2017 14:14:47 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id m17so146886357pfg.3 for ; Wed, 24 May 2017 14:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z6399RzuEoikphWuuRPk9dFRuP8cJ/5C0bKIR3vPf4c=; b=13zApcBIRHL4xfJJXVavT43R0UAg6HHoX0EDQXViD4+8Xc/LROYugb2n2Yt633xaTg y4lPPr7cFUa5uNmOHAgQ0+dYvcaOsjbMIKsRRUM9eGoTWZ1xp50CAwQ/Cwk56mG8dxGg NuKysXHqHjOGsUlTIb+/8w1/tbd7hxW5i43vdqmd8syREMzKc9wExjrqALNoE+nVD4ZG ZCoXsngAfcrf5qTYwUxizk0VVhmdxpdXXLb40B0ohUIeHIdn0JNhs9Jcr93jVsKXXYpp dep8pbwniXjXSxZaOBuELGH+0AkxLhg8pyUoXO78InCd2v7Cr8QLLfff4rHBwrX+Hx6h IUjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z6399RzuEoikphWuuRPk9dFRuP8cJ/5C0bKIR3vPf4c=; b=YPi1igU2cK1bdQJR/c/oIzCOJ04PnK7IONUJRE7dbIdMRHhdQwN6DL5+e8N6HvZBwa sdxlB5pPU5TrdNfZ8Bh5B7Nu0/YU2vxUZOBPK5hlc/1U/zMIe1mNci7zaVAYD1piz2Ao Li3iDLVFyvghFcuWtpX2A5auw1J63RymKc+CBvsTHH8OoLdLB+NesBFK5V2GTHkvXFvC LZVzjyV2oM2ThZwdB3XqXEfVTUVeu8WPkrdqEKcrXBGdNLERVp8MUNG2eBG0vxNWxOon CmVo5R+psRw3qKwTE6HKkDbBBaailknW0kR0s2F+gzw0TGr+CTgQrm4YXXz7gvMtaid/ RaVA==
X-Gm-Message-State: AODbwcAcOtirxtES+UqjVcPWTD44tSYz90QX53QaElJumjBBx0qZHHFd LOk9JYuLfDLGqspL6K0RC3B4NqPDCUu4
X-Received: by 10.84.229.79 with SMTP id d15mr45861443pln.93.1495660486893; Wed, 24 May 2017 14:14:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.177.204 with HTTP; Wed, 24 May 2017 14:14:26 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>       
From: Joseph Salowey 
Date: Wed, 24 May 2017 14:14:26 -0700
Message-ID: 
To: Martin Thomson 
Cc: Daniel Migault , Eric Rescorla , tls-chairs , The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c19ecb406b2a705504b980e"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:15:28 -0000

--94eb2c19ecb406b2a705504b980e
Content-Type: text/plain; charset="UTF-8"

On Wed, May 24, 2017 at 1:13 PM, Martin Thomson 
wrote:

> On 25 May 2017 at 00:04, Daniel Migault 
> wrote:
>
> > B) It is not true as TLS1.3 enables these cipher suites to be negotiated
> > with TLS1.3.
>
> You can't negotiate the new suites with 1.3, but you can offer them in
> case the server picks 1.2.
>
> Joe's proposal fixes this and other errors.
>
>
> >> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
> >> means to use AEAD_AES_128_GCM (and the same for the other
> >> ciphersuites).  I mention this because the order in which the AEAD
> >> algorithms are mentioned is different to the order of the ciphersuites
> >> in the list.
> >>
> >
> > Unless I miss your comment, I believe the section 3 already addresses
> it. If
> > not please let me knoe what text you would like to see.
> >
> > """
> > 3.  ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites
> >
> >    The cipher suites defined in this document are based on the AES-GCM
> >    and AES-CCM Authenticated Encryption with Associated Data (AEAD)
> >    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
> >    defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].
> >
> > """
>
> You miss my comment.  This does not prevent someone from deciding that
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 should use AEAD_AES_128_CCM_8.
>

[Joe] It seems that a reasonable interpretation of the text is that the
AEAD constructs will pair with the cipher suite that share the same name.
Do you still think we need to provide an explicit mapping between the two?

--94eb2c19ecb406b2a705504b980e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, May 24, 2017 at 1:13 PM, Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:
On 25 May 2017 at 00:04, Daniel Migault <daniel.migault@ericsson.com> wrote:



> B) It is not true as TLS1.3 enables these cipher suites to be negotiat=
ed

> with TLS1.3.



You can't negotiate the new suites with 1.3, but you can offer t=
hem in

case the server picks 1.2.



Joe's proposal fixes this and other errors.





>> You don't anywhere state that TLS_ECDHE_PSK_WITH_AES_128_=
GCM_SHA256

>> means to use AEAD_AES_128_GCM (and the same for the other

>> ciphersuites).=C2=A0 I mention this because the order in which the=
 AEAD

>> algorithms are mentioned is different to the order of the ciphersu=
ites

>> in the list.

>>

>

> Unless I miss your comment, I believe the section 3 already addresses =
it. If

> not please let me knoe what text you would like to see.

>

> """

> 3.=C2=A0 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites

>

>=C2=A0 =C2=A0 The cipher suites defined in this document are based on t=
he AES-GCM

>=C2=A0 =C2=A0 and AES-CCM Authenticated Encryption with Associated Data=
 (AEAD)

>=C2=A0 =C2=A0 algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AE=
S_128_CCM

>=C2=A0 =C2=A0 defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [=
RFC6655].

>

> """



You miss my comment.=C2=A0 This does not prevent someone from decidi=
ng that

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 should use AEAD_AES_128_CCM_8.


[Joe] It seems that=
 a reasonable interpretation of the text is that the AEAD constructs will p=
air with the cipher suite that share the same name.=C2=A0 Do you still thin=
k we need to provide an explicit mapping between the two?=C2=A0



--94eb2c19ecb406b2a705504b980e--


From nobody Wed May 24 14:24:23 2017
Return-Path: 
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 8FF0B128792; Wed, 24 May 2017 14:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1SxQjbTnFvaF; Wed, 24 May 2017 14:24:21 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1903412778E; Wed, 24 May 2017 14:24:21 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id h4so74452785lfj.3; Wed, 24 May 2017 14:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iMJfI+wIghYuiUcY/I4Ce2l8JXSLHzv6f0r1YFb3Lps=; b=CvWD7iIOqk3QxAxRt8UFCLCWfMU307cC2L2+QmYEyZRYNlgrq5LL2s/joptPNErgAT ZgMava6UlnuBcEy97BB78zXLA1vAW3Yb5HhVul1S0zff/MwBcl6JdKo4Wrg63hPHaUd2 OYANAnBIye5E65Ok0fwpmT1qREFx2NvUQBFCwIKs1m1r7vg2urkEjpyZWlVFtph+nE3Z ge/b40/VBYgofPpmFruSKUS2efykVjZqmTQxae6a1qdMjFqFRqvOkg4KaizxZF3gkg+u srgkYE4us0T/dmpKng4XBA/JJiYvtsPFBaokqgHOVJU6ZL9umeTRpPauGCFZEW+1nOAy InKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iMJfI+wIghYuiUcY/I4Ce2l8JXSLHzv6f0r1YFb3Lps=; b=mZtH58nV25P5Hgji27GTZRHS7not8Utczv4vkzZULdncA3+l2nfa5lBJZIjw1wQvwf 30+Ym97HMM15e8e1fiVF4VESfhuczIch69PNcqs5A8l5YldXjtvdwkZDp6gvCMsOwoKu TjaQ7/bEr0maoy6J4SW8cooENSYWabeBp3gwGyOdFM9Ida8YtDeN9QD2viNvFl7wkf0s GkUqfNaD2ijdkmNRI4K8/daDG4ggbi0Hjgc4DNQgJio4V1ZgwQQz2EAw3c2HZ76GYmCm 7GSVsD/CNmtu4sHkRGIZPdqhtOxqlCO3FGMqmnOlxrhrrcrPro0uDTI/oK0udIXBhxgX r/7g==
X-Gm-Message-State: AODbwcCasMJjOEUlsnPQiR2pD67fZIXDfzh7ztjI3+69Y4iFLvuvMFAV OLnTPR1gU1ilXb2aXiK+DxNJCwwC0Q==
X-Received: by 10.25.148.20 with SMTP id w20mr9957011lfd.169.1495661059159; Wed, 24 May 2017 14:24:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Wed, 24 May 2017 14:24:18 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>        
From: Martin Thomson 
Date: Thu, 25 May 2017 07:24:18 +1000
Message-ID: 
To: Joseph Salowey 
Cc: Daniel Migault , Eric Rescorla , tls-chairs , The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:24:22 -0000

On 25 May 2017 at 07:14, Joseph Salowey  wrote:
> [Joe] It seems that a reasonable interpretation of the text is that the AEAD
> constructs will pair with the cipher suite that share the same name.  Do you
> still think we need to provide an explicit mapping between the two?


Reasonable, sure, even obvious.  I've learned that reasonable doesn't
work always.  Note that the order that the AEADs are listed doesn't
match the order of the cipher suites.


From nobody Wed May 24 14:29:57 2017
Return-Path: 
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 301DD129BC6 for ; Wed, 24 May 2017 14:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 OJ_rxOCsBrON for ; Wed, 24 May 2017 14:29:54 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B02129BE8 for ; Wed, 24 May 2017 14:29:54 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id 9so147121440pfj.1 for ; Wed, 24 May 2017 14:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OByUJjmambhY4FaX9+dd+LdXW9Wee+F+eutB8WdeKm8=; b=f/N2IpNstluv+IFGqvRakdXcHUjJmH265khUY1ctLziolpaL8kI5I6SUuWqemZNIRf njMAsW97Vh6buqBJtRIgiPWXoopOAjktCnKdAcH9OEAuxA624KT2hbQApGThgd1EcvNb ZCBXKCRcloath+eAPYTkgJn7VjEARaEIkyFvjY47s07LmKYRRMaZTJzJsfsA07gJphHC gsbf2y7u7wdGUGHvgGwkxUe0kQxlQrQxfu276UpkoUJcArHlOOwEMsytJ9nl++8KFfBK YYqF6XHFarBKn6XY59Mq4XTMnoo0aQls1WIbfo69vcG7WBaf3whXte1RWQDKs4J+aiWJ wq0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OByUJjmambhY4FaX9+dd+LdXW9Wee+F+eutB8WdeKm8=; b=cFB3mixWL40LkXkM+mWxfWXnsJRusgavNv8Ut8EaDDHwSyiJWtBXeJEZbZDypgccPV CIe7DkWyBvc8yfg7qUXUHz0egV7IeHpIBVBbxkVidhP2m47qdSs7RciFtbo0XxvL/T6y YFeOZ58GT6AY9+Pogpw5qmFfCippNJd9LHIHxM/4LanpDKieWLQiwPeAsW5+c1/gVm/E ymedBgi1pLw6580ihfIGwfCp1SJHdMBCu3KRLc1L3KedB/49gQU4NLqE2Ku5KHI8FJEb 3+XjlpIV9sb68G5839s2rA+WzTFOH+gB8MwjApHOcCx5GaOz0+IyasodGSv5bbJQB6+h zFMA==
X-Gm-Message-State: AODbwcBlStl9DGHKpbwJOYkw8VGlVdMS9z/UjILf4kYAA7UOc68CaIPC OoAVFEw4fOb4I4ffmFdWuCSiCztMG63G
X-Received: by 10.98.216.198 with SMTP id e189mr40511431pfg.61.1495661393681;  Wed, 24 May 2017 14:29:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.177.204 with HTTP; Wed, 24 May 2017 14:29:33 -0700 (PDT)
In-Reply-To: <34EDA6D1-71BA-4E4C-BB9F-5E8FD05786D9@cooperw.in>
References: <149523380739.28567.9584998643479497589@ietfa.amsl.com> <34EDA6D1-71BA-4E4C-BB9F-5E8FD05786D9@cooperw.in>
From: Joseph Salowey 
Date: Wed, 24 May 2017 14:29:33 -0700
Message-ID: 
To: Alissa Cooper 
Cc: Dan Romascanu ,  "gen-art >> General area reviewing team" , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1149494a13323c05504bcecb"
Archived-At: 
Subject: Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:29:56 -0000

--001a1149494a13323c05504bcecb
Content-Type: text/plain; charset="UTF-8"

Hi Dan and Alissa,

There has been some churn in the text of the document due to my oversight
when sending the document to the IESG.   The proposed new text provided
below show should also resolve your comment.  Please let me know if you see
any issues with this approach.

Thanks,

Joe

Replacing section 4:


   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].




On Wed, May 24, 2017 at 8:15 AM, Alissa Cooper  wrote:

> Dan, thank you for your reviews of this document and thanks to the authors
> for providing clarifications. I have balloted No Objection.
>
> Alissa
>
> > On May 19, 2017, at 6:43 PM, Dan Romascanu  wrote:
> >
> > Reviewer: Dan Romascanu
> > Review result: Ready
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair. Please wait for direction from your
> > document shepherd or AD before posting a new version of the draft.
> >
> > For more information, please see the FAQ at
> >
> > .
> >
> > Document: draft-ietf-tls-ecdhe-psk-aead-??
> > Reviewer: Dan Romascanu
> > Review Date: 2017-05-19
> > IETF LC End Date: 2017-05-18
> > IESG Telechat date: 2017-05-25
> >
> > Summary:
> >
> > This is a straight-forward and clear document that defines several new
> > cipher suites for the Transport Layer Security (TLS) protocol version
> > 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> > with Pre-Shared Key (ECDHE_PSK) key exchange together with the
> > Authenticated Encryption with Associated Data (AEAD) algorithms
> > AES-GCM and AES-CCM. The document is well written and I appreciate the
> > effort to clarify in the Introduction the context, what was missing,
> > and why the document is necessary. One issue raised in my initial
> > review for draft-03 was addressed, discussed and draft-04 includes
> > useful clarification text.
> >
> > The document is Ready
> >
> > Major issues:
> >
> > Minor issues:
> >
> > Nits/editorial comments:
> >
> >
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
>
>

--001a1149494a13323c05504bcecb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dan and Alissa,

There has been some =
churn in the text of the document due to my oversight when sending the docu=
ment to the IESG. =C2=A0 The proposed new text provided below show should a=
lso resolve your comment.=C2=A0 Please let me know if you see any issues wi=
th this approach. =C2=A0

Thanks,

Joe

Replac=
ing section 4:
 =20
   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].
<=
/div>


<=
br>
On Wed, May 24, 2017 at 8:15 AM, Alissa Coope=
r <alissa@cooperw.in> wrote:
Dan, thank you for your reviews of this document and thanks to the autho=
rs for providing clarifications. I have balloted No Objection.



Alissa




> On May 19, 2017, at 6:43 PM, Dan Romascanu <dromasca@gmail.com> wrote:

>

> Reviewer: Dan Romascanu

> Review result: Ready

>

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed

> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.

>

> For more information, please see the FAQ at

>

> <https://trac.ietf.org/trac/gen/wiki/GenAr=
tfaq>.

>

> Document: draft-ietf-tls-ecdhe-psk-aead-??

> Reviewer: Dan Romascanu

> Review Date: 2017-05-19

> IETF LC End Date: 2017-05-18

> IESG Telechat date: 2017-05-25

>

> Summary:

>

> This is a straight-forward and clear document that defines several new=


> cipher suites for the Transport Layer Security (TLS) protocol version<=
br>
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> with Pre-Shared Key (ECDHE_PSK) key exchange together with the

> Authenticated Encryption with Associated Data (AEAD) algorithms

> AES-GCM and AES-CCM. The document is well written and I appreciate the=


> effort to clarify in the Introduction the context, what was missing,
> and why the document is necessary. One issue raised in my initial

> review for draft-03 was addressed, discussed and draft-04 includes

> useful clarification text.

>

> The document is Ready

>

> Major issues:

>

> Minor issues:

>

> Nits/editorial comments:

>

>


> _______________________________________________

> Gen-art mailing list

> Gen-art@ietf.org

> https://www.ietf.org/mailman/listinfo/gen-art=








--001a1149494a13323c05504bcecb--


From nobody Wed May 24 14:43:19 2017
Return-Path: 
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 ED4BB129BF2; Wed, 24 May 2017 14:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1rSzhkuQcWlB; Wed, 24 May 2017 14:43:08 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BA3129BC6; Wed, 24 May 2017 14:43:08 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id a5so61122791lfh.2; Wed, 24 May 2017 14:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WF2P3cM/JNWkRljBu2JhCSVCjFUVxmOUBGWGaT8uXMA=; b=vHiSU7IwDZmm70+WbM0vJqFeCSOR5RGBpfxzYEJbzwsqXcWiq64HdeXy9mdtz/Apo/ FAOkIDE+3yZl52Tyhe2n/eqG4qzDLs4bqBdR7DdAfABY9tvo8GoJ/l0XH+FhpFMqbkDD jYhFmFKsZ2j0i8vJ9BSIlWVByrGXSuGAAEVG6aCFH3TbTyFWhnPQbk7DJg9WBo83XcFS 8682QbTeE4Up7n5MEgfT89FoTALmLvD1XGNfilUhG2dcolZPmZ6CxPKE72KBi+DYPYrS FliVsoxu1x6uPBei2HcEcKdPy3R93eKhGG90iCVSeFOu/9ej9sG9wGg2nKLdtzHtQntc R9HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WF2P3cM/JNWkRljBu2JhCSVCjFUVxmOUBGWGaT8uXMA=; b=HF4a9XV+RR/DCdLuwu2XikSTQcUIWiUOMYRsfnR3+/2FcOonZFZh6zGTATQejcAPxm 9QTBOovyVtyqV8eChExkWOsZyjR5+4bCfG0SpAvqWxL6BQzxN7yZuuylMVtCKM/n+uMr QRo+nAyeme0BfZNFyXny/usYYWfDyHPVr2gfS9G5vwR5Tpfl1v0iZPNMTk6+hPlcEI0l b4P70i+28Yy2Na8MWjrbRrOs7VRmlknVyqrZZZkwivIYa9QJpMyXr1sgbQ8a/n9n6nSS Qno+4Dl8H13l+3m3VMxot4n6gk1M5WxzojJqTlCOysPyHc+kqj31sezAvdhCOrDekRuX O2hw==
X-Gm-Message-State: AODbwcD8dUrDM3gxv5KzuWZVrgN9KIwvUpKMr3q7FTpdJUBAgkl/YYZL dgfm7vR69IS9u7VLIVkrs6sE3qKe3Q==
X-Received: by 10.25.104.5 with SMTP id d5mr11066049lfc.147.1495662186573; Wed, 24 May 2017 14:43:06 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Wed, 24 May 2017 14:43:05 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>         
From: Daniel Migault 
Date: Wed, 24 May 2017 16:43:05 -0500
X-Google-Sender-Auth: Vno7-A--hyFZ7_nx_0PMQQoDAXE
Message-ID: 
To: Martin Thomson 
Cc: Joseph Salowey , Eric Rescorla , tls-chairs ,  The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="f403045e589c55b28c05504bfdd0"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:43:10 -0000

--f403045e589c55b28c05504bfdd0
Content-Type: text/plain; charset="UTF-8"

>From your response I understand you do not request changes.
Yours,
Daniel

On Wed, May 24, 2017 at 4:24 PM, Martin Thomson 
wrote:

> On 25 May 2017 at 07:14, Joseph Salowey  wrote:
> > [Joe] It seems that a reasonable interpretation of the text is that the
> AEAD
> > constructs will pair with the cipher suite that share the same name.  Do
> you
> > still think we need to provide an explicit mapping between the two?
>
>
> Reasonable, sure, even obvious.  I've learned that reasonable doesn't
> work always.  Note that the order that the AEADs are listed doesn't
> match the order of the cipher suites.
>

--f403045e589c55b28c05504bfdd0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


From your response I understand you do not reque=
st changes. 
Yours, 
Daniel 

On Wed, May 24, 2017 at 4:24 PM, Mar=
tin Thomson <martin.thomson@gmail.com> wrote:
On 25 May 2017 at 07:14, Joseph=
 Salowey <joe@salowey.net> wro=
te:

> [Joe] It seems that a reasonable interpretation of the text is that th=
e AEAD

> constructs will pair with the cipher suite that share the same name.=
=C2=A0 Do you

> still think we need to provide an explicit mapping between the two?




Reasonable, sure, even obvious.=C2=A0 I've learned that reasonab=
le doesn't

work always.=C2=A0 Note that the order that the AEADs are listed doesn'=
t

match the order of the cipher suites.





--f403045e589c55b28c05504bfdd0--


From nobody Wed May 24 14:55:13 2017
Return-Path: 
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 1A423129B9C; Wed, 24 May 2017 14:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 m1axPg2-ONuc; Wed, 24 May 2017 14:55:02 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABA2128CFF; Wed, 24 May 2017 14:55:02 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id 99so74562412lfu.1; Wed, 24 May 2017 14:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4xeegoPaUqlKzclUd3Aha2fIOP/uvmB7FGY2SKCQOwY=; b=no5aj0k5Xy37JgLmGKMQGTP9ANYZC78mF6N46xOW1FoDuF3/k5WKcUCRQ8Vz9cQfhI i/QR2wtxPzueGqjIr1NmqOV1j9qtgEtn/q6hsLs7TiWJ+cgke9rIld2FAMaCsTeHOGos zayAM3lGmHq6NnwpsvBC6im4KWvGaRcc9gHI9W/q6eOJDF8EovUIM3ygJSdtWhaFt+SF 30OrjG45XHJsK9zmKxaJ+1URI88BZFC0JgYtoUOtl1pEdwcYHnx/20HSgqFUun6zhq9W 27XMpXe4TdfJRxBCwZqN6nvG50AVAH7Dwhcwsn3WBagewAiQjay4DDSGO/g4KALjWcNH ktDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4xeegoPaUqlKzclUd3Aha2fIOP/uvmB7FGY2SKCQOwY=; b=r9BfgF8sEbzhXkDuWdQ9NC7z7AoBpYo7BBrO2u6i4RlVVeRNKOkxMJ8JI6xZHKq17R TjkrrXdFloOpuhlRLSKsApd9KTMv09oL8lx9CO3l/XHPABi+kUwDJ7jdN8Zy8K5UH9Zp 2sauw4bHvSsrgNuoatWA9cp7pivZxS7fT1pEWXJnGRsHStR/SmdA13udrZ1DxFj0WJ1z o7wyqAnZHuoNoCfJSg9YDaoK8EV+bvTvp8KuWgrI78UeYElLQ19QlsparnvAd9Nr9Slx AIM6tPGNBmLpQtbZLH323i+Zu2xpHdH+TESQvnycc1+TdemIXo0FUXAAbh4wj54Pwpze cQ5g==
X-Gm-Message-State: AODbwcAvA3p74vGcj0bnNrThlbZWdG0116IRCBz5veVgfcPN6hVqLATr T6QqdplyrZZa8bu+CNoLCYWyq4xg2w==
X-Received: by 10.46.76.1 with SMTP id z1mr9311014lja.128.1495662900462; Wed, 24 May 2017 14:55:00 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Wed, 24 May 2017 14:54:59 -0700 (PDT)
In-Reply-To: 
References: <149565899558.8677.16612425338646271478.idtracker@ietfa.amsl.com> 
From: Daniel Migault 
Date: Wed, 24 May 2017 16:54:59 -0500
X-Google-Sender-Auth: BbZAkHMqXmNmZhIdNPFXhy4Y6uw
Message-ID: 
To: Kathleen Moriarty 
Cc: Spencer Dawkins , The IESG ,  "" , "joe@salowey.net" , tls-chairs , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="f403045ea6dae2ca8205504c276c"
Archived-At: 
Subject: Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:55:04 -0000

--f403045ea6dae2ca8205504c276c
Content-Type: text/plain; charset="UTF-8"

Thanks Spencer for your review. Actually the scope has always been TLS1.2
only. I confirm version 05 have addressed Erik's comments.
Yours,
Daniel

On Wed, May 24, 2017 at 4:03 PM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> On Wed, May 24, 2017 at 4:49 PM, Spencer Dawkins
>  wrote:
> > Spencer Dawkins has entered the following ballot position for
> > draft-ietf-tls-ecdhe-psk-aead-04: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Ciphersuite drafts for TLS are usually above my pay grade, but I
> > understand most of EKR's Discuss, and agree with Adam's suggestion to
> > change the document title to "ECDHE_PSK with AES-GCM and AES-CCM Cipher
> > Suites for Transport Layer Security Version 1.2 (TLS 1.2)" at an absolute
> > minimum.
>
> The shepherd proposed a resolution that should clear up the discuss points.
> >
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>

--f403045ea6dae2ca8205504c276c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Spencer for your review. Actually the sco=
pe has always been TLS1.2 only. I confirm version 05 have addressed Erik=
9;s comments. 
Yours, 
Daniel=C2=A0 

On Wed, May 24, 2017 at 4:0=
3 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
On Wed, May 24, 2017 at 4:49 PM, Spencer Dawkins

<spencerdawkins.ietf@gm=
ail.com> wrote:

> Spencer Dawkins has entered the following ballot position for

> draft-ietf-tls-ecdhe-psk-aead-04: No Objection

>

> When responding, please keep the subject line intact and reply to all<=
br>
> email addresses included in the To and CC lines. (Feel free to cut thi=
s

> introductory paragraph, however.)

>

>

> Please refer to https://www.ietf.org/i=
esg/statement/discuss-criteria.html

> for more information about IESG DISCUSS and COMMENT positions.

>

>

> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

>

>

>

> ------------------------------------------------------------=
----------

> COMMENT:

> ------------------------------------------------------------=
----------

>

> Ciphersuite drafts for TLS are usually above my pay grade, but I

> understand most of EKR's Discuss, and agree with Adam's sugges=
tion to

> change the document title to "ECDHE_PSK with AES-GCM and AES-CCM =
Cipher

> Suites for Transport Layer Security Version 1.2 (TLS 1.2)" at an =
absolute

> minimum.




The shepherd proposed a resolution that should clear up the dis=
cuss points.

>

>







--



Best regards,

Kathleen





--f403045ea6dae2ca8205504c276c--


From nobody Wed May 24 15:06:06 2017
Return-Path: 
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 8E5DA1287A7; Wed, 24 May 2017 15:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HE_5z2MVLzqk; Wed, 24 May 2017 15:05:55 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66825126CF9; Wed, 24 May 2017 15:05:55 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id k74so165410023qke.1; Wed, 24 May 2017 15:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V3bEJVmTghW+X6rgS+l/oQtoc9hbwKmIv0x1WHMkA9g=; b=f0XEM30GQLjMHLS1ZhBcVI2KA/sEiIQbxkfLWpxGQ0Sbj7kzxAOzWKNLyMyO9MKgQ9 llwrg0X52bwC8uKIbedyqWAnn3DS3ZagRzvSmBtKSfPRA93GaTUsmsxTKq+l1/4vSah+ sJahUIC1bQpQkhiLUqne5P3scVKwuMagUcpI2/2touj7BJHzf2nd5+RMyKne6RFBL/Hv L/Xzg8aP1W+h52hR9tWstpwyrtEjbiwi9hu0heFgE0jtQ7p8fKIbdKsLW/yHRcMuni+h J8dXzJNq/63TZkpBZPhB64RdNfOufJa/OVsVwZqk5z/04R4YLhrYfrNs/S9mf8lRa3oM YzJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V3bEJVmTghW+X6rgS+l/oQtoc9hbwKmIv0x1WHMkA9g=; b=JdrtUcoWlhRr8hKRgOhK6uFu28Bj3M3Tu2BsExabQVIgi0Jq9josV5sji5qZXg6cUe eCP0aA1p+vp5mygPkeHST2H6eGDdSTqqgTcSXs2Fu/OhTC6js7sphMDL1FqNWeOHuKB0 gPXIf5PxjTPOsrb49ilrYtf9GavVEgZm9lSE1mdUup+nkQUoVkf1zXdmKoMgaCKHSBxW +xAIYDIXLM+9rDbJMJFDCuGjUt8LSEGJUlH3CVSDRWAdmnCYE2q3Qph1tl4l/nWazWeg bU9D7Byh8LvJmQhNZuXhNoAnNkvPHfSqcIZJ+RkT7iOGw7a/MjXCqLZTPZKDFSLpOINC FbyQ==
X-Gm-Message-State: AODbwcAJIkCX+wMquHgcfzTWrXnE9kisFqsDcoKtOGAv8pEYQJzrrUlY d8b7xlkNz7McFueZx2BQcQzRcrk7PyOO
X-Received: by 10.55.157.74 with SMTP id g71mr36468864qke.92.1495663554495; Wed, 24 May 2017 15:05:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.31.101 with HTTP; Wed, 24 May 2017 15:05:53 -0700 (PDT)
In-Reply-To: 
References: <149523380739.28567.9584998643479497589@ietfa.amsl.com> <34EDA6D1-71BA-4E4C-BB9F-5E8FD05786D9@cooperw.in> 
From: Dan Romascanu 
Date: Thu, 25 May 2017 01:05:53 +0300
Message-ID: 
To: Joseph Salowey 
Cc: Alissa Cooper ,  "gen-art >> General area reviewing team" , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0556ecde8d8f05504c4e81"
Archived-At: 
Subject: Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 22:05:58 -0000

--94eb2c0556ecde8d8f05504c4e81
Content-Type: text/plain; charset="UTF-8"

Hi Joe,

Looks OK, but don't you need to also drop 'as well as version 1.3 of TLS'
from the first paragraph in the Introduction?

Regards,

Dan

On Thu, May 25, 2017 at 12:29 AM, Joseph Salowey  wrote:

> Hi Dan and Alissa,
>
> There has been some churn in the text of the document due to my oversight
> when sending the document to the IESG.   The proposed new text provided
> below show should also resolve your comment.  Please let me know if you see
> any issues with this approach.
>
> Thanks,
>
> Joe
>
> Replacing section 4:
>
>
>    The cipher suites defined in this document MUST NOT be negotiated for
>    any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
>    one of these cipher suites when selecting TLS version other than TLS
>    1.2.  A client MUST treat the selection of these cipher suites in
>    combination with a different version of TLS as an error and generate
>    a fatal 'illegal_parameter' TLS alert.
>
>    Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
>    support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].
>
>
>
>
> On Wed, May 24, 2017 at 8:15 AM, Alissa Cooper  wrote:
>
>> Dan, thank you for your reviews of this document and thanks to the
>> authors for providing clarifications. I have balloted No Objection.
>>
>> Alissa
>>
>> > On May 19, 2017, at 6:43 PM, Dan Romascanu  wrote:
>> >
>> > Reviewer: Dan Romascanu
>> > Review result: Ready
>> >
>> > I am the assigned Gen-ART reviewer for this draft. The General Area
>> > Review Team (Gen-ART) reviews all IETF documents being processed
>> > by the IESG for the IETF Chair. Please wait for direction from your
>> > document shepherd or AD before posting a new version of the draft.
>> >
>> > For more information, please see the FAQ at
>> >
>> > .
>> >
>> > Document: draft-ietf-tls-ecdhe-psk-aead-??
>> > Reviewer: Dan Romascanu
>> > Review Date: 2017-05-19
>> > IETF LC End Date: 2017-05-18
>> > IESG Telechat date: 2017-05-25
>> >
>> > Summary:
>> >
>> > This is a straight-forward and clear document that defines several new
>> > cipher suites for the Transport Layer Security (TLS) protocol version
>> > 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
>> > with Pre-Shared Key (ECDHE_PSK) key exchange together with the
>> > Authenticated Encryption with Associated Data (AEAD) algorithms
>> > AES-GCM and AES-CCM. The document is well written and I appreciate the
>> > effort to clarify in the Introduction the context, what was missing,
>> > and why the document is necessary. One issue raised in my initial
>> > review for draft-03 was addressed, discussed and draft-04 includes
>> > useful clarification text.
>> >
>> > The document is Ready
>> >
>> > Major issues:
>> >
>> > Minor issues:
>> >
>> > Nits/editorial comments:
>> >
>> >
>> > _______________________________________________
>> > Gen-art mailing list
>> > Gen-art@ietf.org
>> > https://www.ietf.org/mailman/listinfo/gen-art
>>
>>
>

--94eb2c0556ecde8d8f05504c4e81
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Joe,

Looks OK, but don't you need to also dr=
op 'as well as version 1.3 of TLS'=C2=A0 from the first paragraph i=
n the Introduction? 

Regards,

Dan

On Thu, May 25, 2017 at 12:29 AM, J=
oseph Salowey <joe@salowey.net> wrote:
Hi Dan and Alissa,

There has=
 been some churn in the text of the document due to my oversight when sendi=
ng the document to the IESG. =C2=A0 The proposed new text provided below sh=
ow should also resolve your comment.=C2=A0 Please let me know if you see an=
y issues with this approach. =C2=A0

Thanks,
<=
div>
Joe

Replacing section 4:
 =20
   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].
<=
/div>



On We=
d, May 24, 2017 at 8:15 AM, Alissa Cooper <alissa@cooperw.in> wrote:
Dan, thank you for your reviews =
of this document and thanks to the authors for providing clarifications. I =
have balloted No Objection.



Alissa




> On May 19, 2017, at 6:43 PM, Dan Romascanu <dromasca@gmail.com> wrote:

>

> Reviewer: Dan Romascanu

> Review result: Ready

>

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed

> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.

>

> For more information, please see the FAQ at

>

> <https://trac.ietf.org/trac/gen/wiki/GenAr=
tfaq>.

>

> Document: draft-ietf-tls-ecdhe-psk-aead-??

> Reviewer: Dan Romascanu

> Review Date: 2017-05-19

> IETF LC End Date: 2017-05-18

> IESG Telechat date: 2017-05-25

>

> Summary:

>

> This is a straight-forward and clear document that defines several new=


> cipher suites for the Transport Layer Security (TLS) protocol version<=
br>
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> with Pre-Shared Key (ECDHE_PSK) key exchange together with the

> Authenticated Encryption with Associated Data (AEAD) algorithms

> AES-GCM and AES-CCM. The document is well written and I appreciate the=


> effort to clarify in the Introduction the context, what was missing,
> and why the document is necessary. One issue raised in my initial

> review for draft-03 was addressed, discussed and draft-04 includes

> useful clarification text.

>

> The document is Ready

>

> Major issues:

>

> Minor issues:

>

> Nits/editorial comments:

>

>


> _______________________________________________

> Gen-art mailing list

> Gen-art@ietf.org=


> https://www.ietf.org/mailman/listinfo/gen-art=











--94eb2c0556ecde8d8f05504c4e81--


From nobody Wed May 24 15:29:33 2017
Return-Path: 
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 6C46F129B41; Wed, 24 May 2017 15:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vXcJOyd3tdjf; Wed, 24 May 2017 15:29:28 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C165D129C00; Wed, 24 May 2017 15:29:27 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id h4so75077837lfj.3; Wed, 24 May 2017 15:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FOdG42rChCzBH0jcHYrlbb88YkgZEs7aF4JexBxxcEo=; b=DT4kFjQ0+Aj5PDK18QdzN1bstfRcSsbVAz3jjTA9ZoIfJWw14wyDXslPvCxVuCiO79 tBNz9ZJwGjJtbSAo7KIGMKg2su9H1KsAp9up1NzifDu21Nzne29A8OMV7DETC79lFDO1 idx68YepWaIzSAQDjPcwPHLlejNiBZEmm6UyLs4DvmEUO/HhT5YYpd004m/NPKUaDSN7 g0tHkYA4rI8ZX0waxjKNPFwnGRElw+zplFsVZ4b1HhYSZq94xAO3n/3c2r9abzGQ3egs EzsGf/UoRIY7YIyOIHzntQHSgpBBoKsIMxx0gOre5LwSHYwjh8XclmYjeUMxhDD5Mzcc h18w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FOdG42rChCzBH0jcHYrlbb88YkgZEs7aF4JexBxxcEo=; b=beXlZEhfpsKED/bM5c8ZvnMKmBaKczWPxEE/0XshN/T5y4ep9GLZ9pfv+Msr/uBNJ4 bzADZWtE6k3ylNbQDWhFgSqWEFzu3LGt5EbdgHmKIpexLqLT/AjTJ4RkLrhUj+Ag7oPl qDQ/r0mQJ4yQ4kLMe0XCMseUDCvsG2wcA45zGQK00COgZkfLFTEZA+8X1Xf0Ibed5NDl cJs76ZTwsUoHDCdSybRNjYPvRtXLSu+GVXJwNkczhjRbNrlcmQeNx0uCRmbUxDRaXqrz IEn8lPMsSRPNVjruu06S7zbkg7UkusoL265e/2lZ/v1OVqMSVLs8y0Do1jMnRT7LeMhI ApSA==
X-Gm-Message-State: AODbwcB0laeYIq0cpSWyIYw0ehSvHULYw5H3h4Qy0NBLOVia/wUOEr2W BZkAUz+HZDRjsEzupbIFioURMFnu0A==
X-Received: by 10.46.7.10 with SMTP id 10mr10716113ljh.113.1495664965930; Wed, 24 May 2017 15:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Wed, 24 May 2017 15:29:25 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>          
From: Martin Thomson 
Date: Thu, 25 May 2017 08:29:25 +1000
Message-ID: 
To: Daniel Migault 
Cc: Joseph Salowey , Eric Rescorla , tls-chairs ,  The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 22:29:29 -0000

On 25 May 2017 at 07:43, Daniel Migault  wrote:
> From your response I understand you do not request changes.


I am requesting changes. Just say that
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 uses AEAD_AES_128_GCM, and so
forth.  It's not hard to be explicit.


From nobody Wed May 24 15:49:17 2017
Return-Path: 
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 49163126C0F; Wed, 24 May 2017 15:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fPnxfAajvUqx; Wed, 24 May 2017 15:49:05 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B0E127077; Wed, 24 May 2017 15:49:04 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id m18so75205859lfj.0; Wed, 24 May 2017 15:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CJm+XsCdi0G6OjNaWzXItfy8Mur7Nh8IW9/XMo0fBao=; b=gngTnTFdh4ivYFG1HVCyOlvY2KDJZsc0VJZsBg/SrFjQO8UFMBYkQeXPZBVoN5K+/2 qbojsPPu/Any+8AJPaNrwcPjqXIfueRsfKFFXGIKFVOsLbbvPU6kDMvdNZEeMTuP2fTS TGXLD/HjLwvCrCUVtKh4A1DW0ya1x8OzO8mgLr6IcDJ+lPQeaSLF/GvlgcrFbUa2/PS2 yu0CqnqdKAkZdvpdb2kEl9ElOL9JD0ROF8YNGdY2YHEqHPPoTOB2ejC82OMJ27mCHzNO XV+hwazErVfHtt+4MEwVAsUbG/qT2Ae5S7ze03VOMEL95kq/6Jo5fHOC56wAeIUzhhLJ Ch9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CJm+XsCdi0G6OjNaWzXItfy8Mur7Nh8IW9/XMo0fBao=; b=EShcUnubp+yJmy5qmNyGv7H61u4HWrP4T1OwS9lklQIaHe14MAZOulcZZe7M6UdYpl nXPydu9cxVOq4Ysfafs/DHp1yGqcURmxdHpmUuBdZjPuQJsHkgJ9wGmBh07ksAvcZQqi IOd7x/KG12KoEitTpWWcVhPJawLjAhBEwMlDmp8pS6oTmPXpHNxY7wNl7tDg1MgIXsnC f80JxsgsD9Y1qT4JvWMmk8tephyE4qjrd5i6NXXBCjAoib7Jq0WAHs4dkB+wy6jv0drQ oXeyFN8E29VofAsgUHEC00klr3yMAJ8KqpQAE6Nn+kyyeHIK6BU+EMq5YWOEYbXLA3J8 Kwnw==
X-Gm-Message-State: AODbwcCXRReTOAMQsPL6q0iQ+5KmrayCDbUrlJcL6WvZczjeoacUMu/G /tvscXIixYckD+URWwIyfPimSE+DOg==
X-Received: by 10.46.88.17 with SMTP id m17mr9819328ljb.26.1495666142791; Wed, 24 May 2017 15:49:02 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Wed, 24 May 2017 15:49:02 -0700 (PDT)
In-Reply-To: 
References: <149523380739.28567.9584998643479497589@ietfa.amsl.com> <34EDA6D1-71BA-4E4C-BB9F-5E8FD05786D9@cooperw.in>  
From: Daniel Migault 
Date: Wed, 24 May 2017 17:49:02 -0500
X-Google-Sender-Auth: vt0RFHDF2_mJVRPkAP20GmnSFbw
Message-ID: 
To: Dan Romascanu 
Cc: Joseph Salowey , Alissa Cooper ,  "gen-art >> General area reviewing team" , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403043882e024d05c05504ce936"
Archived-At: 
Subject: Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 22:49:07 -0000

--f403043882e024d05c05504ce936
Content-Type: text/plain; charset="UTF-8"

Hi Dan,

The major concern we have is that as a response to your comment I detailed
how the defined cipher suites are agreed with TLS1.3. The text we agreed on
has been updated, but I guess it still provides enough details.

In addition, you are right, we have also clarified the text and make sure
there is not misunderstanding that the code points assigned are only valid
for TLS1.2. This includes specification of the version in the title, as
well as removal of most reference to TLS1.3 in the introduction. The only
remaining reference to TLS1.3 in the introduction is used to motivate the
use of AEAD algorithms.

The current text for the introduction is as quoted below.

Again thank you all for your reviews,

Yours,
Daniel



2.  Introduction

   This document defines new cipher suites that provide Pre-Shared Key
   (PSK) authentication, Perfect Forward Secrecy (PFS), and
   Authenticated Encryption with Associated Data (AEAD).  The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol and version 1.2 of the Datagram Transport
   Layer Security (DTLS) protocol [RFC6347].

   Pre-Shared Key (PSK) Authentication is widely used in many scenarios.
   One deployment is 3GPP networks where pre-shared keys are used to
   authenticate both subscriber and network.  Another deployment is
   Internet of Things where PSK authentication is often preferred for
   performance and energy efficiency reasons.  In both scenarios the
   endpoints are owned/controlled by a party that provisions the pre-
   shared keys and makes sure that they provide a high level of entropy.

   Perfect Forward Secrecy (PFS) is a strongly recommended feature in
   security protocol design and can be accomplished by using an
   ephemeral Diffie-Hellman key exchange method.  Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) provides PFS with excellent performance
   and small key sizes.  ECDHE is mandatory to implement in both HTTP/2
   [RFC7540] and CoAP [RFC7252].

  AEAD algorithms that combine encryption and integrity protection are
   strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].  The AEAD
   algorithms considered in this document are AES-GCM and AES-CCM.  The
   use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
   is defined in [RFC6655].

   [RFC4279] defines Pre-Shared Key (PSK) cipher suites for TLS but does
   not consider Elliptic Curve Cryptography.  [RFC4492] introduces
   Elliptic Curve Cryptography for TLS but does not consider PSK
   authentication.  [RFC5487] describes the use of AES-GCM in
   combination with PSK authentication, but does not consider ECDHE.
   [RFC5489] describes the use of PSK in combination with ECDHE but does
   not consider AES-GCM or AES-CCM.


On Wed, May 24, 2017 at 5:05 PM, Dan Romascanu  wrote:

> Hi Joe,
>
> Looks OK, but don't you need to also drop 'as well as version 1.3 of TLS'
> from the first paragraph in the Introduction?
>
> Regards,
>
> Dan
>
> On Thu, May 25, 2017 at 12:29 AM, Joseph Salowey  wrote:
>
>> Hi Dan and Alissa,
>>
>> There has been some churn in the text of the document due to my oversight
>> when sending the document to the IESG.   The proposed new text provided
>> below show should also resolve your comment.  Please let me know if you see
>> any issues with this approach.
>>
>> Thanks,
>>
>> Joe
>>
>> Replacing section 4:
>>
>>
>>    The cipher suites defined in this document MUST NOT be negotiated for
>>    any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
>>    one of these cipher suites when selecting TLS version other than TLS
>>    1.2.  A client MUST treat the selection of these cipher suites in
>>    combination with a different version of TLS as an error and generate
>>    a fatal 'illegal_parameter' TLS alert.
>>
>>    Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
>>    support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].
>>
>>
>>
>>
>> On Wed, May 24, 2017 at 8:15 AM, Alissa Cooper  wrote:
>>
>>> Dan, thank you for your reviews of this document and thanks to the
>>> authors for providing clarifications. I have balloted No Objection.
>>>
>>> Alissa
>>>
>>> > On May 19, 2017, at 6:43 PM, Dan Romascanu  wrote:
>>> >
>>> > Reviewer: Dan Romascanu
>>> > Review result: Ready
>>> >
>>> > I am the assigned Gen-ART reviewer for this draft. The General Area
>>> > Review Team (Gen-ART) reviews all IETF documents being processed
>>> > by the IESG for the IETF Chair. Please wait for direction from your
>>> > document shepherd or AD before posting a new version of the draft.
>>> >
>>> > For more information, please see the FAQ at
>>> >
>>> > .
>>> >
>>> > Document: draft-ietf-tls-ecdhe-psk-aead-??
>>> > Reviewer: Dan Romascanu
>>> > Review Date: 2017-05-19
>>> > IETF LC End Date: 2017-05-18
>>> > IESG Telechat date: 2017-05-25
>>> >
>>> > Summary:
>>> >
>>> > This is a straight-forward and clear document that defines several new
>>> > cipher suites for the Transport Layer Security (TLS) protocol version
>>> > 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
>>> > with Pre-Shared Key (ECDHE_PSK) key exchange together with the
>>> > Authenticated Encryption with Associated Data (AEAD) algorithms
>>> > AES-GCM and AES-CCM. The document is well written and I appreciate the
>>> > effort to clarify in the Introduction the context, what was missing,
>>> > and why the document is necessary. One issue raised in my initial
>>> > review for draft-03 was addressed, discussed and draft-04 includes
>>> > useful clarification text.
>>> >
>>> > The document is Ready
>>> >
>>> > Major issues:
>>> >
>>> > Minor issues:
>>> >
>>> > Nits/editorial comments:
>>> >
>>> >
>>> > _______________________________________________
>>> > Gen-art mailing list
>>> > Gen-art@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/gen-art
>>>
>>>
>>
>

--f403043882e024d05c05504ce936
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dan, 

The major concern we have =
is that as a response to your comment I detailed how the defined cipher sui=
tes are agreed with TLS1.3. The text we agreed on has been updated, but I g=
uess it still provides enough details. 

In addition, you =
are right, we have also clarified the text and make sure there is not misun=
derstanding that the code points assigned are only valid for TLS1.2. This i=
ncludes specification of the version in the title, as well as removal of mo=
st reference to TLS1.3 in the introduction. The only remaining reference to=
 TLS1.3 in the introduction is used to motivate the use of AEAD algorithms.=
 

The current text for the introduction is as quoted below.
=


Again thank you all for your reviews, 

Yours, 
Daniel



2.=C2=
=A0 Introduction

=C2=A0=C2=A0 This document defines new cipher suite=
s that provide Pre-Shared Key
=C2=A0=C2=A0 (PSK) authentication, Perfect=
 Forward Secrecy (PFS), and
=C2=A0=C2=A0 Authenticated Encryption with A=
ssociated Data (AEAD).=C2=A0 The cipher
=C2=A0=C2=A0 suites are defined =
for version 1.2 of the Transport Layer Security
=C2=A0=C2=A0 (TLS) [RFC5=
246] protocol and version 1.2 of the Datagram Transport
=C2=A0=C2=A0 Lay=
er Security (DTLS) protocol [RFC6347].

=C2=A0=C2=A0 Pre-Shared Key (=
PSK) Authentication is widely used in many scenarios.
=C2=A0=C2=A0 One d=
eployment is 3GPP networks where pre-shared keys are used to
=C2=A0=C2=
=A0 authenticate both subscriber and network.=C2=A0 Another deployment is=C2=A0=C2=A0 Internet of Things where PSK authentication is often preferr=
ed for
=C2=A0=C2=A0 performance and energy efficiency reasons.=C2=A0 In =
both scenarios the
=C2=A0=C2=A0 endpoints are owned/controlled by a part=
y that provisions the pre-
=C2=A0=C2=A0 shared keys and makes sure that =
they provide a high level of entropy.

=C2=A0=C2=A0 Perfect Forward S=
ecrecy (PFS) is a strongly recommended feature in
=C2=A0=C2=A0 security =
protocol design and can be accomplished by using an
=C2=A0=C2=A0 ephemer=
al Diffie-Hellman key exchange method.=C2=A0 Ephemeral Elliptic
=C2=A0=
=C2=A0 Curve Diffie-Hellman (ECDHE) provides PFS with excellent performance=

=C2=A0=C2=A0 and small key sizes.=C2=A0 ECDHE is mandatory to implement=
 in both HTTP/2
=C2=A0=C2=A0 [RFC7540] and CoAP [RFC7252].

=C2=A0=
 AEAD algorithms that combine encryption and integrity protection are
=
=C2=A0=C2=A0 strongly recommended for (D)TLS [RFC7525] and non-AEAD algorit=
hms are
=C2=A0=C2=A0 forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].=
=C2=A0 The AEAD
=C2=A0=C2=A0 algorithms considered in this document are =
AES-GCM and AES-CCM.=C2=A0 The
=C2=A0=C2=A0 use of AES-GCM in TLS is def=
ined in [RFC5288] and the use of AES-CCM
=C2=A0=C2=A0 is defined in [RFC=
6655].

=C2=A0=C2=A0 [RFC4279] defines Pre-Shared Key (PSK) cipher su=
ites for TLS but does
=C2=A0=C2=A0 not consider Elliptic Curve Cryptogra=
phy.=C2=A0 [RFC4492] introduces
=C2=A0=C2=A0 Elliptic Curve Cryptography=
 for TLS but does not consider PSK
=C2=A0=C2=A0 authentication.=C2=A0 [R=
FC5487] describes the use of AES-GCM in
=C2=A0=C2=A0 combination with PS=
K authentication, but does not consider ECDHE.
=C2=A0=C2=A0 [RFC5489] de=
scribes the use of PSK in combination with ECDHE but does
=C2=A0=C2=A0 n=
ot consider AES-GCM or AES-CCM.


On Wed, May 24, 2017 at 5:0=
5 PM, Dan Romascanu <dromasca@gmail.com> wrote:
Hi Joe,

Looks OK, but don=
9;t you need to also drop 'as well as version 1.3 of TLS'=C2=A0 fro=
m the first paragraph in the Introduction? 

Regards,

Dan
<=
/div>
On Thu, May 25, 2017 at 12:29 AM, Joseph Salowe=
y <joe@salowey.net> wrote:
<=
div dir=3D"ltr">Hi Dan and Alissa,

There has been some c=
hurn in the text of the document due to my oversight when sending the docum=
ent to the IESG. =C2=A0 The proposed new text provided below show should al=
so resolve your comment.=C2=A0 Please let me know if you see any issues wit=
h this approach. =C2=A0

Thanks,

Joe

Replaci=
ng section 4:
 =20
   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].
<=
/div>



On Wed, May 24, 2017 at 8:15 AM, Aliss=
a Cooper <alissa@cooperw.in> wrote:
Dan, thank you for your reviews of this document and thanks to t=
he authors for providing clarifications. I have balloted No Objection.



Alissa




> On May 19, 2017, at 6:43 PM, Dan Romascanu <dromasca@gmail.com> wrote:

>

> Reviewer: Dan Romascanu

> Review result: Ready

>

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed

> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.

>

> For more information, please see the FAQ at

>

> <https://trac.ietf.org/trac/gen/wiki/GenAr=
tfaq>.

>

> Document: draft-ietf-tls-ecdhe-psk-aead-??

> Reviewer: Dan Romascanu

> Review Date: 2017-05-19

> IETF LC End Date: 2017-05-18

> IESG Telechat date: 2017-05-25

>

> Summary:

>

> This is a straight-forward and clear document that defines several new=


> cipher suites for the Transport Layer Security (TLS) protocol version<=
br>
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> with Pre-Shared Key (ECDHE_PSK) key exchange together with the

> Authenticated Encryption with Associated Data (AEAD) algorithms

> AES-GCM and AES-CCM. The document is well written and I appreciate the=


> effort to clarify in the Introduction the context, what was missing,
> and why the document is necessary. One issue raised in my initial

> review for draft-03 was addressed, discussed and draft-04 includes

> useful clarification text.

>

> The document is Ready

>

> Major issues:

>

> Minor issues:

>

> Nits/editorial comments:

>

>


> _______________________________________________

> Gen-art mailing list

> Gen-art@ietf.org=


> https://www.ietf.org/mailman/listinfo/gen-art=














--f403043882e024d05c05504ce936--


From nobody Wed May 24 19:27:51 2017
Return-Path: 
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 F1E8812704B; Wed, 24 May 2017 19:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YWAurgjiNSRJ; Wed, 24 May 2017 19:27:47 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7971200B9; Wed, 24 May 2017 19:27:46 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id b84so34457741wmh.0; Wed, 24 May 2017 19:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hU70Opv3ubXNYT9u411JEuaFuMZehs32p+ChUdZ4pz0=; b=L93cgORs+JNrc3kD8AR5z6KO2aRnHWHlldm84lStVmECsEClBCG8XpeW4IEd2sL6Vh vsUwYeRgtIEj8f/Ar8fD2i0ILl92aCfdw0lYvoclUn2gOip3KJfLPVDobRepxi8lVwAI OiBBtvaBmSbMHMR5TP/Ud58zgSVRlOQYcYhajsiHLHBYoZ7dcqOjlCt++WFUI9lYB7BM bbKfArG/Hfi1UKLQXl0jwv7KvnjN0DPv08a2ubpsf6qasNsoSXTxEbE7fsNfqKfdBT/e xUFA0VZi62IjxymuzBwyb86w83aLYQIhe7p0QMEQu4Le3dGgtAI/0jxXDTppzBU2Q05y 50RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hU70Opv3ubXNYT9u411JEuaFuMZehs32p+ChUdZ4pz0=; b=cnIQsXMGxYDD3ZI+WoACDkfQ3fB5m3whPDjBY3+WXTua5TeV38SQa1BTowdLIJJTzq HAU/9l53lL32E1Fj1Zo2OhSrDiYjWfLmT3LXmUgQYBYpBWkXRoKbUMbJMLkDBYDRjjGH 3HKq7yI5YQgNxMrh0zQc+/9ZuCrrcu9TMnKBK/gRI8g5HwLgqKb9LDidE385ZVE5afF7 Lp+N4TveCTG5KqwbbALdu72CmWmRlSVTgbSynxyZnQ1qJqKCskQ13jFyCVXs/yY5Qj5K orB1fL4tGU6RZp5ek7lTE2GeeGwhay0ELXjZaAh4e61YrFe6thDfzd3h+AIqn7cRVP3d Up6w==
X-Gm-Message-State: AODbwcBXXkbBhopyYLVT0HfSLCy0rE4KB+KXoY2AjUf7oU23hkwCHemm Smci/HmY1DyIZAEVm3c=
X-Received: by 10.28.209.131 with SMTP id i125mr7778267wmg.57.1495679265263; Wed, 24 May 2017 19:27:45 -0700 (PDT)
Received: from [10.0.0.4] (bzq-109-64-80-239.red.bezeqint.net. [109.64.80.239]) by smtp.gmail.com with ESMTPSA id w18sm5226682wmw.26.2017.05.24.19.27.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 19:27:44 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7AE317D5-E72E-4B21-90D3-35F853CFCA48
Mime-Version: 1.0 (1.0)
From: Dan Romascanu 
X-Mailer: iPhone Mail (14E304)
In-Reply-To: 
Date: Thu, 25 May 2017 05:27:39 +0300
Cc: Joseph Salowey , Alissa Cooper , "gen-art >> General area reviewing team" , draft-ietf-tls-ecdhe-psk-aead.all@ietf.org, "tls@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <93ACAA0C-8E1F-4F58-BF98-1179B141FF05@gmail.com>
References: <149523380739.28567.9584998643479497589@ietfa.amsl.com> <34EDA6D1-71BA-4E4C-BB9F-5E8FD05786D9@cooperw.in>   
To: Daniel Migault 
Archived-At: 
Subject: Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 02:27:50 -0000

--Apple-Mail-7AE317D5-E72E-4B21-90D3-35F853CFCA48
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Thanks. This clarifies now.

Regards,

Dan

Sent from my iPhone

> On 25 May 2017, at 1:49, Daniel Migault  wrot=
e:
>=20
> Hi Dan,=20
>=20
> The major concern we have is that as a response to your comment I detailed=
 how the defined cipher suites are agreed with TLS1.3. The text we agreed on=
 has been updated, but I guess it still provides enough details.=20
>=20
> In addition, you are right, we have also clarified the text and make sure t=
here is not misunderstanding that the code points assigned are only valid fo=
r TLS1.2. This includes specification of the version in the title, as well a=
s removal of most reference to TLS1.3 in the introduction. The only remainin=
g reference to TLS1.3 in the introduction is used to motivate the use of AEA=
D algorithms.=20
>=20
> The current text for the introduction is as quoted below.
>=20
> Again thank you all for your reviews,=20
>=20
> Yours,=20
> Daniel
>=20
>=20
>=20
> 2.  Introduction
>=20
>    This document defines new cipher suites that provide Pre-Shared Key
>    (PSK) authentication, Perfect Forward Secrecy (PFS), and
>    Authenticated Encryption with Associated Data (AEAD).  The cipher
>    suites are defined for version 1.2 of the Transport Layer Security
>    (TLS) [RFC5246] protocol and version 1.2 of the Datagram Transport
>    Layer Security (DTLS) protocol [RFC6347].
>=20
>    Pre-Shared Key (PSK) Authentication is widely used in many scenarios.
>    One deployment is 3GPP networks where pre-shared keys are used to
>    authenticate both subscriber and network.  Another deployment is
>    Internet of Things where PSK authentication is often preferred for
>    performance and energy efficiency reasons.  In both scenarios the
>    endpoints are owned/controlled by a party that provisions the pre-
>    shared keys and makes sure that they provide a high level of entropy.
>=20
>    Perfect Forward Secrecy (PFS) is a strongly recommended feature in
>    security protocol design and can be accomplished by using an
>    ephemeral Diffie-Hellman key exchange method.  Ephemeral Elliptic
>    Curve Diffie-Hellman (ECDHE) provides PFS with excellent performance
>    and small key sizes.  ECDHE is mandatory to implement in both HTTP/2
>    [RFC7540] and CoAP [RFC7252].
>=20
>   AEAD algorithms that combine encryption and integrity protection are
>    strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are
>    forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13].  The AEAD
>    algorithms considered in this document are AES-GCM and AES-CCM.  The
>    use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
>    is defined in [RFC6655].
>=20
>    [RFC4279] defines Pre-Shared Key (PSK) cipher suites for TLS but does
>    not consider Elliptic Curve Cryptography.  [RFC4492] introduces
>    Elliptic Curve Cryptography for TLS but does not consider PSK
>    authentication.  [RFC5487] describes the use of AES-GCM in
>    combination with PSK authentication, but does not consider ECDHE.
>    [RFC5489] describes the use of PSK in combination with ECDHE but does
>    not consider AES-GCM or AES-CCM.
>=20
>=20
>> On Wed, May 24, 2017 at 5:05 PM, Dan Romascanu  wrote=
:
>> Hi Joe,
>>=20
>> Looks OK, but don't you need to also drop 'as well as version 1.3 of TLS'=
  from the first paragraph in the Introduction?=20
>>=20
>> Regards,
>>=20
>> Dan
>>=20
>>> On Thu, May 25, 2017 at 12:29 AM, Joseph Salowey  wrote=
:
>>> Hi Dan and Alissa,
>>>=20
>>> There has been some churn in the text of the document due to my oversigh=
t when sending the document to the IESG.   The proposed new text provided be=
low show should also resolve your comment.  Please let me know if you see an=
y issues with this approach. =20
>>>=20
>>> Thanks,
>>>=20
>>> Joe
>>>=20
>>> Replacing section 4:
>>>  =20
>>>    The cipher suites defined in this document MUST NOT be negotiated for=

>>>    any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
>>>    one of these cipher suites when selecting TLS version other than TLS
>>>    1.2.  A client MUST treat the selection of these cipher suites in
>>>    combination with a different version of TLS as an error and generate
>>>    a fatal 'illegal_parameter' TLS alert.
>>>=20
>>>    Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>>>    TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
>>>    support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].
>>>=20
>>>=20
>>>=20
>>>> On Wed, May 24, 2017 at 8:15 AM, Alissa Cooper  wrot=
e:
>>>> Dan, thank you for your reviews of this document and thanks to the auth=
ors for providing clarifications. I have balloted No Objection.
>>>>=20
>>>> Alissa
>>>>=20
>>>> > On May 19, 2017, at 6:43 PM, Dan Romascanu  wrote=
:
>>>> >
>>>> > Reviewer: Dan Romascanu
>>>> > Review result: Ready
>>>> >
>>>> > I am the assigned Gen-ART reviewer for this draft. The General Area
>>>> > Review Team (Gen-ART) reviews all IETF documents being processed
>>>> > by the IESG for the IETF Chair. Please wait for direction from your
>>>> > document shepherd or AD before posting a new version of the draft.
>>>> >
>>>> > For more information, please see the FAQ at
>>>> >
>>>> > .
>>>> >
>>>> > Document: draft-ietf-tls-ecdhe-psk-aead-??
>>>> > Reviewer: Dan Romascanu
>>>> > Review Date: 2017-05-19
>>>> > IETF LC End Date: 2017-05-18
>>>> > IESG Telechat date: 2017-05-25
>>>> >
>>>> > Summary:
>>>> >
>>>> > This is a straight-forward and clear document that defines several ne=
w
>>>> > cipher suites for the Transport Layer Security (TLS) protocol version=

>>>> > 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
>>>> > with Pre-Shared Key (ECDHE_PSK) key exchange together with the
>>>> > Authenticated Encryption with Associated Data (AEAD) algorithms
>>>> > AES-GCM and AES-CCM. The document is well written and I appreciate th=
e
>>>> > effort to clarify in the Introduction the context, what was missing,
>>>> > and why the document is necessary. One issue raised in my initial
>>>> > review for draft-03 was addressed, discussed and draft-04 includes
>>>> > useful clarification text.
>>>> >
>>>> > The document is Ready
>>>> >
>>>> > Major issues:
>>>> >
>>>> > Minor issues:
>>>> >
>>>> > Nits/editorial comments:
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Gen-art mailing list
>>>> > Gen-art@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/gen-art
>>>>=20
>>>=20
>>=20
>=20

--Apple-Mail-7AE317D5-E72E-4B21-90D3-35F853CFCA48
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thanks. This clarifies now.

Regards,

=
Dan

Sent from my iPhone

On 25 May 2017, at 1:49, Daniel=
 Migault <daniel.migault@e=
ricsson.com> wrote:

Hi Dan, 

The major concern we have is that=
 as a response to your comment I detailed how the defined cipher suites are a=
greed with TLS1.3. The text we agreed on has been updated, but I guess it st=
ill provides enough details. 

In addition, you are right, w=
e have also clarified the text and make sure there is not misunderstanding t=
hat the code points assigned are only valid for TLS1.2. This includes specif=
ication of the version in the title, as well as removal of most reference to=
 TLS1.3 in the introduction. The only remaining reference to TLS1.3 in the i=
ntroduction is used to motivate the use of AEAD algorithms. 

The=
 current text for the introduction is as quoted below.

Again thank you all for your reviews, 

Yours, 
Daniel



2.  Introduction
   This document defines new cipher suites that provide Pre-Shar=
ed Key
   (PSK) authentication, Perfect Forward Secrecy (PFS), a=
nd
   Authenticated Encryption with Associated Data (AEAD).&nbs=
p; The cipher
   suites are defined for version 1.2 of the Tran=
sport Layer Security
   (TLS) [RFC5246] protocol and version 1.=
2 of the Datagram Transport
   Layer Security (DTLS) protocol [=
RFC6347].

   Pre-Shared Key (PSK) Authentication is widely u=
sed in many scenarios.
   One deployment is 3GPP networks where=
 pre-shared keys are used to
   authenticate both subscriber an=
d network.  Another deployment is
   Internet of Things wh=
ere PSK authentication is often preferred for
   performance an=
d energy efficiency reasons.  In both scenarios the
   end=
points are owned/controlled by a party that provisions the pre-
 &nb=
sp; shared keys and makes sure that they provide a high level of entropy.
   Perfect Forward Secrecy (PFS) is a strongly recommended fe=
ature in
   security protocol design and can be accomplished by=
 using an
   ephemeral Diffie-Hellman key exchange method. =
; Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) provides P=
FS with excellent performance
   and small key sizes.  ECD=
HE is mandatory to implement in both HTTP/2
   [RFC7540] and Co=
AP [RFC7252].

  AEAD algorithms that combine encryption and inte=
grity protection are
   strongly recommended for (D)TLS [RFC752=
5] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [=
I-D.ietf-tls-tls13].  The AEAD
   algorithms considered in=
 this document are AES-GCM and AES-CCM.  The
   use of AES=
-GCM in TLS is defined in [RFC5288] and the use of AES-CCM
   i=
s defined in [RFC6655].

   [RFC4279] defines Pre-Shared Key=
 (PSK) cipher suites for TLS but does
   not consider Elliptic C=
urve Cryptography.  [RFC4492] introduces
   Elliptic Curve=
 Cryptography for TLS but does not consider PSK
   authenticati=
on.  [RFC5487] describes the use of AES-GCM in
   combinat=
ion with PSK authentication, but does not consider ECDHE.
   [R=
FC5489] describes the use of PSK in combination with ECDHE but does
 =
;  not consider AES-GCM or AES-CCM.


On Wed, May 24, 2017 a=
t 5:05 PM, Dan Romascanu <dromasca@gmail.com> wrote:
Hi Joe,

Looks OK, but don't=
 you need to also drop 'as well as version 1.3 of TLS'  from the first p=
aragraph in the Introduction? 

Regards,

Dan

On Thu, May 25, 2017 at 12:29 AM, Joseph Salowey <joe@salowey.net=
> wrote:
Hi D=
an and Alissa,

There has been some churn in the text of t=
he document due to my oversight when sending the document to the IESG.  =
; The proposed new text provided below show should also resolve your comment=
.  Please let me know if you see any issues with this approach.  <=
/div>

Thanks,

Joe

=

Replacing section 4:
 =20
   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Servers MUST NOT select
   one of these cipher suites when selecting TLS version other than TLS
   1.2.  A client MUST treat the selection of these cipher suites in
   combination with a different version of TLS as an error and generate
   a fatal 'illegal_parameter' TLS alert.

   Cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are used to
   support equivalent functionality in TLS 1.3 [I-D.ietf-tls-tls13].



On Wed, May 24, 2017 at 8:15 AM, Alissa Co=
oper <alissa@cooperw.in> wrote:
Dan, thank you for your reviews of this document and thanks to the author=
s for providing clarifications. I have balloted No Objection.



Alissa




> On May 19, 2017, at 6:43 PM, Dan Romascanu <dromasca@gmail.com> wrote:

>

> Reviewer: Dan Romascanu

> Review result: Ready

>

> I am the assigned Gen-ART reviewer for this draft. The General Area
=

> Review Team (Gen-ART) reviews all IETF documents being processed

> by the IESG for the IETF Chair. Please wait for direction from your
=

> document shepherd or AD before posting a new version of the draft.

>

> For more information, please see the FAQ at

>

> <https://trac.ietf.org/trac/gen/wiki/GenArtf=
aq>.

>

> Document: draft-ietf-tls-ecdhe-psk-aead-??

> Reviewer: Dan Romascanu

> Review Date: 2017-05-19

> IETF LC End Date: 2017-05-18

> IESG Telechat date: 2017-05-25

>

> Summary:

>

> This is a straight-forward and clear document that defines several new<=
br>
> cipher suites for the Transport Layer Security (TLS) protocol version
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> with Pre-Shared Key (ECDHE_PSK) key exchange together with the

> Authenticated Encryption with Associated Data (AEAD) algorithms

> AES-GCM and AES-CCM. The document is well written and I appreciate the<=
br>
> effort to clarify in the Introduction the context, what was missing,
> and why the document is necessary. One issue raised in my initial

> review for draft-03 was addressed, discussed and draft-04 includes

> useful clarification text.

>

> The document is Ready

>

> Major issues:

>

> Minor issues:

>

> Nits/editorial comments:

>

>


> _______________________________________________

> Gen-art mailing list

> Gen-art@ietf.org<=
/a>

> https://www.ietf.org/mailman/listinfo/gen-art













=

--Apple-Mail-7AE317D5-E72E-4B21-90D3-35F853CFCA48--


From nobody Thu May 25 06:32:21 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D09129A96; Thu, 25 May 2017 06:32:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149571912389.8608.7864221512808308039@ietfa.amsl.com>
Date: Thu, 25 May 2017 06:32:03 -0700
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 25 May 2017 13:32:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2
        Authors         : John Mattsson
                          Daniel Migault
	Filename        : draft-ietf-tls-ecdhe-psk-aead-05.txt
	Pages           : 7
	Date            : 2017-05-25

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol version 1.2.  The cipher suites are all
   based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared
   Key (ECDHE_PSK) key exchange together with the Authenticated
   Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-
   CCM.  PSK provides light and efficient authentication, ECDHE provides
   forward secrecy, and AES-GCM and AES-CCM provides encryption and
   integrity protection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu May 25 06:37:36 2017
Return-Path: 
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 35B0D12944A; Thu, 25 May 2017 06:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level: 
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LOF7676mjb1b; Thu, 25 May 2017 06:37:25 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9E9128B90; Thu, 25 May 2017 06:37:24 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id 99so83658633lfu.1; Thu, 25 May 2017 06:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P8kPHP21WBgAslSOk7RK+DxNYRp86Krm5CMaS0NhS8M=; b=ROK9zmKHRCdrbPGgdp184fkNs7REQ8y2hEWSWuOxmMcsQJNwcH9iMbdleDdOElkVXb iKPGdWwxGqlfdT+mJQ8ewauY22Ci21tDYNp2fXC2Kd1XZmGdu15QEdJifqXz1JpnpG3p RULcvx23OpUZq6n70BiTDxqZOvCYUIndRDtQ38+faAgdRV/vP4XUWV4kn2PH4u+q99hs 4rvo7eJPwRhHSrBqgvZSUR+vzAPX/LvuwxXP35y+J4ZCU1JwS07YKKqq0nzm9Z2PVKVN JK6N7EjDJEle4El7tOE5czOgKHyh2N67ACquq9/ZW7R0l4kMM0bsmnkiHCgxvK2vShxs vIXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P8kPHP21WBgAslSOk7RK+DxNYRp86Krm5CMaS0NhS8M=; b=IAalsH+M6mFZk4QOjlv4ZHztR6047qMLU5bkJNVcecf7Elfarulb8c0XjWGeLEFBUj SA7EOzpep+bYjXtUtSIy9rvDqQXK7WNxOwg1CJcKmj/hacujHb/kMr0qgFSV84H+SjaW rq9jXqDjhk8EYQUrlWCMYaN0knXLpd2kdQzeJGzAEqUdGfM7FPcNdzaqCwKdY52DSZYj g6Yi5ByAuetPw/rMj0GWHhRZi+JqDaTKHWxfU5WmfwQMqH4VBaNR718+4x4sMmWDCS8B RMfVp+7yZvOTljfKOV2yUqNtDcJXxETf3RCwji2bLtlwx21x8Rj3tZgQccMD5UaXqh+H l7cg==
X-Gm-Message-State: AODbwcCW1tbksSfF/ckDkv3sKymwpDit6EDXqVXwbrHfYUDfPiXyAY89 323F0A8UVZYarp5ppfZMQrM5cZbStg==
X-Received: by 10.46.88.17 with SMTP id m17mr10759812ljb.26.1495719442894; Thu, 25 May 2017 06:37:22 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.0.14 with HTTP; Thu, 25 May 2017 06:37:21 -0700 (PDT)
In-Reply-To: 
References: <149550551972.4974.3201248950751611020.idtracker@ietfa.amsl.com>           
From: Daniel Migault 
Date: Thu, 25 May 2017 09:37:21 -0400
X-Google-Sender-Auth: cNHJUXlR2x4rVwHaUaeBzltlzWA
Message-ID: 
To: Martin Thomson 
Cc: Joseph Salowey , Eric Rescorla , tls-chairs ,  The IESG , tls , draft-ietf-tls-ecdhe-psk-aead@ietf.org
Content-Type: multipart/alternative; boundary="f403043882e013d91105505952c1"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 13:37:27 -0000

--f403043882e013d91105505952c1
Content-Type: text/plain; charset="UTF-8"

 Hi,

Please find the version the secretariat just published. I believe all
comments have been addressed. Thank you all for the reviews!

Yours,

Daniel



-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, May 25, 2017 9:32 AM
To: John Mattsson ; Daniel Migault

Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-05.txt





A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-05.txt

has been successfully submitted by Daniel Migault and posted to the IETF
repository.



Name:                  draft-ietf-tls-ecdhe-psk-aead

Revision:              05

Title:                      ECDHE_PSK with AES-GCM and AES-CCM Cipher
Suites for Transport Layer Security (TLS) Protocol version 1.2

Document date:               2017-05-24

Group:                  tls

Pages:                   7

URL:
https://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-aead-05.txt

Status:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05

Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-05

Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-05



Abstract:

   This document defines several new cipher suites for the Transport

   Layer Security (TLS) protocol version 1.2.  The cipher suites are all

   based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared

   Key (ECDHE_PSK) key exchange together with the Authenticated

   Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-

   CCM.  PSK provides light and efficient authentication, ECDHE provides

   forward secrecy, and AES-GCM and AES-CCM provides encryption and

   integrity protection.










Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.



The IETF Secretariat

On Wed, May 24, 2017 at 6:29 PM, Martin Thomson 
wrote:

> On 25 May 2017 at 07:43, Daniel Migault 
> wrote:
> > From your response I understand you do not request changes.
>
>
> I am requesting changes. Just say that
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 uses AEAD_AES_128_GCM, and so
> forth.  It's not hard to be explicit.
>

--f403043882e013d91105505952c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable





=C2=A0Hi, 
Please find the version the secretariat just published. I believe al=
l comments have been addressed. Thank you all for the reviews!
Yours, 
D=
aniel



=C2=A0



-----Original Mes=
sage-----

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 

Sent: Thursday, May 25, 2017 9:32 AM

To: John Mattsson <john.mattsson@ericsson.com>; Daniel Migault
<daniel.migault@ericsson.com>

Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-05.txt<=
/a>



=C2=A0



=C2=A0



A new version of
I-D, draft-ietf-tls-ecdhe-psk-aead-05.txt



has been
successfully submitted by Daniel Migault and posted to the IETF repository.=




=C2=A0



Name:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 draft-ietf-tls-ecdhe-psk-aead



Revision:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 05<=
/p>


Title:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 ECDHE_PSK with AES-GCM and
AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1=
.2



Document date:=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2017-05-24



Group:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 tls



Pages:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 7



URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/inte=
rnet-drafts/draft-ietf-tls-ecdhe-psk-aead-05.txt



Status:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-ietf-tls-ec=
dhe-psk-aead/



Htmlized:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05



Htmlized:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/draft-ietf-tls=
-ecdhe-psk-aead-05



Diff:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?url=
2=3Ddraft-ietf-tls-ecdhe-psk-aead-05



=C2=A0



Abstract:



=C2=A0=C2=A0 This docume=
nt defines several new cipher
suites for the Transport



=C2=A0=C2=A0 Layer Secur=
ity (TLS) protocol version
1.2.=C2=A0 The cipher suites are all



=C2=A0=C2=A0 based on th=
e Ephemeral Elliptic Curve
Diffie-Hellman with Pre-Shared



=C2=A0=C2=A0 Key (ECDHE_=
PSK) key exchange together with
the Authenticated



=C2=A0=C2=A0 Encryption =
with Associated Data (AEAD)
algorithms AES-GCM and AES-



=C2=A0=C2=A0 CCM.=
=C2=A0
PSK provides light and efficient authentication, ECDHE provides



=C2=A0=C2=A0 forward sec=
recy, and AES-GCM and AES-CCM
provides encryption and



=C2=A0=C2=A0 integrity p=
rotection.



=C2=A0



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0




=C2=A0



=C2=A0



Please note that
it may take a couple of minutes from the time of submission until the htmli=
zed
version and diff are available at tools.i=
etf.org.



=C2=A0



The IETF
Secretariat




On Wed, May=
 24, 2017 at 6:29 PM, Martin Thomson <martin.thomson@gmail.com&=
gt; wrote:
On 25 =
May 2017 at 07:43, Daniel Migault <daniel.migault@ericsson.com> wrote:

> From your response I understand you do not request changes.





I am requesting changes. Just say that

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 uses AEAD_AES_128_GCM, and so
forth.=C2=A0 It's not hard to be explicit.





--f403043882e013d91105505952c1--


From nobody Thu May 25 22:16:10 2017
Return-Path: 
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 7A2011241FC for ; Thu, 25 May 2017 22:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 s_xay3pqANBj for ; Thu, 25 May 2017 22:16:06 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7A3126CBF for ; Thu, 25 May 2017 22:16:06 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id b204so695380oii.1 for ; Thu, 25 May 2017 22:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=3a22t06/qUkM4rrXbI74rmIjmEG5cnLy/6trVJUMfUc=; b=qFNXxOaZifBGW7q77wE0VhCV/t/7oKrgGVoZW8Dfg3LCasoFhB/wTy/dwkx8Gbst9d KmmUq46fOgVwt8E+00rim98pgLO3UayYnSDIEeEUld38ynUQ9CpYreeEPpz9p7UzCf8n WOENXQ9WFdRzkS8YHL1OYBNKoe8SzjwuA4OVDaxIpukleZVNxrK6m9FZ6xaC/csmIx6s 6arvCQoey2mKb/JomHDUJUwQ8jEaB2mnW211QZrKaXJ8mVCGYqgajSnBw8WY+EMD/DsZ Z9h4fpHMItInIpQnxGta3yzz53nRs0TFev7cLYf6ny9pjr6duNCKO3pWUBDXFOa3SkOH r+CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3a22t06/qUkM4rrXbI74rmIjmEG5cnLy/6trVJUMfUc=; b=GiK0BttF3ofp0gOGFZhdq8Jt+wLqfRX88LXY8TXKi8Ji4oGLLlskz3OYORykNMaY5N OsJt+SQWpzYJ/QS8erbbJKLCGGtEN4krM7E01wlm52fWyyRdIad51yGk7WuqvmUh1/bQ 4LEAXPSU8j7Ps4Aug0a2DRR8RAudnhMmqMy+BB6dPOyLavysRzN4l7zcEDl0EhLh8BEE LfCG6MEX0/fLoeK5x52IItCi0ARgeSZufF0C5EfNPJffEbeJjOxWBxoGAyHt7E5zcJRb 8RLqDpatxjFeZdngWIEN/T1uuB6BdfacARervniGbvxEbjIb9wNjlhPprRQWv+0i/3yW /4CA==
X-Gm-Message-State: AODbwcC6Ppm4V0CzslHWrv+gFOQHXi/zU05yu0ubqvAjKHSa5o0avb5l pDHsJvXvivd/QGWNdoGABmaD2VO5dw==
X-Received: by 10.157.16.55 with SMTP id h52mr55027ote.218.1495775766161; Thu, 25 May 2017 22:16:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.56.24 with HTTP; Thu, 25 May 2017 22:16:05 -0700 (PDT)
From: Sankalp Bagaria 
Date: Fri, 26 May 2017 10:46:05 +0530
Message-ID: 
To: tls@ietf.org
Cc: sankalp , Balaji Rajendran 
Content-Type: multipart/alternative; boundary="001a113d034234b1cc0550666ff8"
Archived-At: 
Subject: [TLS] HTTPS Phishing sites
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 05:16:08 -0000

--001a113d034234b1cc0550666ff8
Content-Type: text/plain; charset="UTF-8"

Hello,

http://securityaffairs.co/wordpress/59238/cyber-crime/
https-phishing-sites.html claims
that phishing websites using HTTPS are increasing in number. If malicious
sites can
get certificates, it defeats the purpose of TLS. In my opinion, tougher
measures are
required to prevent malicious sites getting legitimate certificates. What
can we do
about it ?

Regards,
Sankalp.

--001a113d034234b1cc0550666ff8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

http://securityaffairs.co/wordpress/59238/cyber-crime/ht=
tps-phishing-sites.html claims
that phishing websites using HTT=
PS are increasing in number. If malicious sites can
get certifica=
tes, it defeats the purpose of TLS. In my opinion, tougher measures are
required to prevent malicious sites getting legitimate certificates.=
 What can we do
about it ?

Regards,
Sankalp.


--001a113d034234b1cc0550666ff8--


From BATV+e4eadb104ff0d7260b01+5024+infradead.org+dwmw2@twosheds.srs.infradead.org  Thu May 25 22:24:10 2017
Return-Path: 
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 6B4A5120454 for ; Thu, 25 May 2017 22:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=infradead.org
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 1PhQvxfAUCOX for ; Thu, 25 May 2017 22:24:08 -0700 (PDT)
Received: from twosheds.infradead.org (twosheds.infradead.org [IPv6:2001:8b0:10b:1:21d:7dff:fe04:dbe2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE08126CBF for ; Thu, 25 May 2017 22:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=twosheds.20170209; h=Mime-Version:Date:Content-Type: References:In-Reply-To:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hs8hawknLK6ak5CG/6k3bqleXo3FEZPaMRrB3Pgivzk=; b=DJ/YV5cNhkqcabjm+AeRFyZkh LowGQiSTMUqijDgDIUT6Ow/s2i4a1a2pN7YkP/+jU0j5Hyj/43NVgELbjDsX9MNK3B9JHqPVCHSNT h8+AqaMuQspV0UqwMlMdbtRIZ6SWI+S9IscyFadxriXAqJXpvJrxEQ+OQEcOtKbwBoOuorFZ855Jd 9uBO79nfKQhO/93Qa8wgr2wSbw5iVBGCTRnHknjoIf0zbDs/r0Bh2CnpxePMqeANhlf5+7YkhFA2u m39m4NuKuN5cevQuZ0X+/9IqvLiRbpYKP4xCerOoy4xl0G2cQ7FZJI9qrwmlcSmd7Ibhhps+Oks3X HHAkodf3g==;
Received: from [2001:8b0:10b:1:5de4:715c:a500:779a] by twosheds.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1dE7jI-0006h7-Um; Fri, 26 May 2017 05:24:05 +0000
Message-ID: <1495776243.26190.10.camel@infradead.org>
From: David Woodhouse 
To: Sankalp Bagaria , tls@ietf.org
Cc: Balaji Rajendran , sankalp 
In-Reply-To: 
References: 
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-QEUZ30nL3gpMQREopP7M"
Date: Fri, 26 May 2017 06:24:03 +0100
Mime-Version: 1.0
X-Mailer: Evolution 3.18.5.2-0ubuntu3.1 
X-SRS-Rewrite: SMTP reverse-path rewritten from  by twosheds.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Subject: Re: [TLS] HTTPS Phishing sites
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 05:24:57 -0000

--=-QEUZ30nL3gpMQREopP7M
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2017-05-26 at 10:46 +0530, Sankalp Bagaria wrote:
> Hello,
>=20
> http://securityaffairs.co/wordpress/59238/cyber-crime/https-phishing-site=
s.html claims
> that phishing websites using HTTPS are increasing in number. If malicious=
 sites can
> get certificates, it defeats the purpose of TLS. In my opinion, tougher m=
easures are
> required to prevent malicious sites getting legitimate certificates. What=
 can we do
> about it ?

I wouldn't say that it defeats the purpose of TLS.

If https://hackerssite.co.ua/=C2=A0has a TLS certificate validating that it
really is hackerssite.co.ua, and I go there for my online banking...
well that's kind of my fault. That domain *isn't* my bank's clearly
owned domain name, and I should be looking for an EV certificate with
my bank's name in it.

So that would be *my* fault.... unless I suppose my bank have ACTIVELY
TRAINED me to succumb to fraud, by doing something insanely
incompetently negligent.... like Nat West running their online banking
on 'nwolb.com', with a certificate that says 'Royal Bank of Scotland'.
Neither of which match the brand "Nat West" by which I know my bank.

Those morons should probably be prosecuted for aiding and abetting the
fraud that they are enabling. Because *their* behaviour defeats the
purpose of TLS.

cf.=C2=A0http://david.woodhou.se/re-registration.html
--=-QEUZ30nL3gpMQREopP7M
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDzUw
ggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQG
EwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU
UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTE0MTIyMjAw
MDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1h
bmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF
bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAImxDdp6UxlOcFIdvFamBia3
uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdhTpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYep
LkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayT
QLm1CJM6nCpToxDbPSBhPFUDjtlOdiUCISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9
UjewM2ktQ+v61qXxl3dnUYzZ7ifrvKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3Rh
UL7GQD/L5OKfoiECAwEAAaOCARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa
MB0GA1UdDgQWBBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/
BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRV
HSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4
dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3Nw
LnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb4yJj
nFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ26Y3NOh7
4AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT9HaSyoY0B7ks
yuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInltukWeh95FPZKEBom
+nyK+5swggU9MIIEJaADAgECAhBqC1BYlVMtBFBN4igR/howMA0GCSqGSIb3DQEBCwUAMIGbMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYxMjIwMDAwMDAwWhcN
MTcxMjIwMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZyYWRlYWQub3JnMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwbTrFaiGdvN2pThnR9q+4eaXB2wQZQNqhter5ZrJ
pPO47e87bZ+f1tmYoh6+rB90G/XN24NErPRfvU4zVzNT9pCtCzSSVnBlZQBpaEYMKhcXo5PGKNsm
An8BoGwNXjlxwbBNRaNO+ky0wNCaMNd1JLxEuvqg9J7rrcpHhWmnpXD5IKa8gv9GyVAJgOpiBOts
p91sShc2kHvWJ5waPEWPCHDH9J+twGGKqKIIU7fdbURLUgUL1wlDSAHf/lgIAVCSj2H2HpoGqHpy
HgOAClX9iRSLNa0Znj8HTaqfOwxXevsz1KkLFY+Ahm426GIEqdfkK2iT6Hhgc7tjNO3f8i5ALQID
AQABo4IB8TCCAe0wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFILE
dmHLtK6oxmFJZvBhTQhvqrS0MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ
MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7
BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D
UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2
Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw
gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu
dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v
Y3NwLmNvbW9kb2NhLmNvbTAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRlYWQub3JnMA0GCSqGSIb3
DQEBCwUAA4IBAQA+AfvNhFwtapF5Lzjapgul3zYuEnMfR538Ya1vhP8wuOkcoJeT2gEFXzVO2WUu
eWM0g0/DumnRB53htV/Qq/+vsL0i6a2+iOO7kHi5O7bZkgbdNv0t2lzonDUHi6LTa7NUj+tv+j6y
hW+iNquC3ACP1dIZH8gJmicHblW63qRgp6wxhn315MLBeavi3uiSag2eeKFePiTIwJjN2UYq6kWg
PL5G/Ycf9x/xN1XBTfJiURc0FsXhrA98VMWnt52C5Lo4txhGjzTI+IZg40b3YDs6E7mTYb5KKmbc
QZA9priOFDdj1z5W9BdWhU6I/D0P9y8Z4Tr6+ZscMUVD0RqWy2LeMIIFPTCCBCWgAwIBAgIQagtQ
WJVTLQRQTeIoEf4aMDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy
ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp
bWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBMB4XDTE2MTIyMDAwMDAwMFoXDTE3MTIyMDIzNTk1OVowJDEiMCAGCSqG
SIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMG06xWohnbzdqU4Z0favuHmlwdsEGUDaobXq+WayaTzuO3vO22fn9bZmKIevqwfdBv1zduD
RKz0X71OM1czU/aQrQs0klZwZWUAaWhGDCoXF6OTxijbJgJ/AaBsDV45ccGwTUWjTvpMtMDQmjDX
dSS8RLr6oPSe663KR4Vpp6Vw+SCmvIL/RslQCYDqYgTrbKfdbEoXNpB71iecGjxFjwhwx/SfrcBh
iqiiCFO33W1ES1IFC9cJQ0gB3/5YCAFQko9h9h6aBqh6ch4DgApV/YkUizWtGZ4/B02qnzsMV3r7
M9SpCxWPgIZuNuhiBKnX5Ctok+h4YHO7YzTt3/IuQC0CAwEAAaOCAfEwggHtMB8GA1UdIwQYMBaA
FJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCxHZhy7SuqMZhSWbwYU0Ib6q0tDAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED
BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYB
BQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0
dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8v
Y3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0R
BBcwFYETZHdtdzJAaW5mcmFkZWFkLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAPgH7zYRcLWqReS84
2qYLpd82LhJzH0ed/GGtb4T/MLjpHKCXk9oBBV81TtllLnljNINPw7pp0Qed4bVf0Kv/r7C9Iumt
vojju5B4uTu22ZIG3Tb9Ldpc6Jw1B4ui02uzVI/rb/o+soVvojargtwAj9XSGR/ICZonB25Vut6k
YKesMYZ99eTCwXmr4t7okmoNnnihXj4kyMCYzdlGKupFoDy+Rv2HH/cf8TdVwU3yYlEXNBbF4awP
fFTFp7edguS6OLcYRo80yPiGYONG92A7OhO5k2G+Sipm3EGQPaa4jhQ3Y9c+VvQXVoVOiPw9D/cv
GeE6+vmbHDFFQ9Ealsti3jGCA9MwggPPAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg
TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu
ZCBTZWN1cmUgRW1haWwgQ0ECEGoLUFiVUy0EUE3iKBH+GjAwDQYJYIZIAWUDBAIBBQCgggHzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDUyNjA1MjQwM1owLwYJ
KoZIhvcNAQkEMSIEIAZa3FgqKFs20u6VJPfdgBOCGd5q6Ma0jbW4eUNwUBIZMIHBBgkrBgEEAYI3
EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01P
RE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQagtQ
WJVTLQRQTeIoEf4aMDCBwwYLKoZIhvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp
b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQagtQWJVTLQRQTeIoEf4aMDANBgkqhkiG9w0BAQEFAASC
AQApZaAk8s0UYYEHKMnXBOEx+KftoT8mtvhtsH62LCgpBJotjdFXRt4EUT8wNIpr3wJeLI7KY94l
nu9LHIDPp+ejC3d0l8rak4WCQ7pmUpiH5Io5UKje6Upl7eDYtaHqCtDXRzdQA7SoYkx7LQnRp6ll
TTMMRppZmdSyyRAuK8ttcwEinjK+0qAHoA/raSmEMS/WP6znO/PKRZ+Sn7629Mz/sCFP5ZTioag9
RZJL7BDGmVHtNxvst+FTGecrFII599Vw8c2G59W0rcnc5FnYMbWFBxRkPH0pkmoBDRSPhkb0FgO+
NjLiSjTI+zRc/axv+hs1A7bldC+ZEkUC8TAs87nrAAAAAAAA


--=-QEUZ30nL3gpMQREopP7M--


From nobody Thu May 25 23:33:29 2017
Return-Path: 
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 E830A127698 for ; Thu, 25 May 2017 23:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 OsH7u5tH9GFS for ; Thu, 25 May 2017 23:33:26 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73703120725 for ; Thu, 25 May 2017 23:33:26 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id 187so398158ybg.0 for ; Thu, 25 May 2017 23:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4LlWPMmES3IU66b0WM44TiJWq3oHw3kPHOScuy1cS0A=; b=2SkGWkwaeKd6UKJUTX3XFNeGT+IIBX/QHhyGiMUtvVyqB0dUNGeebjcf5R2P4uR+Q6 SXXGmLMDAmDrje0mdR2fNJ0ffZzsVCc5pwiaUQFWAaKg9R3Bi6wPrW2ndYto0immE8lR A8BzBcQyVeYXciFLRMKuFWtXDw7vDQ2SBxyIVZ2zJUGwdhTGSmqY+5oGQTMpzlbTKYmR HMPcNMqjtmAXRoV28JDWiNLy53ZnGj4smfBH9JKnlvY7AuChTwR8FdZTeoaHzqcMiMbL cDhbc0H3l4kWLYoxTNmQ73ivhdsiQzZFo6s5jnfl+2vaw4FKgXkzC/teJbvem3c0Di8r gJgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4LlWPMmES3IU66b0WM44TiJWq3oHw3kPHOScuy1cS0A=; b=h7cEeTBoa9aGtfyon5NI4THQAYCCMuJUXsiw4DHXVli4xqQiUjcAouW5I5OXK7Z+m1 +Rgq20+zvPSTIiVObs/yXmU2MWWyGLqejOHxktwwsRoHb+9MKPBmpLwqhuyNAQy9avit XjbvkBpoaJjml6etqOPdcnGY13tHY8dSbr+BZNMdFgsJkNmc1udPuPB8HDzwl8tylOpN mkAXEiz4tKvpcPfoWQ36F8YcZi7RWNc9ZqsORnVHP0KXgqpkAKheGVCjZZ4lvobR7nmm /ZD5Elma16Go0LwdH1FXFnA4LsMcBd97Jqr9gR31jx6jImUQw35kT4VH+JAry0FNd6hQ FAag==
X-Gm-Message-State: AODbwcBIj1knKaJHyLw9txK/Be+KOuux1LSRXD/sArEqNUco8ZSfOQAd 6M8xUQnIY9a8JgEUKA3aAzIwjdFkmC1F
X-Received: by 10.37.206.8 with SMTP id x8mr29318455ybe.16.1495780404264; Thu, 25 May 2017 23:33:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 25 May 2017 23:32:43 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Fri, 26 May 2017 14:32:43 +0800
Message-ID: 
To: Sankalp Bagaria 
Cc: "tls@ietf.org" , Balaji Rajendran , sankalp 
Content-Type: multipart/alternative; boundary="94eb2c190b20a8974f055067838e"
Archived-At: 
Subject: Re: [TLS] HTTPS Phishing sites
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 06:33:28 -0000

--94eb2c190b20a8974f055067838e
Content-Type: text/plain; charset="UTF-8"

On Fri, May 26, 2017 at 1:16 PM, Sankalp Bagaria 
wrote:

> Hello,
>
> http://securityaffairs.co/wordpress/59238/cyber-crime/https-
> phishing-sites.html claims
> that phishing websites using HTTPS are increasing in number. If malicious
> sites can
> get certificates, it defeats the purpose of TLS. In my opinion, tougher
> measures are
> required to prevent malicious sites getting legitimate certificates. What
> can we do
> about it ?
>
>
This issue is out of scope for the TLS WG. You might try the IETF general
mailing list.

-Ekr


> Regards,
> Sankalp.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c190b20a8974f055067838e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On F=
ri, May 26, 2017 at 1:16 PM, Sankalp Bagaria <sankalp.nitt@gmail.com=
> wrote:
<=
div>Hello,

http://se=
curityaffairs.co/wordpress/59238/cyber-crime/https-phishing-sites=
.html claims
that phishing websites using HTTPS are increasing =
in number. If malicious sites can
get certificates, it defeats th=
e purpose of TLS. In my opinion, tougher measures are
required to=
 prevent malicious sites getting legitimate certificates. What can we do
about it ?


This issue is out of scope for the TLS WG. You might try the IETF genera=
l mailing list.

-Ekr
=C2=A0
Regards,
Sankalp.


_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c190b20a8974f055067838e--


From nobody Fri May 26 03:07:34 2017
Return-Path: 
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 2056812711E for ; Fri, 26 May 2017 03:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 qQM2MXRf2194 for ; Fri, 26 May 2017 03:07:30 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90855126C7A for ; Fri, 26 May 2017 03:07:29 -0700 (PDT)
Received: from 213.171.251.212.customer.cdi.no ([212.251.171.213]:57185 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.84_2) (envelope-from ) id 1dEC9W-0003hT-9w for tls@ietf.org; Fri, 26 May 2017 12:07:26 +0200
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References: 
Date: Fri, 26 May 2017 12:07:14 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/12.17 (Win32)
Archived-At: 
Subject: Re: [TLS] HTTPS Phishing sites
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 10:07:33 -0000

On Fri, 26 May 2017 07:16:05 +0200, Sankalp Bagaria  
 wrote:

> Hello,
>
> http://securityaffairs.co/wordpress/59238/cyber-crime/
> https-phishing-sites.html claims
> that phishing websites using HTTPS are increasing in number. If malicious
> sites can
> get certificates, it defeats the purpose of TLS. In my opinion, tougher
> measures are
> required to prevent malicious sites getting legitimate certificates. What
> can we do
> about it ?

As EKR says separately, this is out of scope for the TLS WG.

It might be in scope for the CA/Browser Forum ,  
though.

However, you should not get your hopes up too high.

This is a very big problemspace, and I suspect that it is very difficult  
to get anything beyond checks for lookalike names to work properly (which  
could conceivably cause issues for legitimate sites, such as  
"sucks"-sites), without causing problems for the overriding goal of  
getting all internet traffic encrypted at an affordable cost.

Beyond this and the whack-a-mole system of lookup up lists of fraudulent  
sites, I suspect the difficult task of educating people is the only  
practical way of dealing with this issue; as mandating Extended Validation  
certficates would create trouble for the affordable encrypted internet  
goal.

-- 
Sincerely,
Yngve N. Pettersen


From nobody Fri May 26 12:20:14 2017
Return-Path: 
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 9A4821204DA for ; Fri, 26 May 2017 12:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OO4CRPFUI_Q9 for ; Fri, 26 May 2017 12:20:10 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id BA68A126CF6 for ; Fri, 26 May 2017 12:20:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2FF0C2568E; Fri, 26 May 2017 22:20:07 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id vA-1Dgs_B1Qb; Fri, 26 May 2017 22:20:06 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A63172313; Fri, 26 May 2017 22:20:06 +0300 (EEST)
Date: Fri, 26 May 2017 22:20:04 +0300
From: Ilari Liusvaara 
To: Sankalp Bagaria 
Cc: tls@ietf.org, Balaji Rajendran , sankalp 
Message-ID: <20170526192004.GA16526@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] HTTPS Phishing sites
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 19:20:13 -0000

On Fri, May 26, 2017 at 10:46:05AM +0530, Sankalp Bagaria wrote:
> 
> http://securityaffairs.co/wordpress/59238/cyber-crime/
> https-phishing-sites.html claims
> that phishing websites using HTTPS are increasing in number. If malicious
> sites can get certificates, it defeats the purpose of TLS. In my opinion,
> tougher measures are required to prevent malicious sites getting legitimate
> certificates. What can we do about it ?

As EKR said, this isn't within scope of TLS Working Group. And I don't
think it is even in the scope of the entiere IETF as whole (considering
the scope of work IETF does).

My opinion is that the problem isn't maliscous sites getting security
certificates (so what if paypal.com.foobar.za gets certificate saying
it is paypal.com.foobar.za? That is completely true claim). The issue
is the completely screwed up handling of security indications in
browsers. That is certainly not the sort of work the IETF is doing.


Judging by resonable interpretation of browser indications:

- Unencrypted http:// is safe (apart from passwords/CC numbers).
- DV certificates are extra trustworthy.

Neither of these interpretations is correct. But both are still
in my opinion reasonable.


TLS with DV certificates is not above expected security, it is the
closest to expected security, so it in my opinion should get the
neutral indicators (so no lock). And http:// certainly is much below
expected, so it should get negative indications. EV is above expected,
so it could get positive indications.


-Ilari


From nobody Tue May 30 13:03:57 2017
Return-Path: 
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 6A987129404; Tue, 30 May 2017 13:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.521
X-Spam-Level: 
X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 aee-IRlufD-S; Tue, 30 May 2017 13:03:53 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE8012942F; Tue, 30 May 2017 13:03:53 -0700 (PDT)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wcl133cFgz27wy; Tue, 30 May 2017 22:03:51 +0200 (CEST)
X-purgate-ID: 152705::1496174631-0000088C-5CA12B48/0/0
X-purgate-size: 2543
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3wcl130Kcbz2xb4; Tue, 30 May 2017 22:03:51 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 05F051A6AF; Tue, 30 May 2017 22:03:51 +0200 (CEST)
In-Reply-To: 
To: Eric Rescorla 
Date: Tue, 30 May 2017 22:03:51 +0200 (CEST)
CC: "mrex@sap.com" , The IESG ,  "tls@ietf.org" , tls-chairs ,  draft-ietf-tls-ecdhe-psk-aead@ietf.org
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170530200351.05F051A6AF@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 20:03:55 -0000

Eric Rescorla wrote:
> On Tue, May 23, 2017 at 9:34 PM, Martin Rex  wrote:
>>
>> This change _still_ prohibits the server from negotiating these algorithms
>> with TLSv1.1 and below.
>>
>> Could you elaborate a little on where and why you see a problem with this?
>>
> 
> For starters, TLS 1.3 has already designed a completely independent
> mechanism for doing version negotiation outside of ClientHello.version,
> so doing another seems pretty odd. In any case, it's not something you
> do between IETF-LC and IESG approval.

The suggestion to accept a recognized TLSv1.2 cipher suite code point
as an alternative indicator for the highest client-supported protocol
version is not really a "mechanism".  It's efficient (with 0-bytes on
the wire), intuitive and extremely backwards-compatible (will not upset
old servers, neither version-intolerant as the Win2008/2012 servers,
nor extension-intolerant servers.


> 
>> As this changes tries to explain, had such a text been used for all
>> TLSv1.2 AEAD cipher suite code points, then browsers would have never
>> needed any "downgrade dance" fallbacks, POODLE would have never
>> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
>> would not been needed, either.
> 
> I'm not sure this is true, because there were also servers which did
> not understand extensions.


It's worse -- there are still TLS servers out there which choke on
TLS extensions (and TLS server which choke on extension ordering).

Sending TLS extensions is therefore a negotiation scheme that we
can not ship as patch into the installed base, because we *KNOW*
that it will break a few existing usage scenarios.  Stuff that needs
TLS extensions is therefore an opt-in only scheme -- and even when
making it opt-in, we may have to additonally provide a TLS extension
exclusion list of hostnames.

It seems that there are others facing the same issue:

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows

and defer enabling to explicit customer opt-in.


Really, a very compatible and extremely robust and useful approach would
be to allow implied client protocol version indication through presence of
TLSv1.2-only cipher suite codepoints and this would allow large parts
of the installed base to quickly start using TLSv1.2--without breaking
existing usage scenarios and without the hazzle for users having to opt-in
and test stuff.


-Martin


From nobody Tue May 30 14:38:10 2017
Return-Path: 
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 3BB1C127F0E for ; Tue, 30 May 2017 14:38:08 -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 (2048-bit key) header.d=google.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 jTygyBM7gRXt for ; Tue, 30 May 2017 14:38:05 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588C8124D37 for ; Tue, 30 May 2017 14:38:05 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id u75so79503141qka.3 for ; Tue, 30 May 2017 14:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fgcAQ9B19jVcQY5Z5l9hoa1c+hlNhMu1GHu17eLBEy8=; b=m5TFTaictONYtswPidC6AAZy/50+MANxUZldEcgLfW0edj8n9YjIRNPZnWf6iLBALy m0SCDruHZFX7sPVBvzZndahX2LJptp8uFRpJiLCeNcTyjOjivuO4Bl7Gqrl1T23haayv igcNfyvJ76P6fJ+togHV1dZP4rEDaHzc9NfKTdjJ5j3SLu0s6D13L4iBW2f8bwlLY2dX xdHvgzft2cntH4NXjF34bOtENOhiP7calHDat2GF8BvVlp6qZGD9apdgNO2tvUKsibQX 55+C7QklR277qWz2mDG+xXmNknBXZW3JnRpWK8mbJuim2A1O9oeF1cNNtyNDVDLUmsvq 06SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fgcAQ9B19jVcQY5Z5l9hoa1c+hlNhMu1GHu17eLBEy8=; b=J/kqq6f5f1wJn/Y+I+ApDghSrB0nzwhW6oKlsIer7bxeLSTFly+Z/v/BycCU2xPeN6 CpMfZSFEeqFB810jCCT0zfgVKXW0QqFWtONT0mdZx40+fz3xVAMUt7x/185ZltIw47y8 W9sihoznLeXKZW+5edLgtLm6jh8zCuiAkc5NI7AH0mrnqhq2e3wz/eyGOYizJ0oDKdMa fEia73xlGMXI/eW4knMUvxhhFb6AbsyncVZeZjBYEW0fD48WRF93Cszyr/HO44Q8OwDi uXy+mAAapYTn424XuXtkBOGzbBjCCcT187HWUUv7GJkR5MsBOnTtdxgdXlSIAOLDztgh JJjg==
X-Gm-Message-State: AODbwcB/fqltHE2PNmO/W+9R0Czb5uS23vSSH9h4CPUUMkjs0LRq002P 21C7EJvPKP4dMI10u1vaQINUWc5pvRmM
X-Received: by 10.55.16.206 with SMTP id 75mr11342546qkq.81.1496180283975; Tue, 30 May 2017 14:38:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.76.70 with HTTP; Tue, 30 May 2017 14:38:02 -0700 (PDT)
In-Reply-To: 
References: 
From: Victor Vasiliev 
Date: Tue, 30 May 2017 17:38:02 -0400
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1146cb2058f0cc0550c49e47"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 21:38:08 -0000

--001a1146cb2058f0cc0550c49e47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Colm,

Thank you for your analysis!  I appreciate the attention to the security
properties of the 0-RTT requests, as it is the more delicate part of the
protocol.  It took me a while to get through the entire review, and there
are
many things on which I would like to comment, but if I do that for every
one of
them, this reply would be too long.  Hence, I=E2=80=99ll try to concentrate=
 on the
key
points.

1) The security of a system is an end-to-end property.

TLS isn=E2=80=99t a magical =E2=80=9Ctransport security solution=E2=80=9D, =
it provides a very
specific
set of explicit security guarantees to the applications that use it.  It
can be
used as a building block for the secure systems, but at the end of the day,
the
security of a system hinges on the designers=E2=80=99 understanding of the =
security
contracts provided by individual components.

TLS 1.3 as-is does not remove any of the replay protection guarantees
provided
by TLS 1.2.  However, if the user chooses to waive said protection in order
to
do 0-RTT, they can do that with an API explicitly designed for that purpose=
.

What I believe is important here is that we are very explicit about the
security
guarantees the application is expected to get from TLS.  PR#1005 currently
does
not answer this question in a satisfying manner, since it says that the
server
SHOULD implement three different mechanisms with very different
properties.  If
we provide any replay protection at all, it needs to be well-defined as a
security property.  That is,

2) We have to define explicitly what security properties TLS 0-RTT has.

There are two obvious levels of protection we can provide:

 A. No protection.  Applications are expected to handle idempotency
themselves,
    which is something they already probably should be doing anyways.

 B. Full protection.  Applications can rely on the assumption that once
data is
    written to TLS stack, it will arrive to the receiver at most once, and
TLS
    will enforce that even in presence of passive and active attackers on
the
    path.

I think all of us agree is that we should go for level B if we can have
it.  The
=E2=80=9Cif=E2=80=9D here is important, since...

3) Full replay protection for 0-RTT is not realistically feasible at TLS
layer,
   because TLS layer is not the right place for that.

You=E2=80=99ve already pointed out the existence of the DKG attack, where t=
he
attacker
forces the client to retry the request with 1-RTT.  In this scenario, the
attacker has a buffered 0-RTT request and is ready to insert it at any
convenient point in time, violating the initial order assumptions.

There is also a wide variety of cases in which a web browser or an HTTP
proxy
can be induced to retry a request, with mechanism often as simple as a TCP
RST.
Even if browser will refuse to do that, most users will =E2=80=9Creload=E2=
=80=9D themselves.
This is why the applications *need* to protect against replays end-to-end -=
-
asking users to roll back an extra $1000 transaction is not actually
acceptable.

With respect to the non-browser HTTP applications, I am not sure I am sold
on
the notion of =E2=80=9Ccareful clients=E2=80=9D.  My understanding is that =
you suggest to
treat
0-RTT failure as semantically equivalent to a regular connection failure,
under
the assumption that all of your clients already have to handle that case
properly.  I see how this is supposed to work out, but most systems of this
nature work well because connections succeed most of the time -- and as you
go
more and more towards the path of promising full replay protection, you wil=
l
break more and more 0-RTT handshakes.  Both session resumption in general
and
0-RTT in particular are designed with assumption that they can be declined
at
any point, that this is a normal and expected event, and at worst it would
result in a minor performance degradation; =E2=80=9Ccareful clients=E2=80=
=9D violate that
assumption.

As for the non-HTTP applications, that would have to be determined by their
respective application profiles, but I suspect they are going to be less
complex.  For example, I expect 0-RTT for SMTP to be as simple as just
sending
=E2=80=9CEHLO mail.example.org\n=E2=80=9D, which can be replayed regardless=
.

My key point here is that the problem of protecting against duplicate
messages
in a system is sufficiently complex that it can only be reliably solved
end-to-end.

(In fact, the original End-to-End Argument paper also considers that case:
=E2=80=9Cif
the application level has to have a duplicate-suppressing mechanism anyway,
that
mechanism can also suppress any duplicates generated inside the
communication
network, so the function can be omitted from that lower level.=E2=80=9D [Sa=
ltzer et
al.,
1981] -- here, I suggest to think of the =E2=80=9Ccommunication network=E2=
=80=9D as the
system
of HTTP-layer boxes and middleware that modern systems are made of.)

------------

So, I hope we can agree that we cannot really guarantee B.  There is
another,
third level of protection that surprisingly is worth considering:

  C. =E2=80=9CNebulous=E2=80=9D replay bound.  0-RTT data can be replayed, =
but only for some
      finitely bounded number of times.  I initially wanted to call this
=E2=80=9Cweak
      replay protection=E2=80=9D, but that felt too generous.

Normally I would dismiss this as a useful security property due to its
inherent
vagueness, for the same reasons that =E2=80=9Cyour server is too far away f=
or
nanosecond-level timing attacks on Intel CPUs=E2=80=9D is a property that n=
o serious
cryptographer would admit in a research paper.  However, you=E2=80=99ve poi=
nted out
some
interesting side channel leaks, which exist even without 0-RTT, but can be
amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is
a
meaningful property to provide.

Let=E2=80=99s talk about what mechanisms are and are not viable for the neb=
ulous
bound
promise.

4) Operational experience on datacenter-local strike registers is negative.

We deployed strike registers in the initial QUIC deployment, and it was an
operational hassle, so once we discovered that they do not provide full
replay
protection (due to all issues outlined above), the cost/benefit analysis
became
decidedly not in their favor.

Our deployment experience also suggests that the negative impact from
limiting
0-RTT to the same datacenter is not negligible.

I feel like you are underestimating the cost and complexity of the
distributed
solutions proposed:
 - RAM might be cheap in a big datacenter, but on a CDN node, the
opportunity
   cost of not using that RAM for something else is higher.
 - There is nothing simple about running distributed storage, given that on
top
   of usual operational requirements (ability to rescale and some degree of
   fault tolerance), you also require an atomic read-and-delete.
 - Strike registers with strong guarantees are probably even worse in that
   regard, since inserting a strike record requires a consistent write.

5) Nebulous replay bounds are possible but very much deployment-dependant.

If your deployment consists of one server that can accept a given ticket,
you
can just run a single strike register in memory.  Not particularly painful,
and
solves the problem for simple deployments.

If you wish to accept tickets across multiple servers, to improve 0-RTT
rate,
now we have the tension between wanting cross-server 0-RTT and avoiding
distributed cross-server state. But if your servers are individually
addressable, we can put the client-presumed server IP into the ClientHello
and
use machine-local strike registers. Servers decline 0-RTT if the
client-supplied
IP does not match.  This gives us global replay protection without the need
to
share state.

If you are using QUIC, any of your IPs is terminated by the same load
balancer,
and the load balancers use connection ID to pick the backend, you will also
normally arrive at the same TLS server provided that the server pool was no=
t
resharded.  At that point, local strike register is sufficient; in fact, if
you
have a time-wait list, you get it almost for free.

Of course, this all relies on resumption arriving to the same server as the
original request.  This is obviously not a property you want in a
large-scale
reliable systems, so as soon as you introduce anycast IP addresses or load
balancing based on parameters that are not bound cryptographically, you=E2=
=80=99ll
need
a strike register of a scope larger than a machine, so you have to either
make
one (since we only promising nebulous bounds, this can be eventually
consistent).  Or you could just settle for server-local strike registers --
since we=E2=80=99ve already decided that the bounds are nebulous, and I see=
 no
point of
haggling on how many replays is too many.

I feel like the topic of =E2=80=9Chow do I make the lowest nebulous replay =
bound
with
the lowest amount of effort=E2=80=9D is very large on its own, and is hones=
tly not
that
important for the protocol design.  The client=E2=80=99s ability to specify=
 the
presumed
server=E2=80=99s IP address is nice, and it would require a new extension i=
n the
specification itself, but that would be as far as I would go.  What=E2=80=
=99s
important
is that we can require implementations to provide nebulous bounds.  We of
course
should, on top of that, require clients and endorse servers to enforce the
application-level requirements on idempotence.

------------

Specific proposals I would like to make for TLS 1.3 draft based on the
discussion above:
 1. Emphasize that 0-RTT data is fundamentally replayable, and can be
replayed
    by the attacker at a convenient point.
 2. Replace the current suggestion to use specific mechanisms with a generi=
c
    requirement to provide the =E2=80=9Cnebulous bound=E2=80=9D for replays=
 (terminology up
to
    your preference).
 3. Leave the exact details of how said bound is achieved up to the
    implementations, but point out that time-based replay protection is not
    sufficient.  It might be worth to keep the current discussion of
particular
    mechanisms as an appendix.
 4. Add a =E2=80=9Cserver IP=E2=80=9D extension to the 0-RTT ClientHello, w=
hile we are at
it.

  -- Victor.

--001a1146cb2058f0cc0550c49e47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Colm,

<=
div class=3D"gmail_extra">Thank you for your analysis!=C2=A0 I appreciate t=
he attention to the security
properties of =
the 0-RTT requests, as it is the more delicate part of the
protocol.=C2=A0 It took me a while to get through the enti=
re review, and there are
many things on whi=
ch I would like to comment, but if I do that for every one of
them, this reply would be too long.=C2=A0 Hence, I=E2=80=
=99ll try to concentrate on the key
points.=


1) Th=
e security of a system is an end-to-end property.

TLS isn=E2=80=99t a magical =E2=
=80=9Ctransport security solution=E2=80=9D, it provides a very specific
set of explicit security guarantees to the app=
lications that use it.=C2=A0 It can be
used=
 as a building block for the secure systems, but at the end of the day, the=

security of a system hinges on the designe=
rs=E2=80=99 understanding of the security
c=
ontracts provided by individual components.

TLS 1.3 as-is does not remove any of =
the replay protection guarantees provided
b=
y TLS 1.2.=C2=A0 However, if the user chooses to waive said protection in o=
rder to
do 0-RTT, they can do that with an =
API explicitly designed for that purpose.
<=
br>
What I believe is important here is tha=
t we are very explicit about the security
g=
uarantees the application is expected to get from TLS.=C2=A0 PR#1005 curren=
tly does
not answer this question in a sati=
sfying manner, since it says that the server
SHOULD implement three different mechanisms with very different propertie=
s.=C2=A0 If
we provide any replay protectio=
n at all, it needs to be well-defined as a
=
security property.=C2=A0 That is,

2) We have to define explicitly what security p=
roperties TLS 0-RTT has.

There are two obvious levels of protection we can provid=
e:

=C2=
=A0A. No protection.=C2=A0 Applications are expected to handle idempotency =
themselves,
=C2=A0 =C2=A0 which is somethin=
g they already probably should be doing anyways.

=C2=A0B. Full protection.=C2=A0 =
Applications can rely on the assumption that once data is
=C2=A0 =C2=A0 written to TLS stack, it will arrive to the =
receiver at most once, and TLS
=C2=A0 =C2=
=A0 will enforce that even in presence of passive and active attackers on t=
he
=C2=A0 =C2=A0 path.

I think all of us agree is=
 that we should go for level B if we can have it.=C2=A0 The
=E2=80=9Cif=E2=80=9D here is important, since...

3) Full replay =
protection for 0-RTT is not realistically feasible at TLS layer,
=C2=A0 =C2=A0because TLS layer is not the right place=
 for that.

You=E2=80=99ve already pointed out the existence of the DKG attack, wh=
ere the attacker
forces the client to retry=
 the request with 1-RTT.=C2=A0 In this scenario, the
attacker has a buffered 0-RTT request and is ready to insert it a=
t any
convenient point in time, violating t=
he initial order assumptions.

There is also a wide variety of cases in which a we=
b browser or an HTTP proxy
can be induced t=
o retry a request, with mechanism often as simple as a TCP RST.
Even if browser will refuse to do that, most users wil=
l =E2=80=9Creload=E2=80=9D themselves.
This=
 is why the applications *need* to protect against replays end-to-end --
asking users to roll back an extra $1000 tran=
saction is not actually acceptable.

With respect to the non-browser HTTP applicat=
ions, I am not sure I am sold on
the notion=
 of =E2=80=9Ccareful clients=E2=80=9D.=C2=A0 My understanding is that you s=
uggest to treat
0-RTT failure as semantical=
ly equivalent to a regular connection failure, under
the assumption that all of your clients already have to handle th=
at case
properly.=C2=A0 I see how this is s=
upposed to work out, but most systems of this
nature work well because connections succeed most of the time -- and as =
you go
more and more towards the path of pr=
omising full replay protection, you will
br=
eak more and more 0-RTT handshakes.=C2=A0 Both session resumption in genera=
l and
0-RTT in particular are designed with=
 assumption that they can be declined at
an=
y point, that this is a normal and expected event, and at worst it would
result in a minor performance degradation; =
=E2=80=9Ccareful clients=E2=80=9D violate that
assumption.

As for the non-HTTP applications, that would have to be determine=
d by their
respective application profiles,=
 but I suspect they are going to be less
co=
mplex.=C2=A0 For example, I expect 0-RTT for SMTP to be as simple as just s=
ending
=E2=80=9CEHLO mail.example.org\n=E2=80=9D, which can be replayed regard=
less.

=
My key point here is that the problem of protecting against duplicate messa=
ges
in a system is sufficiently complex tha=
t it can only be reliably solved
end-to-end=
.

(In =
fact, the original End-to-End Argument paper also considers that case: =E2=
=80=9Cif
the application level has to have =
a duplicate-suppressing mechanism anyway, that
mechanism can also suppress any duplicates generated inside the communi=
cation
network, so the function can be omit=
ted from that lower level.=E2=80=9D [Saltzer et al.,
1981] -- here, I suggest to think of the =E2=80=9Ccommunication n=
etwork=E2=80=9D as the system
of HTTP-layer=
 boxes and middleware that modern systems are made of.)

------------

So, I hope we can =
agree that we cannot really guarantee B.=C2=A0 There is another,
third level of protection that surprisingly is worth =
considering:

=C2=A0 C. =E2=80=9CNebulous=E2=80=9D replay bound. =C2=A00-RTT data =
can be replayed, but only for some
=C2=A0 =
=C2=A0 =C2=A0 finitely bounded number of times.=C2=A0 I initially wanted to=
 call this =E2=80=9Cweak
=C2=A0 =C2=A0 =C2=
=A0 replay protection=E2=80=9D, but that felt too generous.

Normally I would dism=
iss this as a useful security property due to its inherent
vagueness, for the same reasons that =E2=80=9Cyour server =
is too far away for
nanosecond-level timing=
 attacks on Intel CPUs=E2=80=9D is a property that no serious
cryptographer would admit in a research paper.=C2=A0 How=
ever, you=E2=80=99ve pointed out some
inter=
esting side channel leaks, which exist even without 0-RTT, but can be
=

amplified by replaying 0-RTT queries. C, like B,=
 mitigates this, so this is a
meaningful pr=
operty to provide.

Let=E2=80=99s talk about what mechanisms are and are not viabl=
e for the nebulous bound
promise.

4) Operational =
experience on datacenter-local strike registers is negative.

We deployed strike r=
egisters in the initial QUIC deployment, and it was an
operational hassle, so once we discovered that they do not prov=
ide full replay
protection (due to all issu=
es outlined above), the cost/benefit analysis became
decidedly not in their favor.
Our deployment experience also suggests t=
hat the negative impact from limiting
0-RTT=
 to the same datacenter is not negligible.
=

I feel like you are underestimating th=
e cost and complexity of the distributed
so=
lutions proposed:
=C2=A0- RAM might be chea=
p in a big datacenter, but on a CDN node, the opportunity
=C2=A0 =C2=A0cost of not using that RAM for something else=
 is higher.
=C2=A0- There is nothing simple=
 about running distributed storage, given that on top
=C2=A0 =C2=A0of usual operational requirements (ability to resca=
le and some degree of
=C2=A0 =C2=A0fault to=
lerance), you also require an atomic read-and-delete.
=C2=A0- Strike registers with strong guarantees are probably eve=
n worse in that
=C2=A0 =C2=A0regard, since =
inserting a strike record requires a consistent write.

5) Nebulous replay bounds =
are possible but very much deployment-dependant.

If your deployment consists of o=
ne server that can accept a given ticket, you
can just run a single strike register in memory.=C2=A0 Not particularly =
painful, and
solves the problem for simple =
deployments.

If you wish to accept tickets across multiple servers, to improve 0-=
RTT rate,
now we have the tension between w=
anting cross-server 0-RTT and avoiding
dist=
ributed cross-server state. But if your servers are individually
addressable, we can put the client-presumed server IP=
 into the ClientHello and
use machine-local=
 strike registers. Servers decline 0-RTT if the client-supplied
IP does not match.=C2=A0 This gives us global replay p=
rotection without the need to
share state.<=
/div>

If you=
 are using QUIC, any of your IPs is terminated by the same load balancer,
and the load balancers use connection ID to =
pick the backend, you will also
normally ar=
rive at the same TLS server provided that the server pool was not
resharded.=C2=A0 At that point, local strike registe=
r is sufficient; in fact, if you
have a tim=
e-wait list, you get it almost for free.
Of course, this all relies on resumption=
 arriving to the same server as the
origina=
l request.=C2=A0 This is obviously not a property you want in a large-scale=

reliable systems, so as soon as you introd=
uce anycast IP addresses or load
balancing =
based on parameters that are not bound cryptographically, you=E2=80=99ll ne=
ed
a strike register of a scope larger than=
 a machine, so you have to either make
one =
(since we only promising nebulous bounds, this can be eventually
consistent).=C2=A0 Or you could just settle for serve=
r-local strike registers --
since we=E2=80=
=99ve already decided that the bounds are nebulous, and I see no point of
haggling on how many replays is too many.

I feel l=
ike the topic of =E2=80=9Chow do I make the lowest nebulous replay bound wi=
th
the lowest amount of effort=E2=80=9D is =
very large on its own, and is honestly not that
important for the protocol design.=C2=A0 The client=E2=80=99s ability =
to specify the presumed
server=E2=80=99s IP=
 address is nice, and it would require a new extension in the
specification itself, but that would be as far as I woul=
d go.=C2=A0 What=E2=80=99s important
is tha=
t we can require implementations to provide nebulous bounds.=C2=A0 We of co=
urse
should, on top of that, require client=
s and endorse servers to enforce the
applic=
ation-level requirements on idempotence.
------------

Specific proposals I would like t=
o make for TLS 1.3 draft based on the
discu=
ssion above:
=C2=A01. Emphasize that 0-RTT =
data is fundamentally replayable, and can be replayed
=C2=A0 =C2=A0 by the attacker at a convenient point.
=C2=A02. Replace the current suggestion to use specifi=
c mechanisms with a generic
=C2=A0 =C2=A0 r=
equirement to provide the =E2=80=9Cnebulous bound=E2=80=9D for replays (ter=
minology up to
=C2=A0 =C2=A0 your preferenc=
e).
=C2=A03. Leave the exact details of how=
 said bound is achieved up to the
=C2=A0 =
=C2=A0 implementations, but point out that time-based replay protection is =
not
=C2=A0 =C2=A0 sufficient.=C2=A0 It migh=
t be worth to keep the current discussion of particular
=C2=A0 =C2=A0 mechanisms as an appendix.
=C2=A04. Add a =E2=80=9Cserver IP=E2=80=9D extension to the 0-RT=
T ClientHello, while we are at it.

=C2=A0 -- Victor.



--001a1146cb2058f0cc0550c49e47--


From nobody Tue May 30 15:32:29 2017
Return-Path: 
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 ECD7C129473 for ; Tue, 30 May 2017 15:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vr6SYWdYdY7r for ; Tue, 30 May 2017 15:32:26 -0700 (PDT)
Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D6A12946B for ; Tue, 30 May 2017 15:32:26 -0700 (PDT)
Received: by mail-qt0-x244.google.com with SMTP id l39so14133393qtb.1 for ; Tue, 30 May 2017 15:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=dj3a8qiIOQPZ0anTsBzFog7ywdLykFnE6Gw6Rgser9o=; b=BjTnfVItesEo+YBqTz1vSFZxWA3pzu9C3k6zwee2Uc9FxwtAXBi5yMH1GzJfCvIotH 8mZBz8NrAfg9kD79IxjlDuUFyS37zJ0tFNAHIsknitRAyYxoQrzi0WjkIqIzE/ap+YsL 8gDTlxkF0Rs0qfsGgEWn/Qr3JsPvqbg/BLP/HN/Y/60NxTdy7eP7rIyY4hUXbUxUN1DM 1JrTA1ijne+kzzTm3Vy+7d702JTrnC2eaFPZpBr3VE9n5QHTjbYJ7PwHKdcL+eT1AiYW NwSca4eIOie5nke1u9TuW9zBA/04h0/66udfzy85mZ1QdKBWXyud8NHshNDki3JXibXh 1yJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=dj3a8qiIOQPZ0anTsBzFog7ywdLykFnE6Gw6Rgser9o=; b=G+vr69v/TLu2O/f/8ZGShIFmkKsiuNet00TVPRnWw+Fdf+jZq09Jdo5UgZVB0H9R6q enY7H1M7xDRAfsi+0uhpn37OJKrGHlfXLQLuqKe4wCbTxhoo3tXMxerU+QFVn6klyORG TiwE/9AsHfdLee7BHXtLOu+HlcyNTFdzW80Wz8u6tglFRBrEa7MwwNlc/5VlExKWti6i r4uHhvT3Torktttcc8RXOcoE/rCtsbG+Fk3hEqccZtwbCgki/BqNcTQ1Uy2Yp2M4ejXz 8PTulICPZjp2SxoqRk15L1SaIXUk7gruvxvgQ64jKC0O5Xhf4tinL1Uv0ElKDwk1mfq4 7JoQ==
X-Gm-Message-State: AODbwcCmuj5LkvV+XVe/h5pijjQ+3fN2aJRjmNHfwUcYoU4YQBAoluvt TJlnqu1ZXcRZifcs
X-Received: by 10.200.3.195 with SMTP id z3mr28254329qtg.185.1496183545500; Tue, 30 May 2017 15:32:25 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-114.phlapa.fios.verizon.net. [71.185.36.114]) by smtp.gmail.com with ESMTPSA id u19sm9230371qtc.64.2017.05.30.15.32.24 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 30 May 2017 15:32:24 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Tue, 30 May 2017 18:32:22 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:  
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201705301832.23150.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 22:32:28 -0000

On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote:
> TLS isn=E2=80=99t a magical =E2=80=9Ctransport security solution=E2=80=9D=
, it provides a very specific
> set of explicit security guarantees to the applications that use it.  It =
can be
> used as a building block for the secure systems, but at the end of the da=
y, the
> security of a system hinges on the designers=E2=80=99 understanding of th=
e security
> contracts provided by individual components.
>=20
> TLS 1.3 as-is does not remove any of the replay protection guarantees pro=
vided
> by TLS 1.2.  However, if the user chooses to waive said protection in ord=
er to
> do 0-RTT, they can do that with an API explicitly designed for that purpo=
se.

+1; In fact, I'd suggest sticking this almost as-is into the spec somewhere.

>   C. =E2=80=9CNebulous=E2=80=9D replay bound.  0-RTT data can be replayed=
, but only for some
>       finitely bounded number of times.  I initially wanted to call this =
=E2=80=9Cweak
>       replay protection=E2=80=9D, but that felt too generous.
>=20
> Normally I would dismiss this as a useful security property due to its in=
herent
> vagueness, for the same reasons that =E2=80=9Cyour server is too far away=
 for
> nanosecond-level timing attacks on Intel CPUs=E2=80=9D is a property that=
 no serious
> cryptographer would admit in a research paper.  However, you=E2=80=99ve p=
ointed out some
> interesting side channel leaks, which exist even without 0-RTT, but can be
> amplified by replaying 0-RTT queries. C, like B, mitigates this, so this =
is a
> meaningful property to provide.
>=20
> Let=E2=80=99s talk about what mechanisms are and are not viable for the n=
ebulous
> bound promise.

There is one relatively straightforward mechanism for limiting 3rd party re=
play:
A 3rd party replaying 0-RTT PSK will fail to successfully complete the hand=
shake
(after 1-RTT), as it would generally have the identity/ticket but not the k=
ey
behind it (e.g. resumption_master_secret). The 0-RTT data will have already=
 been
processed, however a server detecting any PSK failure could then flag the
offending ticket/IP and reject all future 0-RTT attempts for some time peri=
od (e.g.
ticket lifetime). This would limit replays to one per server, or less if th=
is banned
0-RTT state is shared across servers. The notable problem with this mechani=
sm
is that a 0-RTT DDoS, could easily balloon the state size rather significan=
tly, if not
careful. Servers would have to be fine with budgeting resources for a nontr=
ivial
state in the event of attack, even if they don't need it during normal oper=
ation,
but that could at least be doable. A replay from the 1st party that is expe=
cted to
have the correct key/secret or from a 3rd party that has stolen it would no=
t be
mitigated by this system, but that's much harder for an attacker to attempt=
, at
least.


Dave


From nobody Tue May 30 18:56:24 2017
Return-Path: 
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 A66F0129C3E for ; Tue, 30 May 2017 18:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 y5r5HMFsAhBl for ; Tue, 30 May 2017 18:56:20 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1785129C46 for ; Tue, 30 May 2017 18:56:18 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id r66so633723yba.2 for ; Tue, 30 May 2017 18:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=07y+OaDSGAFIS6ej3v58FQmRCk49tQmOrNBnZaYnbRQ=; b=QvTZvwE7Fpk70+cyGrtz9r948Vhahjpd0y21VKZR/YHqnWj+yDvFN6jAUP49nuqPTM eiCVFFiQFriggIIHoNeHR37oIjs0vFsxXUVHwiJYB9lgdvJ6aLfMUjJMEyx5oyhpKtgM G9nabNckZXv6ecA37TkgfYrviQ6+BOMd4OFIYmwmkRfpp1ht1YWY5n+zjcf3m00AMYob uhwMwLcu6RD7JC0ayAC+zRf0WJrc9YUR1xalKxKg8spAwc/pPEBmABy2bW92a7CyvzLT 4tYyKIw48mtXfUr2XxqhRLXLHYM+Vvt66UicC/Xq6MsE1Fvo5sHmA+Qz/VALHHKzR+CG pF+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=07y+OaDSGAFIS6ej3v58FQmRCk49tQmOrNBnZaYnbRQ=; b=tUw1BFF3DScfW190sN23TWQ+MfvthLcOTkC2LjNj0HPfemDS22F3cFunR2LZ/FciBo khHprx9BVlW1YDM5Gm8THju+KspIchPnMS7Rc1ypbmvbSmYDdtTBaO/T3aZyoZf+9J7+ TPaYoUOzO2AEOGLKZ9iDD648Yw1p5Xz3rZ+R6jFT0qoZjHtrxpwVtH48QNYtQHfMfO6u LRh7Xi9ArBg08+ZJoh6sRHn/TcitZIG6LlgM6juPUaMu80DWiRjv6aKnLpLZ/g0UipMF vGFpXL3N8MdChAa/oicsyHlQ8xigDZ3hn1jcgU8eARZRHByIZ7CLAguiY48mm0TYdmZ3 xTHg==
X-Gm-Message-State: AODbwcCuUkwyqJBmCMaqCCJZBp49wTUm2YZwT+KFp+gP3veyQwbYgUAj GcIXT077ExHz2hvkZGoqJg1Zh5byXqpr/jo=
X-Received: by 10.37.16.212 with SMTP id 203mr53159710ybq.90.1496195778013; Tue, 30 May 2017 18:56:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Tue, 30 May 2017 18:56:16 -0700 (PDT)
In-Reply-To: 
References:  
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Tue, 30 May 2017 18:56:16 -0700
Message-ID: 
To: Victor Vasiliev 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11c0ff04dd39620550c83937"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 01:56:23 -0000

--001a11c0ff04dd39620550c83937
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 30, 2017 at 2:38 PM, Victor Vasiliev  wrote=
:

> Thank you for your analysis!  I appreciate the attention to the security
> properties of the 0-RTT requests, as it is the more delicate part of the
> protocol.  It took me a while to get through the entire review, and there
> are
> many things on which I would like to comment, but if I do that for every
> one of
> them, this reply would be too long.  Hence, I=E2=80=99ll try to concentra=
te on the
> key
> points.
>

Thanks too for reading and the response!


> TLS 1.3 as-is does not remove any of the replay protection guarantees
> provided
> by TLS 1.2.  However, if the user chooses to waive said protection in
> order to
> do 0-RTT, they can do that with an API explicitly designed for that
> purpose.
>

I don't think this holds true;  the signs are that browsers and servers
will enable by default, with well-meaning limits on the kinds of requests.
But in the real-world; it'll absolutely be enabled lots, that's the point
after all. I hope we can have pervasive 0-RTT. It'll be awesome, because
the speed of light sucks.


>
> 3) Full replay protection for 0-RTT is not realistically feasible at TLS
> layer,
>    because TLS layer is not the right place for that.
>
> You=E2=80=99ve already pointed out the existence of the DKG attack, where=
 the
> attacker
> forces the client to retry the request with 1-RTT.  In this scenario, the
> attacker has a buffered 0-RTT request and is ready to insert it at any
> convenient point in time, violating the initial order assumptions.
>

Yep, though as I point out too, I think the DKG attack is different from
other replay attacks in ways that matter. The only place that the DKG
attack can be mitigated is at application layer. The TLS APIs and different
streams are pointless here. And I think that's actually an ok trade-off for
some kinds of applications - I don't think it should be a blocker for
0-RTT.  I think we agree on all this.


> With respect to the non-browser HTTP applications, I am not sure I am sol=
d
> on
> the notion of =E2=80=9Ccareful clients=E2=80=9D. My understanding is that=
 you suggest to
> treat
>
0-RTT failure as semantically equivalent to a regular connection failure,
> under
> the assumption that all of your clients already have to handle that case
> properly.  I see how this is supposed to work out, but most systems of th=
is
> nature work well because connections succeed most of the time -- and as
> you go
> more and more towards the path of promising full replay protection, you
> will
> break more and more 0-RTT handshakes.  Both session resumption in general
> and
> 0-RTT in particular are designed with assumption that they can be decline=
d
> at
> any point, that this is a normal and expected event, and at worst it woul=
d
> result in a minor performance degradation; =E2=80=9Ccareful clients=E2=80=
=9D violate that
> assumption.
>

The careful client is just to illustrate what it takes to make a
replay-safe application on top of an eventually consistent data store model
(which isn't uncommon) ... I don't think it's that realistic either, but it
was to point out that separate streams don't help. Only timings do.


> 4) Operational experience on datacenter-local strike registers is negativ=
e.
>
> We deployed strike registers in the initial QUIC deployment, and it was a=
n
> operational hassle, so once we discovered that they do not provide full
> replay
> protection (due to all issues outlined above), the cost/benefit analysis
> became
> decidedly not in their favor.
>

The argument about operational inconvenience is irrelevant and dangerous.
It doesn't matter that it's hard. It doesn't matter how much it costs. It's
the cost of doing 0-RTT securely. Doing it insecurely should not be an
option, and shouldn't be something specified in an RFC.


> Our deployment experience also suggests that the negative impact from
> limiting
> 0-RTT to the same datacenter is not negligible.
>

This is the terribly false premise that gets to the heart of things. You
acknowledge yourself that there are attacks. Here you argue, essentially,
that it is too inconvenient to mitigate those attacks for users. I don't
think we can seriously take that approach.

If the methods are too inconvenient, the secure alternative is to not use
0-RTT at all.

The key phrase here "the negative impact from limiting 0-RTT to the same
datacenter is not negligible" is simply utterly the wrong way around. Yes,
it's true that fewer 0-RTT sections are accepted in a datacenter-local
system than if they are globally valid; but globally valid ones are not
secure; so what's the benefit of that comparison? It's not an alternative
we can responsibly consider. The only secure comparison is to not having
0-RTT at all. At least with datacenter local 0-RTT we do get /some/ 0-RTT.

So the statement should really be "Datacenter-local 0-RTT resumption allows
us to use 0-RTT at all, which is great, considering that it would otherwise
lead to side-channel and privacy-defeating attacks. What a sad world that
would be".

It's not useful to compare secure approaches to insecure ones, we can only
consider the former. AES-GCM is a lot slower and more expensive than RC4,
but I still have to use it.


> I feel like you are underestimating the cost and complexity of the
> distributed
> solutions proposed:
>  - RAM might be cheap in a big datacenter, but on a CDN node, the
> opportunity
>    cost of not using that RAM for something else is higher.
>  - There is nothing simple about running distributed storage, given that
> on top
>    of usual operational requirements (ability to rescale and some degree =
of
>    fault tolerance), you also require an atomic read-and-delete.
>  - Strike registers with strong guarantees are probably even worse in tha=
t
>    regard, since inserting a strike record requires a consistent write.
>

These really suck, I agree. This is why it's so vitally important that we
agree that 0-RTT sections "MUST" be non-replayable, precisely because this
false line of logic is so mentally tempting. And because a set of providers
may be willing to make the insecure trade-off, and risk creating a "race to
the bottom" that means all deployments end up with  these insecure
configurations.

--=20
Colm

--001a11c0ff04dd39620550c83937
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 30, 2017 at 2:38 PM, Victor Vasiliev <=
vasilvv@google.com<=
/a>> wrote:
Thank you =
for your analysis!=C2=A0 I appreciate the attention to the security
properties of the 0-RTT requests, as it is the=
 more delicate part of the
protocol.=C2=A0 =
It took me a while to get through the entire review, and there are
many things on which I would like to comment, but i=
f I do that for every one of
them, this rep=
ly would be too long.=C2=A0 Hence, I=E2=80=99ll try to concentrate on the k=
ey
points.

Thanks too for reading and the response!
=
=C2=A0
TLS 1.3 as-is does not =
remove any of the replay protection guarantees provided
by TLS 1.2.=C2=A0 However, if the user chooses to waive said p=
rotection in order to
do 0-RTT, they can do=
 that with an API explicitly designed for that purpose.

I don't think this holds true; =C2=
=A0the signs are that browsers and servers will enable by default, with wel=
l-meaning limits on the kinds of requests. But in the real-world; it'll=
 absolutely be enabled lots, that's the point after all. I hope we can =
have pervasive 0-RTT. It'll be awesome, because the speed of light suck=
s.=C2=A0
=C2=A0

=

3) Full replay protection for 0-RTT is not=
 realistically feasible at TLS layer,
=C2=
=A0 =C2=A0because TLS layer is not the right place for that.

You=E2=80=99ve alrea=
dy pointed out the existence of the DKG attack, where the attacker
forces the client to retry the request with 1-RTT.=
=C2=A0 In this scenario, the
attacker has a=
 buffered 0-RTT request and is ready to insert it at any
convenient point in time, violating the initial order assumpt=
ions.



=C2=A0
Our deployment experience also =
suggests that the negative impact from limiting
0-RTT to the same datacenter is not negligible.

This is the terribly false premise that g=
ets to the heart of things. You acknowledge yourself that there are attacks=
. Here you argue, essentially, that it is too inconvenient to mitigate thos=
e attacks for users. I don't think we can seriously take that approach.=
=C2=A0

If the methods are too inconvenient, the se=
cure alternative is to not use 0-RTT at all.=C2=A0

The key phrase here "the negative impact from limiting 0-RTT to the s=
ame datacenter is not negligible" is simply utterly the wrong way arou=
nd. Yes, it's true that fewer 0-RTT sections are accepted in a datacent=
er-local system than if they are globally valid; but globally valid ones ar=
e not secure; so what's the benefit of that comparison? It's not an=
 alternative we can responsibly consider. The only secure comparison is to =
not having 0-RTT at all. At least with datacenter local 0-RTT we do get /so=
me/ 0-RTT.=C2=A0

=


It's not useful to compare secure approaches to ins=
ecure ones, we can only consider the former. AES-GCM is a lot slower and mo=
re expensive than RC4, but I still have to use it.=C2=A0
=C2=A0
I feel like you are underestima=
ting the cost and complexity of the distributed
solutions proposed:
=C2=A0- RAM might =
be cheap in a big datacenter, but on a CDN node, the opportunity
=C2=A0 =C2=A0cost of not using that RAM for something=
 else is higher.
=C2=A0- There is nothing s=
imple about running distributed storage, given that on top
=C2=A0 =C2=A0of usual operational requirements (ability to=
 rescale and some degree of
=C2=A0 =C2=A0fa=
ult tolerance), you also require an atomic read-and-delete.
=C2=A0- Strike registers with strong guarantees are probab=
ly even worse in that
=C2=A0 =C2=A0regard, =
since inserting a strike record requires a consistent write.

These really suck, I agree. This =
is why it's so vitally important that we agree that 0-RTT sections &quo=
t;MUST" be non-replayable, precisely because this false line of logic =
is so mentally tempting. And because a set of providers may be willing to m=
ake the insecure trade-off, and risk creating a "race to the bottom&qu=
ot; that means all deployments end up with =C2=A0these insecure configurati=
ons.=C2=A0

-- 
=
Colm




--001a11c0ff04dd39620550c83937--


From nobody Wed May 31 02:32:40 2017
Return-Path: 
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 D48B3129510 for ; Wed, 31 May 2017 02:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 N_Qx3yJxsCkk for ; Wed, 31 May 2017 02:32:37 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC0C12950B for ; Wed, 31 May 2017 02:32:37 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 25429B81436; Wed, 31 May 2017 02:32:17 -0700 (PDT)
To: ekr@rtfm.com, nagendra@cs.stanford.edu, Kathleen.Moriarty.ietf@gmail.com,  ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: korte@easycrypt.de, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170531093217.25429B81436@rfc-editor.org>
Date: Wed, 31 May 2017 02:32:17 -0700 (PDT)
Archived-At: 
Subject: [TLS] [Editorial Errata Reported] RFC6347 (5026)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 09:32:39 -0000

The following errata report has been submitted for RFC6347,
"Datagram Transport Layer Security Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5026

--------------------------------------
Type: Editorial
Reported by: Timm Korte 

Section: 4.1

Original Text
-------------
   length
      Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
      the length should not exceed 2^14.

Corrected Text
--------------
   length
      Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
      the length MUST NOT exceed 2^14.

Notes
-----
The originial comment on length in RFC 5246, 6.2.1 is:
   length
      The length (in bytes) of the following TLSPlaintext.fragment.  The
      length MUST NOT exceed 2^14.
so it has to be "MUST NOT" - instead of "should not" as currently stated.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6347 (draft-ietf-tls-rfc4347-bis-06)
--------------------------------------
Title               : Datagram Transport Layer Security Version 1.2
Publication Date    : January 2012
Author(s)           : E. Rescorla, N. Modadugu
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Wed May 31 02:48:58 2017
Return-Path: 
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 C69891287A3 for ; Wed, 31 May 2017 02:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 KsRNIzUWiiOM for ; Wed, 31 May 2017 02:48:54 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A3EBC12704A for ; Wed, 31 May 2017 02:48:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5A2C527D85; Wed, 31 May 2017 12:48:53 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 9CUCYGMHRN3v; Wed, 31 May 2017 12:48:53 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 25A8F27F; Wed, 31 May 2017 12:48:53 +0300 (EEST)
Date: Wed, 31 May 2017 12:48:50 +0300
From: Ilari Liusvaara 
To: Victor Vasiliev 
Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" 
Message-ID: <20170531094850.GA7298@LK-Perkele-V2.elisa-laajakaista.fi>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 09:48:57 -0000

On Tue, May 30, 2017 at 05:38:02PM -0400, Victor Vasiliev wrote:



A couple points:

- Various mechanisms related to conserving IPv4 addresses can result
  client and server disagreeing about server IP address. Or even the
  address family.
- If one has limited number of replays, distributing those among
  multiple servers is the most dangerous.
- If you rely on sticky loadbalancer, you have to ensure that attacker
  can't send requests directly to the servers, bypassing the
  loadbalancer! In some architectures, it is rather easy to
  accidentially expose the backend servers, even if all the honest
  connections flow through the loadbalancer.
- Binders are computationally random, so if you want to shard on
  those for strike register, simple mod N scheme distributes the load
  well.
- 0-RTT scope can be written into tickets. The session ticket scope
  may be larger than that. Routing to datacenters should be relatively
  sticky.
- As noted, this mess with state is just necressary for security if
  you use 0-RTT.
- Could be good idea for clients to blacklist origins for tickets
  (meaning, use GDHE-CERT and possibly (GDHE-)static-PSK handshakes
  only) for some time if duplicate accepts are detected during
  grease testing. That should not cause any servers to actually
  break from user standpoint, since servers need to support those
  handshake modes anyway.


-Ilari


From nobody Wed May 31 09:36:31 2017
Return-Path: 
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 1A6121298BA for ; Wed, 31 May 2017 09:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.079
X-Spam-Level: 
X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 7uup69YPGaaw for ; Wed, 31 May 2017 09:36:27 -0700 (PDT)
Received: from 6.mo2.mail-out.ovh.net (6.mo2.mail-out.ovh.net [87.98.165.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879FA129BA4 for ; Wed, 31 May 2017 09:36:26 -0700 (PDT)
Received: from player157.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo2.mail-out.ovh.net (Postfix) with ESMTP id C93FC84B51 for ; Wed, 31 May 2017 18:36:24 +0200 (CEST)
Received: from [10.41.51.97] (130.163-14-84.ripe.coltfrance.com [84.14.163.130]) (Authenticated sender: contact@simonbernard.eu) by player157.ha.ovh.net (Postfix) with ESMTPSA id 6F99950007E for ; Wed, 31 May 2017 18:36:24 +0200 (CEST)
To: "tls@ietf.org" 
From: Simon Bernard 
Message-ID: 
Date: Wed, 31 May 2017 18:36:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 17368131965976262897
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 50
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeljedrgeeigddutdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucgoteefjeefqddtgeculdehtddm
Archived-At: 
Subject: [TLS] Stopping retransmission DTLS 1.2
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 16:36:30 -0000

Hi,

    The RFC6347, 4.2.4 [1] say :

         "3. The implementation receives the next flight of messages: if 
this
         is the final flight of messages, the implementation transitions to
         FINISHED. If the implementation needs to send a new flight, it
         transitions to the PREPARING state. Partial reads (whether
         partial messages or only some of the messages in the flight) do
         not cause state transitions or timer resets."

    I would like to know why "partial reads do not cause state timer 
resets".

    I mean if we receive the first "handshake message" of the expected 
"flight". we can assume that the foreign peer received our previous 
flight and so we can stop retransmissions of this flight.
    If the next message is lost, we will never respond and so the 
foreign peer should retransmit the whole flight. We don't need to 
retransmit on our side, so timer should be reset ?

    Did I missed something ?

Thx.

Simon

[1]https://tools.ietf.org/html/rfc6347#section-4.2.4


From nobody Wed May 31 12:49:09 2017
Return-Path: 
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 6D1CF124217 for ; Wed, 31 May 2017 12:49:08 -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 (2048-bit key) header.d=google.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 9F9o0z3VcJ5U for ; Wed, 31 May 2017 12:49:06 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DB81200C5 for ; Wed, 31 May 2017 12:49:06 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id d14so20629996qkb.1 for ; Wed, 31 May 2017 12:49:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L0wmzKABnpeO1sRKba73DKjZYhJcW9/DPOc4LW8JRqI=; b=GB8XMVvCIUX3HI/v4TVAY5BkpAWjvMUEOCev4OsyR2AQshgYo6CxFO9qzeoaoGZoUp YeWXIwP6QyyqXIEygK9Rsk4Cu8dgnGwdT1gGYn7KUfw5TyaVJ3zN5dSl9TYpCVj0kHru VV4irktNk74qC8GN582J42F/VsgnHYRHFugadpGdRVzpP36FXuJgoagpU2qWtbDd7mMC P/wS/GvnlFlaQr8ySKxnSuqkKkzuus2CFfcY/Cb27byKuH7RGfL8gi1NE72Oy01yEAGY 5geYse/Lva6vedBtWXZtgWAHapsPP1wH0HyJs9Z6wXyLbTU+CvXN4fWRIrM/jwZxiimX YKpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L0wmzKABnpeO1sRKba73DKjZYhJcW9/DPOc4LW8JRqI=; b=bsniFmhERYzXj4xAAiyeurUnDKUCkPxtZFFnnD2Rs2uLvkifOhRR0QXbIDZ5BR1sEs nVdYk7aZ+NW0iJt22m+u4ACxETFmNVrbMvRPfwmgKSAv0jHEo7rzYPbJnb1Wy+qrSGyC oj5mF3giA9YuhR05dnB8NOjCEmNMKpSZQv9K4AjlA8X5LiH+VDCxEVYkWweKhxuzJvl+ v1GH/oCGxZI0Qg91Alcz6iyW9pN3+lCk4hDBm73lBrgtKWuphgYkD7Chg4EYhcOKxxd/ 7SOTCXyUWttAaAN8cJ8g6JvZdlZPLDf3QUkSqHPno6e52fJeSaf3QpZ4qd0quPCFbDYP 8TvA==
X-Gm-Message-State: AODbwcBAmzcW/OPidfJs76JZl7E4WSlSwh59SES2AxoUM4L2EMkBPAoX S9AnCm/YRzFp2Bs4IUfeM65X3vpF2XkeV7MHDA==
X-Received: by 10.55.111.198 with SMTP id k189mr29946835qkc.160.1496260144939;  Wed, 31 May 2017 12:49:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.76.70 with HTTP; Wed, 31 May 2017 12:49:03 -0700 (PDT)
In-Reply-To: 
References:   
From: Victor Vasiliev 
Date: Wed, 31 May 2017 15:49:03 -0400
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c05b67c6f04380550d73687"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 19:49:08 -0000

--94eb2c05b67c6f04380550d73687
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 30, 2017 at 9:56 PM, Colm MacC=C3=A1rthaigh 
 wrote:

> Here you argue, essentially, that it is too inconvenient to mitigate thos=
e
> attacks for users. I don't think we can seriously take that approach.
>
> If the methods are too inconvenient, the secure alternative is to not use
> 0-RTT at all.
>
> [snip]
>

I think I am not getting my key point across here clearly.  I am not arguin=
g
that they are inconvenient, I am arguing that the guarantee you are trying
to
provide is impossible.

I wholeheartedly agree that if it is possible to provide guarantee B (zero
replays), we really should provide it.  The problem is, we cannot.  Since
0-RTT
is by its very design declinable, there will be always a possibility for at
least one retry.

Once you concede you can have at least one replay, the difference between
one
replay and N replays (for all N > 0) is not that large, which is why I
refer to
this as "nebulous bound" (guarantee C).  Your applications already have to
contend with replays, it's now just the matter of preventing side-channel
amplification.

So, in other words, since we're now just bargaining about the value of N,
operational concerns are a fair game.

TLS 1.3 as-is does not remove any of the replay protection guarantees
>> provided
>> by TLS 1.2.  However, if the user chooses to waive said protection in
>> order to
>> do 0-RTT, they can do that with an API explicitly designed for that
>> purpose.
>>
>
> I don't think this holds true;  the signs are that browsers and servers
> will enable by default, with well-meaning limits on the kinds of requests=
.
> But in the real-world; it'll absolutely be enabled lots, that's the point
> after all. I hope we can have pervasive 0-RTT. It'll be awesome, because
> the speed of light sucks.
>
>

To clarify, I am not suggesting that two streams would help.  I completely
agree with you that two streams is not going to mitigate the DKG attack or
others.  What I meant is that 0-RTT inherently has slightly different
properties from 1-RTT and must be used with that in mind.  Specifically, I
meant that it will not be enabled for applications by default, and HTTP
clients
would only allow it for methods that RFC 7231 defines as safe.



>> 3) Full replay protection for 0-RTT is not realistically feasible at TLS
>> layer,
>>    because TLS layer is not the right place for that.
>>
>> You=E2=80=99ve already pointed out the existence of the DKG attack, wher=
e the
>> attacker
>> forces the client to retry the request with 1-RTT.  In this scenario, th=
e
>> attacker has a buffered 0-RTT request and is ready to insert it at any
>> convenient point in time, violating the initial order assumptions.
>>
>
> Yep, though as I point out too, I think the DKG attack is different from
> other replay attacks in ways that matter.
>

I do not believe that this to be the case.  The DKG attack is an attack
that allows
for a replay.  There is an enormous difference between a protocol that does
not
allow replays and the protocol that allows one.  For many applications, it
only
takes one replay for things to go terribly wrong.


> The only place that the DKG attack can be mitigated is at application
> layer.
>

Indeed.


> The TLS APIs and different streams are pointless here.
>

I agree that different streams are pointless.  The only ways APIs can help
is
to not send replay-sensitive requests via 0-RTT, and to not accept those
requests until peer liveness is confirmed.


> And I think that's actually an ok trade-off for some kinds of application=
s
> - I don't think it should be a blocker for 0-RTT.  I think we agree on al=
l
> this.
>

I don't think this is an okay trade-off for any application that changes
state
-- in particular, I am strongly against sending POST requests over 0-RTT.
I do
agree, however, that ability to replay requests some bounded number of time=
s
should not preclude us from deploying 0-RTT.


> [snip]
>
> You acknowledge yourself that there are attacks.
>

Indeed, but I am not suggesting we ignore those attacks.  The way I see
this is
that, originally when we did 0-RTT in QUIC, we had strike registers which
are
approximately what you are advocating.  We thought this provided property B
(at-most-once semantics for 0-RTT), but at the IETF, people discovered the
DKG
attack.  Strike registers do not provide B and in fact B is impossible to
provide at the TLS layer.  Thus TLS 1.3 went towards A (no replay
protection at
all for 0-RTT), as it's simpler and we didn't have B anyway.

But, as you describe, this enables some interesting side channels. Now,
these
side channels exist even without 0-RTT.  Attackers already can measure
response
times, probe and groom caches, direct traffic, etc.  *But*, with unlimited
0-RTT replay, the attacker can repeat the experiment unboundedly and amplif=
y
the side channel.

Thus, A is problematic.  I think we both believe this and both agree then
that
the current text is unsatisfactory.  So the question is what to replace it
with.  Whatever we provide, it should be a clear security guarantee between
the
application and TLS (depending on what guarantee we chose, some of your
other
attacks may or may not just be invalid uses of TLS).  B is obviously
preferable, but as it is impossible per DKG, I think we should set the
contract
at C (bounded replay protection).  This is a guarantee that is not
fundamentally impossible and also successfully mitigates your side channel
amplification attacks.

  -- Victor.

--94eb2c05b67c6f04380550d73687
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 9:56 PM, Colm MacC=C3=A1rthaigh=C2=A0<colm@allcos=
ts.net>=C2=A0wrote:=C2=A0
Here you argue, essentially, that it is too inconveni=
ent to mitigate those attacks for users. I don't think we can seriously=
 take that approach.=C2=A0

If the methods are too =
inconvenient, the secure alternative is to not use 0-RTT at all.=C2=A0

[snip]

I think I am not getting my key point across here clearl=
y.=C2=A0 I am not arguing
that they are inconvenient, I am arguin=
g that the guarantee you are trying to
provide is impossible.

I wholeheartedly agree that if it is possible t=
o provide guarantee B (zero
replays), we really should provide it=
.=C2=A0 The problem is, we cannot.=C2=A0 Since 0-RTT
is by its ve=
ry design declinable, there will be always a possibility for at
l=
east one retry.

Once you concede you can have at l=
east one replay, the difference between one
replay and N replays =
(for all N > 0) is not that large, which is why I refer to
thi=
s as "nebulous bound" (guarantee C).=C2=A0 Your applications alre=
ady have to
contend with replays, it's now just the matter of=
 preventing side-channel
amplification.

=
So, in other words, since we're now just bargaining about the value of =
N,
operational concerns are a fair game.

TLS 1.3 as-is does not remove any of the replay=
 protection guarantees provided
by TLS 1.2.=
=C2=A0 However, if the user chooses to waive said protection in order to
do 0-RTT, they can do that with an API explic=
itly designed for that purpose.
I don't think this holds true; =C2=A0the signs are =
that browsers and servers will enable by default, with well-meaning limits =
on the kinds of requests. But in the real-world; it'll absolutely be en=
abled lots, that's the point after all. I hope we can have pervasive 0-=
RTT. It'll be awesome, because the speed of light sucks.=C2=A0
=C2=A0
=


To clarify, I am not suggesting that two streams w=
ould help.=C2=A0 I completely
agree with you that two streams is =
not going to mitigate the DKG attack or
others.=C2=A0 What I mean=
t is that 0-RTT inherently has slightly different
properties from=
 1-RTT and must be used with that in mind.=C2=A0 Specifically, I
=
meant that it will not be enabled for applications by default, and HTTP cli=
ents
would only allow it for methods that RFC 7231 defines as saf=
e.



=
3) Full replay protection for 0-RTT is not realistically feasible at TLS la=
yer,
=C2=A0 =C2=A0because TLS layer is not =
the right place for that.

You=E2=80=99ve already pointed out the existence of the=
 DKG attack, where the attacker
forces the =
client to retry the request with 1-RTT.=C2=A0 In this scenario, the
attacker has a buffered 0-RTT request and is ready=
 to insert it at any
convenient point in ti=
me, violating the initial order assumptions.

Yep, though as I point out too, I think th=
e DKG attack is different from other replay attacks in ways that matter.

I do not believe=
 that this to be the case.=C2=A0 The DKG attack is an attack that allows
for a replay.=C2=A0 There is an enormous difference between a proto=
col that does not
allow replays and the protocol that allows one.=
=C2=A0 For many applications, it only
takes one replay for things=
 to go terribly wrong.
=C2=A0
The only place that the DKG attack can be mitiga=
ted is at application layer.

<=
/div>
Indeed.
=C2=A0
The TLS APIs and different streams are pointless here.

I agree that diffe=
rent streams are pointless.=C2=A0 The only ways APIs can help is
=
to not send replay-sensitive requests via 0-RTT, and to not accept those
requests until peer liveness is confirmed.
=C2=A0
And I think that'=
;s actually an ok trade-off for some kinds of applications - I don't th=
ink it should be a blocker for 0-RTT.=C2=A0 I think we agree on all this.

I don't thi=
nk this is an okay trade-off for any application that changes state
-- in particular, I am strongly against sending POST requests over 0-RTT=
.=C2=A0 I do
agree, however, that ability to replay requests some=
 bounded number of times
should not preclude us from deploying 0-=
RTT.
=C2=A0
[snip]

You acknow=
ledge yourself that there are attacks.
=


Indeed, but I am not suggesting we ignore those at=
tacks.=C2=A0 The way I see this is
that, originally when we did 0=
-RTT in QUIC, we had strike registers which are
approximately wha=
t you are advocating.=C2=A0 We thought this provided property B
(=
at-most-once semantics for 0-RTT), but at the IETF, people discovered the D=
KG
attack.=C2=A0 Strike registers do not provide B and in fact B =
is impossible to
provide at the TLS layer.=C2=A0 Thus TLS 1.3 wen=
t towards A (no replay protection at
all for 0-RTT), as it's =
simpler and we didn't have B anyway.

But, as y=
ou describe, this enables some interesting side channels. Now, these
<=
div>side channels exist even without 0-RTT.=C2=A0 Attackers already can mea=
sure response
times, probe and groom caches, direct traffic, etc.=
 =C2=A0*But*, with unlimited
0-RTT replay, the attacker can repea=
t the experiment unboundedly and amplify
the side channel.
<=
div>
Thus, A is problematic.=C2=A0 I think we both believe th=
is and both agree then that
the current text is unsatisfactory.=
=C2=A0 So the question is what to replace it
with.=C2=A0 Whatever=
 we provide, it should be a clear security guarantee between the
=
application and TLS (depending on what guarantee we chose, some of your oth=
er
attacks may or may not just be invalid uses of TLS).=C2=A0 B i=
s obviously
preferable, but as it is impossible per DKG, I think =
we should set the contract
at C (bounded replay protection).=C2=
=A0 This is a guarantee that is not
fundamentally impossible and =
also successfully mitigates your side channel
amplification attac=
ks.

=C2=A0 -- Victor.


--94eb2c05b67c6f04380550d73687--


From nobody Wed May 31 13:45:50 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAA712943F; Wed, 31 May 2017 13:45:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.52.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149626354781.19809.15739337509507162566.idtracker@ietfa.amsl.com>
Date: Wed, 31 May 2017 13:45:47 -0700
Archived-At: 
Subject: [TLS] tls - New Meeting Session Request for IETF 99
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 31 May 2017 20:45:48 -0000

A new meeting session request has just been submitted by Joseph A. Salowey, a Chair of the tls working group.


---------------------------------------------------------
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Joseph Salowey

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: curdle uta acme cfrg httpbis rtcweb saag stir tcpinc tokbind perc quic
 Second Priority: sacm oauth



People who must be present:
  Eric Rescorla
  Stephen Farrell
  Sean Turner
  Joseph A. Salowey
  Kathleen Moriarty

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Wed May 31 13:52:07 2017
Return-Path: 
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 10D77129BAF for ; Wed, 31 May 2017 13:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 qy57NqXVF6Fb for ; Wed, 31 May 2017 13:52:02 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5262D128C83 for ; Wed, 31 May 2017 13:52:02 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id l14so12025810ywk.1 for ; Wed, 31 May 2017 13:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j7X6yODsQoYJDmeTwe3US42baeo0hoAV6IGXIfZb3rg=; b=TmdKyGom7Cef+FtdwWkXxPPBTtF9m6IGyjiPhhwdmT+QAjDWZ6yrHr3pIoDvskEHVj A+fD8+qPFgWBLbMj3ERKE1m+AYvI9uQ1C4oW/0xgoLFPgA9wQ06+6On7Qt7u8cORG0MI eI4Lcb7WSB1mHtvU4NDjL1uhxrfhDeTmn0e6THFqZrMctBtE2QsNmZjiDv4u1znHg42r ODU16PaTH7PUglNvXtDYY8GmwjEcSYeYUuxbSIpnpFhkIdJ2OCTGXmA/dB+FcVQ8jzzD wExYiUwfMqYlVJxuLzzGQGTtWbbiWe/qlhpi5bZ4oeWaI1A+MnMwTqEn9ZB5oVyGFCr/ ++ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j7X6yODsQoYJDmeTwe3US42baeo0hoAV6IGXIfZb3rg=; b=KTFNWJXxxF6UBkB50Y7PWS8cvAAy5DquRP9OoNrwFZsvp5PQ6RSxRbHgO38GoIFG7k ZBy0yi5kTD75WnaKKBgp0P5GjYzFQL2DjPhwIw5toYehEDs23DhJmhDcHloMc76qnNlc 8MWeFIBU2TNJI9G9XQ41o7TphtwmK80oejDnlSC4rlWKRfPrVRL9FWorry1Dg2qnDsW8 sJ5vQKNIsiPsDtiudJepAzUjaiv3l8ugIGapUmWKxsHulyu2di8AvX+dr/7UCPLEB4w2 uV3S1NYiYfg8NbPbhDBRDIwxizZpfLhtybGeSXorpEq3OLvLdQ04LtXjlArV8q2EEBoC b0kA==
X-Gm-Message-State: AODbwcC+uwasIFy/GxoKTt2nTk28ivmB0bIioCwzcuI1SnnlVSV9Ff1z xtS45nFFNMqwv54yJbbmlDm8OZ5l+t3a
X-Received: by 10.129.157.142 with SMTP id u136mr22817259ywg.323.1496263921534;  Wed, 31 May 2017 13:52:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Wed, 31 May 2017 13:52:00 -0700 (PDT)
In-Reply-To: 
References:    
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Date: Wed, 31 May 2017 13:52:00 -0700
Message-ID: 
To: Victor Vasiliev 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0b68aa88cf280550d817f4"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 20:52:05 -0000

--94eb2c0b68aa88cf280550d817f4
Content-Type: text/plain; charset="UTF-8"

On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev 
wrote:

> I think I am not getting my key point across here clearly.  I am not
> arguing
> that they are inconvenient, I am arguing that the guarantee you are trying
> to
> provide is impossible.
>
> I wholeheartedly agree that if it is possible to provide guarantee B (zero
> replays), we really should provide it.  The problem is, we cannot.  Since
> 0-RTT
> is by its very design declinable, there will be always a possibility for at
> least one retry.
>

This is the part we agree on; but as I've said before, the kinds of attacks
enabled by these kinds of client-initiated retries, and by
attacker-initiated replays are fundamentally different.


> Once you concede you can have at least one replay, the difference between
> one
> replay and N replays (for all N > 0) is not that large, which is why I
> refer to
> this as "nebulous bound" (guarantee C).
>

There's a very big difference and it leads to real-world attacks. With many
replays, all sorts of side-channel analyses become possible, and I've
provided examples. It's particularly nasty that the replays can be
out-of-bound and to arbitrary nodes of the attacker's choosing, which makes
the attacks even more effective.


> Your applications already have to
> contend with replays, it's now just the matter of preventing side-channel
> amplification.
>

Yes; applications using 0-RTT do have to make themselves retry-tolerant,
 as they already must in many scenarios (e.g. a browser driven
application).  What concerns me most here is that people are clearly being
confused by the TLS 1.3 draft into mis-understanding how this interacts
with 0-RTT. For example the X-header trick, to derive an idempotency token
from the binder, that one experimental deployment innovated doesn't
actually work because it doesn't protect against the DKG attack. We're
walking into rakes here.

So, in other words, since we're now just bargaining about the value of N,
> operational concerns are a fair game.
>

They're still not fair game imo, because there's a big difference between
permitting exactly
one duplicate, associated with a client-driven retry, and permitting huge
volumes of replays. They enable different kinds of attacks.

I keep forgetting about forward secrecy in all of this, but it's worth
noting that your argument for globally resumable sessions also implies that
we shouldn't really shoot for  FS for some of the most critical user data.
I also find that bizarre.

To clarify, I am not suggesting that two streams would help.  I completely
> agree with you that two streams is not going to mitigate the DKG attack or
> others.  What I meant is that 0-RTT inherently has slightly different
> properties from 1-RTT and must be used with that in mind.  Specifically, I
> meant that it will not be enabled for applications by default, and HTTP
> clients
> would only allow it for methods that RFC 7231 defines as safe.
>

Well in the real world, I think it'll be pervasive, and I even think it
/should/ be. We should make 0-RTT that safe and remove the sharp edges.

>
> I do not believe that this to be the case.  The DKG attack is an attack
> that allows
> for a replay.
>

It's not. It permits a retry. The difference here is that the client is in
full control. It can decide to delay, to change a unique request ID, or
even not to retry at all. But the legitimate client generated the first
attempt, it can be signaled that it wasn't accepted, and then it generates
the second attempt. If it really really needs to it can even reason about
the complicated semantics of the earlier request being possibly
re-submitted later by an attacker.

Replays are different though; the attacker just literally copies the data
and can resend and resend as desired. As I've shown; this breaks real-world
things like authenticated throttling systems, and leads to side-channel and
cache analysis; where only very rarely is one attempt sufficient to
exploit.


> There is an enormous difference between a protocol that does not
> allow replays and the protocol that allows one.  For many applications, it
> only
> takes one replay for things to go terribly wrong.
>
>
>> The only place that the DKG attack can be mitigated is at application
>> layer.
>>
>
> Indeed.
>
>
>> The TLS APIs and different streams are pointless here.
>>
>
> I agree that different streams are pointless.  The only ways APIs can help
> is
> to not send replay-sensitive requests via 0-RTT, and to not accept those
> requests until peer liveness is confirmed.
>

This puts a massive smile on my face :)

>
> Indeed, but I am not suggesting we ignore those attacks.  The way I see
> this is
> that, originally when we did 0-RTT in QUIC, we had strike registers which
> are
> approximately what you are advocating.
>

Well I'd really advocate for single-use caches, because I think Forward
Secrecy is important :)


> We thought this provided property B
> (at-most-once semantics for 0-RTT), but at the IETF, people discovered the
> DKG
> attack.  Strike registers do not provide B and in fact B is impossible to
> provide at the TLS layer.  Thus TLS 1.3 went towards A (no replay
> protection at
> all for 0-RTT), as it's simpler and we didn't have B anyway.
>

I think in retrospect this was rash :(


> But, as you describe, this enables some interesting side channels. Now,
> these
> side channels exist even without 0-RTT.  Attackers already can measure
> response
> times, probe and groom caches, direct traffic, etc.  *But*, with unlimited
> 0-RTT replay, the attacker can repeat the experiment unboundedly and
> amplify
> the side channel.
>

Exactly :) but also ... what about the attack on the throttling
infrastructure? or other resource exhaustion? 0-RTT replay seems like a
really big problem here and it seems like the most realistic kind of attack
too; booters and trouble-makers trying to lock each other out of systems.


Thus, A is problematic.  I think we both believe this and both agree then
> that
> the current text is unsatisfactory.  So the question is what to replace it
> with.  Whatever we provide, it should be a clear security guarantee
> between the
> application and TLS (depending on what guarantee we chose, some of your
> other
> attacks may or may not just be invalid uses of TLS).  B is obviously
> preferable, but as it is impossible per DKG, I think we should set the
> contract
> at C (bounded replay protection).  This is a guarantee that is not
> fundamentally impossible and also successfully mitigates your side channel
> amplification attacks.
>

I'm all for bounded replay protection, with the bounds being 1 ;-)

-- 
Colm

--94eb2c0b68aa88cf280550d817f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev <=
;vasilvv@google.com=
> wrote:
<=
div class=3D"gmail_extra">
=
I think I am not getting my key point across here clearly.=C2=A0 I am not a=
rguing
that they are inconvenient, I am argu=
ing that the guarantee you are trying to
provide is impossible.

I wholeheartedly agree that if it is possible=
 to provide guarantee B (zero
replays), we really should provide =
it.=C2=A0 The problem is, we cannot.=C2=A0 Since 0-RTT
is by its =
very design declinable, there will be always a possibility for at
least one retry.

=

This is the part we agree on; but as I've said before, the kinds o=
f attacks enabled by these kinds of client-initiated retries, and by attack=
er-initiated replays are fundamentally different.=C2=A0
=C2=A0
Once you concede you can have at le=
ast one replay, the difference between one
replay and N replays (=
for all N > 0) is not that large, which is why I refer to
this=
 as "nebulous bound" (guarantee C).=C2=A0
=


There's a very big difference an=
d it leads to real-world attacks. With many replays, all sorts of side-chan=
nel analyses become possible, and I've provided examples. It's part=
icularly nasty that the replays can be out-of-bound and to arbitrary nodes =
of the attacker's choosing, which makes the attacks even more effective=
.=C2=A0
=C2=A0
 Your ap=
plications already have to
contend with replays, it's now jus=
t the matter of preventing side-channel
amplification.

Yes; applications using=
 0-RTT do have to make themselves retry-tolerant, =C2=A0as they already mus=
t in many scenarios (e.g. a browser driven application).=C2=A0 What concern=
s me most here is that people are clearly being confused by the TLS 1.3 dra=
ft into mis-understanding how this interacts with 0-RTT. For example the X-=
header trick, to derive an idempotency token from the binder, that one expe=
rimental deployment innovated doesn't actually work because it doesn=
9;t protect against the DKG attack. We're walking into rakes here.=C2=
=A0

So, in other w=
ords, since we're now just bargaining about the value of N,
o=
perational concerns are a fair game.

They're still not fair game imo, because there&=
#39;s a big difference between permitting exactly
one duplica=
te, associated with a client-driven retry, and permitting huge volumes of r=
eplays. They enable different kinds of attacks.=C2=A0

<=
div>I keep forgetting about forward secrecy in all of this, but it's wo=
rth noting that your argument for globally resumable sessions also implies =
that we shouldn't really shoot for =C2=A0FS for some of the most critic=
al user data. I also find that bizarre. =C2=A0

To clarify, I am not suggesting that two strea=
ms would help.=C2=A0 I completely
agree with you that two streams=
 is not going to mitigate the DKG attack or
others.=C2=A0 What I =
meant is that 0-RTT inherently has slightly different
properties =
from 1-RTT and must be used with that in mind.=C2=A0 Specifically, I
<=
div>meant that it will not be enabled for applications by default, and HTTP=
 clients
would only allow it for methods that RFC 7231 defines as=
 safe.

Well i=
n the real world, I think it'll be pervasive, and I even think it /shou=
ld/ be. We should make 0-RTT that safe and remove the sharp edges.=C2=A0

<=
div>I do not believe that this to be the case.=C2=A0 The DKG attack is an a=
ttack that allows
for a replay.=C2=A0

It's not. It permits a retry. The di=
fference here is that the client is in full control. It can decide to delay=
, to change a unique request ID, or even not to retry at all. But the legit=
imate client generated the first attempt, it can be signaled that it wasn&#=
39;t accepted, and then it generates the second attempt. If it really reall=
y needs to it can even reason about the complicated semantics of the earlie=
r request being possibly re-submitted later by an attacker.=C2=A0

Replays are different though; the attacker just literally c=
opies the data and can resend and resend as desired. As I've shown; thi=
s breaks real-world things like authenticated throttling systems, and leads=
 to side-channel and cache analysis; where only very rarely is one attempt =
sufficient to exploit.=C2=A0
=C2=A0
 There is an enormous difference between a protocol that does =
not
allow replays and the protocol that allows one.=C2=A0 For man=
y applications, it only
takes one replay for things to go terribl=
y wrong.
=C2=A0
The only place that the DKG attack can be mit=
igated is at application layer.
Indeed.
=C2=A0
The TLS APIs and different strea=
ms are pointless here.

<=
/span>
I agree that different streams are pointless.=C2=A0 The onl=
y ways APIs can help is
to not send replay-sensitive requests via=
 0-RTT, and to not accept those
requests until peer liveness is c=
onfirmed.

Thi=
s puts a massive smile on my face :)
<=
div>
Indeed, but I am not suggesting we ignore those att=
acks.=C2=A0 The way I see this is
that, originally when we did 0-=
RTT in QUIC, we had strike registers which are
approximately what=
 you are advocating.=C2=A0
=


Well I'd really advocate for single-use caches, bec=
ause I think Forward Secrecy is important :)=C2=A0
=C2=A0
 We thought this provided property =
B
(at-most-once semantics for 0-RTT), but at the IETF, people dis=
covered the DKG
attack.=C2=A0 Strike registers do not provide B a=
nd in fact B is impossible to
provide at the TLS layer.=C2=A0 Thu=
s TLS 1.3 went towards A (no replay protection at
all for 0-RTT),=
 as it's simpler and we didn't have B anyway.

I think in retrospect this w=
as rash :(=C2=A0
=C2=A0
But, as you describe, this enables some interesting side channels. No=
w, these
side channels exist even without 0-RTT.=C2=A0 Attackers =
already can measure response
times, probe and groom caches, direc=
t traffic, etc. =C2=A0*But*, with unlimited
0-RTT replay, the att=
acker can repeat the experiment unboundedly and amplify
the side =
channel.

Exactly :) but also ... what about the attack on the throttling infrastru=
cture? or other resource exhaustion? 0-RTT replay seems like a really big p=
roblem here and it seems like the most realistic kind of attack too; booter=
s and trouble-makers trying to lock each other out of systems.=C2=A0
<=
div>

Thus=
, A is problematic.=C2=A0 I think we both believe this and both agree then =
that
the current text is unsatisfactory.=C2=A0 So the question is=
 what to replace it
with.=C2=A0 Whatever we provide, it should be=
 a clear security guarantee between the
application and TLS (depe=
nding on what guarantee we chose, some of your other
attacks may =
or may not just be invalid uses of TLS).=C2=A0 B is obviously
pre=
ferable, but as it is impossible per DKG, I think we should set the contrac=
t
at C (bounded replay protection).=C2=A0 This is a guarantee tha=
t is not
fundamentally impossible and also successfully mitigates=
 your side channel
amplification attacks.
=


I'm all for bounded replay=
 protection, with the bounds being 1 ;-)=C2=A0

--=
 
Colm=





--94eb2c0b68aa88cf280550d817f4--


From nobody Wed May 31 15:42:12 2017
Return-Path: 
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 F2B191267BB for ; Wed, 31 May 2017 15:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2JZ6MJ9L5EDR for ; Wed, 31 May 2017 15:42:09 -0700 (PDT)
Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407DA124D37 for ; Wed, 31 May 2017 15:42:09 -0700 (PDT)
Received: by mail-yb0-x232.google.com with SMTP id r66so7110184yba.2 for ; Wed, 31 May 2017 15:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nEnVuXUsdQUYFQGX2TReZfJavpgtd/9TxPkn7lV2pbc=; b=iTlR95bZuP89h8dyxri9Iw6IhWJdoNtceBgmVM/QsueImhkhU/a4ks4/IQZUFo5IhQ wdA9m0DpY6YUSltY3OFm/pYwaoRL3mUd+JPmthJANyxYmBpo3Pf9UI0YZxzXnKCbqIwJ IiRnoZ3FK5cbO4Y2raQrGkwhYqFoiAnn957g1NYL9jMGhMHu4z8f6z8G2yCs1hAb0L22 YkANNibYZvBfYd8uznz2bOuHiJj4AfnisgW0MgWNUxUGmox4oa5fEaPnygUFz7QdZLIu fi/7/I96qlfcuTkF/CljW7OhryabwiCeQ3pjJb8Csgu9dSmbemCs94gE/NcT61WFSKZn wOVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nEnVuXUsdQUYFQGX2TReZfJavpgtd/9TxPkn7lV2pbc=; b=GTQ12tEkUIzg/LKZ5v5B6ECDV+DF4ouaQ95VLyvu5vOC2MBPzfsxWA6Ok4c1JpW5lF AIEZAJ/Riw7qXzzFhwRUhie5vtJnbHDBj5m1+lQ6zG3MuXyUGxNIPpAuRxhMisCSK91A sot24etJ66hROJjG7PvfRN1Obs6Ba9wcU/crX/nEvIxnF9EbbvL2x4Ar/Fr6WhpNmkM1 qcPCOfzEBq+6VfBe8jG/fpeK7Hi1l2C9sDkf58QZfiKUt4eX+EZi9k4M7FCGP5Y3h4qm IiWKyZ/0M+gkvQgdkN9LPQzkcpShjRuyH7bw3EcQymyh86swn3fAQWC/XSpzQpmgVIiM 84Qg==
X-Gm-Message-State: AODbwcDOpOxbvWqRhemp75qcauuoglckkiRTSeYUdUfiRFHLfjayzDrY X4uACkaRjUKr31VQjt2SdOTnpn1PfGbA
X-Received: by 10.37.174.24 with SMTP id a24mr569606ybj.17.1496270528163; Wed, 31 May 2017 15:42:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.222.67 with HTTP; Wed, 31 May 2017 15:42:07 -0700 (PDT)
In-Reply-To: 
References:     
From: Bill Cox 
Date: Wed, 31 May 2017 15:42:07 -0700
Message-ID: 
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= 
Cc: Victor Vasiliev , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045da35852413f0550d9a14c"
Archived-At: 
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 22:42:11 -0000

--f403045da35852413f0550d9a14c
Content-Type: text/plain; charset="UTF-8"

I've looked at this issue from how this interacts with token binding.  The
layer above TLS (not quite what I would call the application layer) has to
know about the failed 0-RTT attempt so that it can update the token binding
headers in the HTTP request for the 1-RTT retry.  In particular, I want to
emulate a real proof-of-possession, which implies two things: uniqueness
and freshness of the signature.  With a single use cache, we can actually
ensure that the signature is unique, even with the DKG attack: the first
0-RTT flight and the second 1-RTT flight must contain unique TB signatures
in the TB headers.  The TB signature is non-replayable against servers
using 1-use caches.  We unfortunately still lack freshness, but I compare
this to the case of a session that never closed over the same period of
time.  Only one signature is required for this connection, which means the
signature is as stale as the connection.  I find it hard to justify the
need fore more freshness given this trade-off has already been made for
TB.  Uniqueness, however, is something that would be difficult to give up,
if we are to have TB at all for 0-RTT.

Traditional session caches are cheaper to build and maintain than strike
registers by a factor of several, for various reasons.  I feel strongly
that the default behavior of popular HTTP servers, when 0-RTT is enabled,
should be to enforce replay protection with a 1-use cache.  I would prefer
that the RFC wording be chosen to support this outcome.

Finally, it doesn't really make much difference whether we say that clients
SHOULD or MUST use replay mitigation with 0-RTT.  Corporations often choose
to ignore MUST and treat it like SHOULD.  The EMS RFC is a great example.
If we took MUST seriously, the EMS spec would break the web.  No one,
SFAIK, implemented all of EMS's MUST clauses.  The Code is more what you
call guidelines, than actual rules.

Bill

--f403045da35852413f0550d9a14c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I've looked at this issue f=
rom how this interacts with token binding.=C2=A0 The layer above TLS (not q=
uite what I would call the application layer) has to know about the failed =
0-RTT attempt so that it can update the token binding headers in the HTTP r=
equest for the 1-RTT retry.=C2=A0 In particular, I want to emulate a real p=
roof-of-possession, which implies two things: uniqueness and freshness of t=
he signature.=C2=A0 With a single use cache, we can actually ensure that th=
e signature is unique, even with the DKG attack: the first 0-RTT flight and=
 the second 1-RTT flight must contain unique TB signatures in the TB header=
s.=C2=A0 The TB signature is non-replayable against servers using 1-use cac=
hes.=C2=A0 We unfortunately still lack freshness, but I compare this to the=
 case of a session that never closed over the same period of time.=C2=A0 On=
ly one signature is required for this connection, which means the signature=
 is as stale as the connection.=C2=A0 I find it hard to justify the need fo=
re more freshness given this trade-off has already been made for TB.=C2=A0 =
Uniqueness, however, is something that would be difficult to give up, if we=
 are to have TB at all for 0-RTT.

Traditional session caches are cheaper to build=
 and maintain than strike registers by a factor of several, for various rea=
sons.=C2=A0 I feel strongly that the default behavior of popular HTTP serve=
rs, when 0-RTT is enabled, should be to enforce replay protection with a 1-=
use cache.=C2=A0=C2=A0I would prefer that the RFC wording be chosen to supp=
ort this outcome.

Finally, it doesn't really make much difference whether we =
say that clients SHOULD or MUST use replay mitigation with 0-RTT.=C2=A0 Cor=
porations often choose to ignore MUST and treat it like SHOULD.=C2=A0 The E=
MS RFC is a great example.=C2=A0 If we took MUST seriously, the EMS spec wo=
uld break the web.=C2=A0 No one, SFAIK, implemented all of EMS's MUST c=
lauses.=C2=A0 The Code is more what you call guidelines, than actual rules.=


Bill<=
br>


--f403045da35852413f0550d9a14c--


From nobody Wed May 31 19:41:19 2017
Return-Path: 
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 E994C129C30; Wed, 31 May 2017 19:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7gnVGAlsOVxA; Wed, 31 May 2017 19:41:16 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F3C129B5C; Wed, 31 May 2017 19:41:16 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id 9so24085387pfj.1; Wed, 31 May 2017 19:41:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KudiHAByJ9u9S8dut0xPUNX/0NiNmk4Yfr+VLzj8Ytc=; b=edS8Ufv5+As2VaWzcc6F18NIA0mmdX5YCm2ECCgKPn8gqXjhwfEK7i3MMiFXOGaOLH AqhqweqWkSrP9SaYEPgWr5PpgKYJpDCTLCGvKouUiw4hMj/qYIkag7EGXJA9FUS2P6XY 6TNKF7GFyZUj6OqTkKgYxjuNGLVt1FYRYOGpqMMLzE1LM2F9hSR4AM7IK8K9ZLzawHsw ctXe6RgeO11bPQLk10P2+ZAfxoDXsgPtIGCGbubWCPMxRwmwGHfaG+Hovy8Si1uP7kpr IjBCSaP+Wfh028J4K1noF6BI4vm74yb/gtzkW4+QLHnug23k7gqm4qQnwoQbenBS3ErO 4lQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KudiHAByJ9u9S8dut0xPUNX/0NiNmk4Yfr+VLzj8Ytc=; b=N+Vlgye+WJ5Dya08jCKmlt586tz6ishNW/OnL92ewwFBO0jFAS2BdMDelmY8O96TqJ h0MJKC//dEqSiOLbrIdPlhDawA+tXoC3IPqUNy1UtumvdCVmQiXPvBHc6xhHjL4PikZQ JsZVJvBDesfNiX8UsEAE+oamGtNiVcN76zyg0XhUyUy4uP6OldHOwJddl2ugW5DVzbdI pQPvT+tYZJiJBwcvBYFAAOL5+5UsO89YW/MpxkNrJx1B4cPKMMv1d3myn4zlv1nGWKWT +XAUUMu5haU84rWbemDJDslwzq2GA+dnEnaQKaK21m0jKr/YY4ssQEegGCbx/pdZMLUc bSNA==
X-Gm-Message-State: AODbwcC40T/ktABiKlsTNDpEFd1Vm41PaHA8eiQYpywLmm0e0wPUkBJ2 C32Er9pek4FV1krE57FeG3Ef/LoG8A==
X-Received: by 10.84.224.1 with SMTP id r1mr92113460plj.78.1496284875702; Wed, 31 May 2017 19:41:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.207.228 with HTTP; Wed, 31 May 2017 19:41:15 -0700 (PDT)
In-Reply-To: <20170530200351.05F051A6AF@ld9781.wdf.sap.corp>
References:  <20170530200351.05F051A6AF@ld9781.wdf.sap.corp>
From: Watson Ladd 
Date: Wed, 31 May 2017 19:41:15 -0700
Message-ID: 
To: "mrex@sap.com" 
Cc: Eric Rescorla , tls-chairs , The IESG ,  draft-ietf-tls-ecdhe-psk-aead@ietf.org, "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Jun 2017 02:41:18 -0000

On Tue, May 30, 2017 at 1:03 PM, Martin Rex  wrote:
> Eric Rescorla wrote:
>> On Tue, May 23, 2017 at 9:34 PM, Martin Rex  wrote:
>>>
>>> This change _still_ prohibits the server from negotiating these algorithms
>>> with TLSv1.1 and below.
>>>
>>> Could you elaborate a little on where and why you see a problem with this?
>>>
>>
>> For starters, TLS 1.3 has already designed a completely independent
>> mechanism for doing version negotiation outside of ClientHello.version,
>> so doing another seems pretty odd. In any case, it's not something you
>> do between IETF-LC and IESG approval.
>
> The suggestion to accept a recognized TLSv1.2 cipher suite code point
> as an alternative indicator for the highest client-supported protocol
> version is not really a "mechanism".  It's efficient (with 0-bytes on
> the wire), intuitive and extremely backwards-compatible (will not upset
> old servers, neither version-intolerant as the Win2008/2012 servers,
> nor extension-intolerant servers.

It's a substantial change made after WG last call. That alone makes it
improper. If you want to get WG consensus for such a change, go ahead.
But don't try making this in the dead of night.

>
>
>>
>>> As this changes tries to explain, had such a text been used for all
>>> TLSv1.2 AEAD cipher suite code points, then browsers would have never
>>> needed any "downgrade dance" fallbacks, POODLE would have never
>>> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
>>> would not been needed, either.
>>
>> I'm not sure this is true, because there were also servers which did
>> not understand extensions.
>
>
> It's worse -- there are still TLS servers out there which choke on
> TLS extensions (and TLS server which choke on extension ordering).

TLS 1.2 demands extensions work. Sending a TLS 1.2 hello without
extensions is going to make it impossible to implement many features
TLS 1.2 security relies on.

>
> Sending TLS extensions is therefore a negotiation scheme that we
> can not ship as patch into the installed base, because we *KNOW*
> that it will break a few existing usage scenarios.  Stuff that needs
> TLS extensions is therefore an opt-in only scheme -- and even when
> making it opt-in, we may have to additonally provide a TLS extension
> exclusion list of hostnames.
>
> It seems that there are others facing the same issue:
>
> https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows
>
> and defer enabling to explicit customer opt-in.
>
>
> Really, a very compatible and extremely robust and useful approach would
> be to allow implied client protocol version indication through presence of
> TLSv1.2-only cipher suite codepoints and this would allow large parts
> of the installed base to quickly start using TLSv1.2--without breaking
> existing usage scenarios and without the hazzle for users having to opt-in
> and test stuff.

The people who have these problems are not "large parts" of the
install base. They are large parts of *your* install base. Don't
confuse these two.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.


From nobody Wed May 31 23:20:54 2017
Return-Path: 
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 960E412EB29 for ; Wed, 31 May 2017 23:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 8nG5XZniCNfI for ; Wed, 31 May 2017 23:20:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A2512EB26 for ; Wed, 31 May 2017 23:20:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHR65837; Thu, 01 Jun 2017 06:20:45 +0000 (GMT)
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 07:20:44 +0100
Received: from BLREML509-MBS.china.huawei.com ([169.254.8.188]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0301.000; Thu, 1 Jun 2017 11:50:32 +0530
From: Raja ashok 
To: Simon Bernard , "tls@ietf.org" 
Thread-Topic: RE: [TLS] Stopping retransmission DTLS 1.2
Thread-Index: AdLanyo8SF5mZcwtRIGyFlRHWH2H7g==
Date: Thu, 1 Jun 2017 06:20:31 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.213.121]
Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.592FB23E.0120, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.8.188, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 12cfde9614d61c96b6fe2dad56998eeb
Archived-At: 
Subject: Re: [TLS] Stopping retransmission DTLS 1.2
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Jun 2017 06:20:52 -0000

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_
Content-Type: multipart/alternative;
	boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_"

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgU2ltb24sDQoNCg0KDQpJbiBjYXNlIG9mIHBhcnRpYWwgcmVhZCwgYWZ0ZXIgcmV0cmFuc21p
dCB0aW1lb3V0IGlmIGEgRFRMUyByZWNlaXZlciBkb2VzbqGvdCByZXRyYW5zbWl0cyB0aGVuIHBl
ZXIgd2lsbCByZXRyYW5zbWl0IGl0cyBmbGlnaHQgYWdhaW4gb25seSBpZiBpdCBpcyBub3QgdGhl
IGZpbmFsIGZsaWdodC4NCg0KDQoNCkNvbnNpZGVyIGEgcmVjZWl2ZXIgaXMgRFRMUyBjbGllbnQs
IGFuZCBwZWVyIChzZXJ2ZXIpIGlzIHNlbmRpbmcgaXRzIGZpbmFsIGZsaWdodCAoQ0NTIGFuZCBG
TSkuIElmIGFueSBvbmUgb2YgdGhlIG1lc3NhZ2UgaXMgbm90IHJlY2VpdmVkLCB0aGVuIGNsaWVu
dCBoYXMgdG8gcmV0cmFuc21pdCBpdHMgcHJldmlvdXMgZmxpZ2h0IChDS0UsIENDUyBhbmQgRk0p
IG90aGVyd2lzZSBzZXJ2ZXIgd29udCByZXRyYW5zbWl0IGl0cyBtZXNzYWdlLg0KDQoNCg0KUmVn
YXJkcywNCg0KQXNob2sNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCltDb21w
YW55X2xvZ29dDQoNClJhamEgQXNob2sgViBLDQpIdWF3ZWkgVGVjaG5vbG9naWVzDQpCYW5nYWxv
cmUsIEluZGlhDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2rei
y824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7K
vcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+
1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8
/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp
biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRl
ZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBh
Ym92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55
IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRp
c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhl
ciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSBy
ZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkN
CnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg0KDQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaW1vbiBCZXJuYXJkDQpTZW50OiAzMSBNYXkgMjAxNyAy
MjowNg0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gU3RvcHBpbmcgcmV0cmFuc21p
c3Npb24gRFRMUyAxLjINCg0KDQoNCkhpLA0KDQoNCg0KICAgIFRoZSBSRkM2MzQ3LCA0LjIuNCBb
MV0gc2F5IDoNCg0KDQoNCiAgICAgICAgICIzLiBUaGUgaW1wbGVtZW50YXRpb24gcmVjZWl2ZXMg
dGhlIG5leHQgZmxpZ2h0IG9mIG1lc3NhZ2VzOiBpZiB0aGlzDQoNCiAgICAgICAgIGlzIHRoZSBm
aW5hbCBmbGlnaHQgb2YgbWVzc2FnZXMsIHRoZSBpbXBsZW1lbnRhdGlvbiB0cmFuc2l0aW9ucyB0
bw0KDQogICAgICAgICBGSU5JU0hFRC4gSWYgdGhlIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvIHNl
bmQgYSBuZXcgZmxpZ2h0LCBpdA0KDQogICAgICAgICB0cmFuc2l0aW9ucyB0byB0aGUgUFJFUEFS
SU5HIHN0YXRlLiBQYXJ0aWFsIHJlYWRzICh3aGV0aGVyDQoNCiAgICAgICAgIHBhcnRpYWwgbWVz
c2FnZXMgb3Igb25seSBzb21lIG9mIHRoZSBtZXNzYWdlcyBpbiB0aGUgZmxpZ2h0KSBkbw0KDQog
ICAgICAgICBub3QgY2F1c2Ugc3RhdGUgdHJhbnNpdGlvbnMgb3IgdGltZXIgcmVzZXRzLiINCg0K
DQoNCiAgICBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aHkgInBhcnRpYWwgcmVhZHMgZG8gbm90IGNh
dXNlIHN0YXRlIHRpbWVyIHJlc2V0cyIuDQoNCg0KDQogICAgSSBtZWFuIGlmIHdlIHJlY2VpdmUg
dGhlIGZpcnN0ICJoYW5kc2hha2UgbWVzc2FnZSIgb2YgdGhlIGV4cGVjdGVkICJmbGlnaHQiLiB3
ZSBjYW4gYXNzdW1lIHRoYXQgdGhlIGZvcmVpZ24gcGVlciByZWNlaXZlZCBvdXIgcHJldmlvdXMg
ZmxpZ2h0IGFuZCBzbyB3ZSBjYW4gc3RvcCByZXRyYW5zbWlzc2lvbnMgb2YgdGhpcyBmbGlnaHQu
DQoNCiAgICBJZiB0aGUgbmV4dCBtZXNzYWdlIGlzIGxvc3QsIHdlIHdpbGwgbmV2ZXIgcmVzcG9u
ZCBhbmQgc28gdGhlIGZvcmVpZ24gcGVlciBzaG91bGQgcmV0cmFuc21pdCB0aGUgd2hvbGUgZmxp
Z2h0LiBXZSBkb24ndCBuZWVkIHRvIHJldHJhbnNtaXQgb24gb3VyIHNpZGUsIHNvIHRpbWVyIHNo
b3VsZCBiZSByZXNldCA/DQoNCg0KDQogICAgRGlkIEkgbWlzc2VkIHNvbWV0aGluZyA/DQoNCg0K
DQpUaHguDQoNCg0KDQpTaW1vbg0KDQoNCg0KWzFdaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzYzNDcjc2VjdGlvbi00LjIuNA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KVExTIG1haWxpbmcgbGlzdA0KDQpUTFNAaWV0Zi5vcmc8
bWFpbHRvOlRMU0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby90bHMNCg0K

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Simon,


 


In case of partial read, after retransmit timeout=
 if a DTLS receiver doesn=A1=AFt retransmits then peer will retransmit its =
flight again only if it is not the final flight.



 


Consider a receiver is DTLS client, and peer (ser=
ver) is sending its final flight (CCS and FM). If any one of the message is=
 not received, then client has to retransmit its previous flight (CKE, CCS =
and FM) otherwise server wont retransmit
 its message.


 


Regards,


Ashok


 








3D"Company_logo"



Raja Ashok V K

Huawei Technologies

Bangalore, India

http://www.huawei.com 








=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=
=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=
=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=
=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=
=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=
=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=
=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=
=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=
=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=
=A1

This e-mail and its attachments contain confide=
ntial information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!


 


 


 


 


-----Original Message-----

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Simon Bernard

Sent: 31 May 2017 22:06

To: tls@ietf.org

Subject: [TLS] Stopping retransmission DTLS 1.2


 


Hi,


 


    The RFC6347, 4.2.4 [1] say :


 


         =
"3. The implementation receives the next flight of messages: if this


         =
is the final flight of messages, the implementation transitions to


         =
FINISHED. If the implementation needs to send a new flight, it

         =
transitions to the PREPARING state. Partial reads (whether


         =
partial messages or only some of the messages in the flight) do<=
/p>

         =
not cause state transitions or timer resets."


 


    I would like to know why "=
;partial reads do not cause state timer resets".


 


    I mean if we receive the first=
 "handshake message" of the expected "flight". we can a=
ssume that the foreign peer received our previous flight and so we can stop=
 retransmissions of this flight.


    If the next message is lost, w=
e will never respond and so the foreign peer should retransmit the whole fl=
ight. We don't need to retransmit on our side, so timer should be reset ?


 


    Did I missed something ?<=
/o:p>


 


Thx.


 


Simon


 


[1]https=
://tools.ietf.org/html/rfc6347#section-4.2.4


 


_______________________________________________


TLS mailing list


TLS@ietf.org


https://www.ietf=
.org/mailman/listinfo/tls


 






--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_--

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=6737;
	creation-date="Thu, 01 Jun 2017 06:20:31 GMT";
	modification-date="Thu, 01 Jun 2017 06:20:31 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA
AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA
AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA
AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB
AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A
AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA////////
/////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/////////
////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA
AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A
AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA
AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg
AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS
AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF
U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA
AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA
TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA
AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA
AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB
bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA
AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl
QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u
ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN
BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA
AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM
QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT
ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O
Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB
IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB
AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR
obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF
tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR
AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV
NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA
AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6
6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs
VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns
U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9
w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh
fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX
146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh
SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t
bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo
JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb
qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv
/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F
ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4
HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v
6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m
+u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6
tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ
JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r
WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z
OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB
AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA
AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq
AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8
CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox
ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA
BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB
AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf
Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM
DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM
DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED
EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV
UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0
pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB
UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz
hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/
APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3
0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl
/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP
UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+
qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW
9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq
FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp
VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku
cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf
Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0
PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C
OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us
XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j
QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6
jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n
0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT
gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf
UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj
Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI
BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04
MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA
AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh
CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV
1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK
C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy
0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge
ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn
yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr
aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g
dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf
03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l
6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo
9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai
uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45
RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV
zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc
TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM
v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S
reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8
V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM
qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/
thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le
LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x
ke3tRX0lRQB//9k=

--_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1952F79BLREML509MBSchi_--