From nobody Thu Feb 2 07:22: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 F330312946B for ; Thu, 2 Feb 2017 07:22:25 -0800 (PST) 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 zHcdKj4AyPuL for ; Thu, 2 Feb 2017 07:22:19 -0800 (PST) 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 D18E212965D for ; Thu, 2 Feb 2017 07:22:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 20204300466 for ; Thu, 2 Feb 2017 10:22:19 -0500 (EST) 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 uOCVKrmN7p0R for ; Thu, 2 Feb 2017 10:22:18 -0500 (EST) Received: from russellsleysmbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 233843003D0 for ; Thu, 2 Feb 2017 10:22:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <733EE968-69EF-43A5-A39B-F016993A3CCD@vigilsec.com> Date: Thu, 2 Feb 2017 10:20:09 -0500 Content-Transfer-Encoding: 7bit Message-Id: <949EBD4E-613B-4B36-BD93-FDE3E4D4926F@vigilsec.com> References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com> <733EE968-69EF-43A5-A39B-F016993A3CCD@vigilsec.com> To: IETF TLS X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:22:26 -0000 Proposed update to Section 4.1.1 of draft-ietf-tls-tls13-18 OLD: The server indicates its selected parameters in the ServerHello as follows: - If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key. - If PSK is not being used, then (EC)DHE and certificate-based authentication are always used. - When (EC)DHE is in use, the server will also provide a "key_share" extension. - When authenticating via a certificate (i.e., when a PSK is not in use), the server will send the Certificate (Section 4.4.1) and CertificateVerify (Section 4.4.2) messages. NEW: The server indicates its selected parameters in the ServerHello as follows: - If PSK is not being used, then (EC)DHE and certificate-based authentication are always used, and the server will: -- provide a "key_share" extension; and -- send the Certificate (Section 4.4.1) and CertificateVerify (Section 4.4.2) messages. - If PSK (without DH or ECDH) is being used, then the server sends a "pre_shared_key" extension to indicate the selected key. - If PSK and (EC)DH are being used together, then the server will: -- sends a "pre_shared_key" extension to indicate the selected key; -- provide a "key_share" extension; and -- send the Certificate (Section 4.4.1) and CertificateVerify (Section 4.4.2) messages. END Many thanks to Sean Turner for turning this into a PR for me: https://github.com/tlswg/tls13-spec/pull/870 Thanks, Russ From nobody Thu Feb 2 08:25: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 C461612973D for ; Thu, 2 Feb 2017 08:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 RqLIErcogrpN for ; Thu, 2 Feb 2017 08:24:55 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 F1682129735 for ; Thu, 2 Feb 2017 08:24:54 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so38767297qtg.3 for ; Thu, 02 Feb 2017 08:24:54 -0800 (PST) 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=6rwc8j6kiwcnTmH7mwIMtc/s9CiYrk22YWZb30qSozA=; b=G8y4RZRhUU/9KX2xLth+A850b0AnLhx23g4GDRFzvpYFxdFGiHJgUoZK7VaLCJNdyK L5t86jYrSgaksLiabMwqdWetmtEWRv56InEUQAbonl4tAyb9GVJBPBHLPInv3cSiQsWG 9ZC7msJLJCV48M1uodXMnlhELP+FBfxp7oNgw= 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=6rwc8j6kiwcnTmH7mwIMtc/s9CiYrk22YWZb30qSozA=; b=fQQniNLuZ9f7D/cq9nvoq3IxezlP+SNMFYYqGudvzyfeg7snbWyKoSzafgPAGyGv/c ZqQgOQtEZY3BHzwMi0lG4k5kOe47AQ5y320l8JFvAmFC2fhI2xi+T9G9SZWcYkwxaXG+ sezl2CqvIj5J/32WppDyXs/6PsMBPld/xLiCN3lgS84roU2gTl9YRdG9J6j1IOYL6Zxw GDfYMgxMVp/+kIE5Cq+nwsszjigT713H6xKQ45PYOvmf846iHj6ACp0OlH4Ze6nNnwp7 3Aw/b6b4U8gu1LVhPFFQNJjxQGLjm9MWDvSxcX0Ufv49abVcn7JUPbT1ye1oZBhu15gn hIEA== X-Gm-Message-State: AIkVDXJlO2Ns7UGhvVibIQy3qDEk5Iug+udoBjIOSe6zLKA7gQbDdUD0mYthnOMeMzIKD4gS2r3B5lY8RYDxT1ts X-Received: by 10.237.34.250 with SMTP id q55mr9473278qtc.127.1486052693916; Thu, 02 Feb 2017 08:24:53 -0800 (PST) MIME-Version: 1.0 References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com> <733EE968-69EF-43A5-A39B-F016993A3CCD@vigilsec.com> <949EBD4E-613B-4B36-BD93-FDE3E4D4926F@vigilsec.com> In-Reply-To: <949EBD4E-613B-4B36-BD93-FDE3E4D4926F@vigilsec.com> From: David Benjamin Date: Thu, 02 Feb 2017 16:24:43 +0000 Message-ID: To: Russ Housley , IETF TLS Content-Type: multipart/alternative; boundary=001a113eea5af0a46405478e9a60 Archived-At: Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:24:58 -0000 --001a113eea5af0a46405478e9a60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think this is much clearer, except for one bullet point below: On Thu, Feb 2, 2017 at 10:22 AM Russ Housley wrote: > [...] > - If PSK and (EC)DH are being used together, then the server will: > > -- sends a "pre_shared_key" extension to indicate the selected > key; > > -- provide a "key_share" extension; and > > -- send the Certificate (Section 4.4.1) and CertificateVerify > (Section 4.4.2) messages. This last bullet here contradicts what specification says elsewhere. From 4.4.1: """ The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except PSK). This message conveys the endpoint=E2=80=99s certificate chain to the peer. """ (Otherwise we defeat the point of resumption and lose PSK-based identities.= ) Like MT, I am interested in a mode with both (right now we have a ticket renewal cliff because only the initial handshake does an online signature), but we'll need to work out the exact semantics. Going from one identity to two identities, especially when one is added partway through the stream (consider 0-RTT) has a lot of sharp edges. Since this can easily be added as an extension (and would need one anyway for negotiation), I think it's better to do it as a later document, so we don't delay what we've done already or rush in a combined mode without considering all the details. The document would just say "when PSK and fancy_new_extension are both negotiated, then the server will [...]". Plenty of extensions have modified the handshake message flow. David --001a113eea5af0a46405478e9a60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is much clear= er, except for one bullet point below:

On Thu, Feb= 2, 2017 at 10:22 AM Russ Housley <housley@vigilsec.com> wrote:
[...]
=C2=A0 -=C2=A0 If PSK and (EC)DH are being used together, then the server w= ill:

=C2=A0 =C2=A0 =C2=A0--=C2=A0 sends a "pre_shared_key" extension t= o indicate the selected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key;

=C2=A0 =C2=A0 =C2=A0--=C2=A0 provide a "key_share" extension; and=

=C2=A0 =C2=A0 =C2=A0--=C2=A0 send the Certificate (Section 4.4.1) and Certi= ficateVerify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 4.4.2) messages.

This last bullet here contradicts what specification says = elsewhere. From 4.4.1:

"""
The server MUST send a Certificate message whenever the agreed-upon key e= xchange method uses certificates for authentication (this includes all key = exchange methods defined in this document except PSK). This message conveys= the endpoint=E2=80=99s certificate chain to the peer.
"= ""

(Otherwise we defeat the point of res= umption and lose PSK-based identities.)

Like MT, I= am interested in a mode with both (right now we have a ticket renewal clif= f because only the initial handshake does an online signature), but we'= ll need to work out the exact semantics. Going from one identity to two ide= ntities, especially when one is added partway through the stream (consider = 0-RTT) has a lot of sharp edges.

Since this can ea= sily be added as an extension (and would need one anyway for negotiation), = I think it's better to do it as a later document, so we don't delay= what we've done already or rush in a combined mode without considering= all the details. The document would just say "when PSK and fancy_new_= extension are both negotiated, then the server will [...]". Plenty of = extensions have modified the handshake message flow.

David --001a113eea5af0a46405478e9a60-- From nobody Fri Feb 3 06:46: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 E1F2B129DAB for ; Fri, 3 Feb 2017 06:46:32 -0800 (PST) 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 7uZlCpYUTMwW for ; Fri, 3 Feb 2017 06:46:31 -0800 (PST) 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 A42BC129DA0 for ; Fri, 3 Feb 2017 06:46:30 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id v200so13050726ywc.3 for ; Fri, 03 Feb 2017 06:46:30 -0800 (PST) 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=2nJU3CA7XWh57cDQBDYQyUtfP3HV/QQZ0nLlnAz3Vy0=; b=tBacbG2OQGd5OvgjBALzqsRwwPb8QoWx7XshNORQdtRASPcb3J5+Z0riDdT/7u0ZBq i2IVlbaUUnC59qiowMvjo1IsfihshlVTyO4Uqye3LsMmrzBdmE5omi7Z1QgsXT0ZQzvt jHi+jKRyOH91AH0AGv74Kt7TuUfoOFRhzCeyBnd4rinaO+mXcPzYKNyv4krlMIyXVIi4 KPEm5kB6BI3tFk7NyhhkcHF8q+wnkwx57SHL1dcT/CYfcynVykGA28w+Z7Z4c9Xz5KbN xRskRqVw1s4VgC8CgN/jmNrxWYaMySCKyCxQFW6ZkG5r7B9oVC0hKw4YTWGzbzNo3Hdj jLaQ== 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=2nJU3CA7XWh57cDQBDYQyUtfP3HV/QQZ0nLlnAz3Vy0=; b=SuV0DX1i5syyFGtOANwG4H9O2snPnXO1rkj8l9rzBEGEJ1oYkNECVVLlPMJDSSnhlk t2nMbUMcqbtxfyovxrZkixU5CDEQ4k7AoJfzKCfmb3UBtwLDbxylrJAZiMWZDX+tZdVk F7TQjfCvsSKf98iFrEwW/twBrsJ0rmLxHg00N3IeC6pS8D5VP5LLuw1d5L74SZmQazWL eMdGtlkx1JyltIM7tLuwPL46Gku1aMBEJ+fjWWCNCzSNVZJzSUObDEB+5hI0noksAAGl kNfMwi10hcQNt59pFM2cwcHLfvjo1F3CyGEhkHn1u/uuJRsuW1xRUK5cXuKvZH4icpxN 7ELg== X-Gm-Message-State: AIkVDXJ4oxZGzu70w2NIBDXy8XooduQpL0fWNavIKOCOYYP95oHdKsj1B7gW1fQJpZSWQpIcmTWHQ1QXdGUQXA== X-Received: by 10.129.162.130 with SMTP id z124mr11111909ywg.276.1486133189945; Fri, 03 Feb 2017 06:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 06:45:49 -0800 (PST) In-Reply-To: References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com> <733EE968-69EF-43A5-A39B-F016993A3CCD@vigilsec.com> <949EBD4E-613B-4B36-BD93-FDE3E4D4926F@vigilsec.com> From: Eric Rescorla Date: Fri, 3 Feb 2017 06:45:49 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c129292e088550547a15893 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:46:33 -0000 --94eb2c129292e088550547a15893 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with David here. Specifically, I think. - The base specification should continue to forbid certificates in combination with PSK - We should at some point contemplate an extension that allows the use of certificates in combination with PSK - The base spec should be factored in such a way as to make that extension easy. -Ekr On Thu, Feb 2, 2017 at 8:24 AM, David Benjamin wrote: > I think this is much clearer, except for one bullet point below: > > On Thu, Feb 2, 2017 at 10:22 AM Russ Housley wrote= : > >> [...] >> - If PSK and (EC)DH are being used together, then the server will: >> >> -- sends a "pre_shared_key" extension to indicate the selected >> key; >> >> -- provide a "key_share" extension; and >> >> -- send the Certificate (Section 4.4.1) and CertificateVerify >> (Section 4.4.2) messages. > > > This last bullet here contradicts what specification says elsewhere. From > 4.4.1: > > """ > The server MUST send a Certificate message whenever the agreed-upon key > exchange method uses certificates for authentication (this includes all k= ey > exchange methods defined in this document except PSK). This message conve= ys > the endpoint=E2=80=99s certificate chain to the peer. > """ > > (Otherwise we defeat the point of resumption and lose PSK-based > identities.) > > Like MT, I am interested in a mode with both (right now we have a ticket > renewal cliff because only the initial handshake does an online signature= ), > but we'll need to work out the exact semantics. Going from one identity t= o > two identities, especially when one is added partway through the stream > (consider 0-RTT) has a lot of sharp edges. > > Since this can easily be added as an extension (and would need one anyway > for negotiation), I think it's better to do it as a later document, so we > don't delay what we've done already or rush in a combined mode without > considering all the details. The document would just say "when PSK and > fancy_new_extension are both negotiated, then the server will [...]". > Plenty of extensions have modified the handshake message flow. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c129292e088550547a15893 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with David here. Specifically, I think.

- The base specification should continue to forbid certificates in= combination with PSK
- We should at some point contemplate an ex= tension that allows the use of certificates in combination with PSK
- The base spec should be factored in such a way as to make that extensi= on easy.

-Ekr

<= /div>

= On Thu, Feb 2, 2017 at 8:24 AM, David Benjamin <davidben@chromium.org<= /a>> wrote:
I think this is much clearer, except for one = bullet point below:

[...]
=C2=A0 -=C2=A0 If PSK and (EC)DH are being used together, then the server w= ill:

=C2=A0 =C2=A0 =C2=A0--=C2=A0 sends a "pre_shared_key" extension t= o indicate the selected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key;

=C2=A0 =C2=A0 =C2=A0--=C2=A0 provide a "key_share" extension; and=

=C2=A0 =C2=A0 =C2=A0--=C2=A0 send the Certificate (Section 4.4.1) and Certi= ficateVerify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 4.4.2) messages.

This last bullet here contradicts what specificatio= n says elsewhere. From 4.4.1:

"""
The server MUST send a Certificate message whenever the agreed-upo= n key exchange method uses certificates for authentication (this includes a= ll key exchange methods defined in this document except PSK). This message = conveys the endpoint=E2=80=99s certificate chain to the peer.
"""

(Otherwise we defeat the point= of resumption and lose PSK-based identities.)

Lik= e MT, I am interested in a mode with both (right now we have a ticket renew= al cliff because only the initial handshake does an online signature), but = we'll need to work out the exact semantics. Going from one identity to = two identities, especially when one is added partway through the stream (co= nsider 0-RTT) has a lot of sharp edges.

Since this= can easily be added as an extension (and would need one anyway for negotia= tion), I think it's better to do it as a later document, so we don'= t delay what we've done already or rush in a combined mode without cons= idering all the details. The document would just say "when PSK and fan= cy_new_extension are both negotiated, then the server will [...]". Ple= nty of extensions have modified the handshake message flow.

David

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


--94eb2c129292e088550547a15893-- From nobody Sun Feb 5 16:12: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 9429F129560 for ; Sun, 5 Feb 2017 16:12:11 -0800 (PST) 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 GRD_FTxPW1cn for ; Sun, 5 Feb 2017 16:12:10 -0800 (PST) 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 61CC6129557 for ; Sun, 5 Feb 2017 16:12:10 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E51276315A; Mon, 6 Feb 2017 00:12:10 +0000 (UTC) Received: from ovpn-116-19.ams2.redhat.com (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v160C6PN003870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Feb 2017 19:12:08 -0500 Message-ID: <1486339925.22876.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Date: Mon, 06 Feb 2017 01:12:05 +0100 In-Reply-To: <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 06 Feb 2017 00:12:11 +0000 (UTC) Archived-At: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 00:12:11 -0000 On Mon, 2017-01-23 at 12:52 +0200, Ilari Liusvaara wrote: > On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2017-01-20 at 17:43 +0000, Dr Stephen Henson wrote: > > > > > Additionally PSS signatures (see RFC4055) can be used with RSA > > > keys > > > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). > > > Does > > > the RSASSA-PSS mean that both types must be accepted? > > > > That's a quite interesting finding. Although that protocol behavior > > seems to ease transition to RSASSA-PSS, it also paves the field for > > new > > cross protocol attacks. A server which can sign with either of > > RSASSA- > > PSS and RSA-PKCS1 and the same key is certainly less secure than a > > server which can sign with either of them. The only way to enforce > > that > > a key is restricted is by requiring the id-RSASSA-PSS OID for > > RSASSA- > > PSS. > > Unfortunately, dedicated RSA-PSS keys are pretty much undeployable, > and > requirement to use those would be de facto the same as removing RSA > server signatures entierely from TLS 1.3[1]. > > I don't know any CA that would certify RSA-PSS keys. And adding new > key > types is a slow process. Heck, Certifying ECDSA keys are poorly > supported among CAs[2]. > > And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that > there > exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any > messages, unless keysizes are too small, hashes are too large or > salts are too large. The issue is that we cannot tell for sure. Any proof of security assumes that the keys are restricted to a single scheme. So I think we got into a trap where we intended to increase security, while in fact reduced the protocol's security, by ending-up adding RSA-PSS in a way that can share keys with PKCS#1 1.5. I think that we should treat RSA- PSS as the mean to increase security rather than the end-goal. Even if the approach of separating keys would mean that RSA-PSS will not be deployed immediately, it will allow implementors to provide well-behaved clients that will refuse to mix marked as RSA-PSS keys with the legacy ones. On the current protocol description it is impossible for an implementor to do that. The reason is that if one does that, his software will not be functional, will fail to connect to several web servers, and thus will have to compromise (functionality always wins over security). > [2] Some commercial CAs (don't have list) and Let's Encrypt (signed  > with RSA[3] and even then most ACME software can't handle those).. TLS 1.3 requiring a different key type, will provide an incentive for them to update. regards, Nikos From nobody Sun Feb 5 18:36: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 4F7F6129565 for ; Sun, 5 Feb 2017 18:36:31 -0800 (PST) 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 dCd9ydhauIeE for ; Sun, 5 Feb 2017 18:36:30 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 37E711294AD for ; Sun, 5 Feb 2017 18:36:30 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 11so42640183qkl.3 for ; Sun, 05 Feb 2017 18:36:30 -0800 (PST) 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=qgRHlDtiF8qaJITHXYchouTAIh2yfCSTRjkQDfoBGvo=; b=kb4BNYycCYIjtpEQdI/JX2IDMPjdDRVe5Uz1MeMHgbebxKQM59UU0o6AAZvfKPB3dd WLlZBMDejn+iIor7Lj7MKePex0Z4Vqc5K0GXsMIO7Z3c6OUp0x7vswYQvaJI9ZucaN/K 9GgxZi5vjs1UYuKoKaSUE8bejFqEITXGY1NQ1dccXByhFpinjsUjHB9NgTGFPj+OACP1 KDVAc6RtU7lzVH9plwTlzDiqoyW8S2e6pd9+x8iEi5j1CeS9MI+4W8pJJ7ktxEaAVDca lGzksKBOv9spCUSRIid0F0ed+PvujH/DNvNG2ayAFQNnj81RVbMBy6xc1uJIUXo1swsl LDgg== 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=qgRHlDtiF8qaJITHXYchouTAIh2yfCSTRjkQDfoBGvo=; b=foy+8zh11Nb5R55LgayAt6fKfCpZ9y5UzXSfu81Q/sjZdMbPdErnBaaYIthsLnKkXY q27FZFNFnDEYlEva+KtDMDYN66bDFhQGPyrFuml7tnRk9ipJr74s6Um9LUm8QVwZLQO+ uex/PrQwI9SupWHWTnee4mm2NmJIeJvcmBGhRCmjgVE4o9I7dWArq6CaEbpEe6EIAcB0 4zcrPI9HExcCW5Lcazhc+YNe+ZqUF2fUOR0Abm6FIDfiQJy2e0GmAO/8tF9B0tZS0U3w eCz3aJQp01x08VtIf/fZDe0F9SOOdf+atnui1Od5KAMHiTHWBXMFK4lz0L2hoXOF9XVM ynVQ== X-Gm-Message-State: AMke39mhUhW3eoSrRX2v9C5bhv3n6UhnlEdz5QHjfJanYF6kr5nIY62YbmuvGNcZITPBjZTs/Q3SxlisTyn0gw== X-Received: by 10.233.216.68 with SMTP id u65mr7396642qkf.68.1486348589324; Sun, 05 Feb 2017 18:36:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 5 Feb 2017 18:36:28 -0800 (PST) In-Reply-To: <1486339925.22876.1.camel@redhat.com> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> <1486339925.22876.1.camel@redhat.com> From: Martin Thomson Date: Mon, 6 Feb 2017 13:36:28 +1100 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:36:31 -0000 On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos wrote: > TLS 1.3 requiring a different key type, will provide an incentive for > them to update. I don't think that's how this works. More likely, that would become a reason not to deploy TLS 1.3 if you insist that only RSA-PSS certs are used. Yes, I know that it's relatively easy to configure a PSS certificate separately. I wrote the code that did that in NSS, but it's going to remain the case that most servers have one cert. If you have one cert, then it's going to be the one that works with all the clients. From nobody Sun Feb 5 18:46: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 B7D44129A8B for ; Sun, 5 Feb 2017 18:46:21 -0800 (PST) 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, 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 bQwBilZNijnb for ; Sun, 5 Feb 2017 18:46:20 -0800 (PST) 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 9C6BE1294AD for ; Sun, 5 Feb 2017 18:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1486349179; x=1517885179; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4s2/dw/V6hY5ebRpVSR7oDtmx75LwBGmON61zBdJjwU=; b=VKSbjdLXZtfeIxUbbSZRVhjZLMy+331OlJ5+E9QAFuw1D4lanI/mGiFm lZCCeURSHcmGL732xKlCpYns0ClaZ+P99m9fECENKHY6wQ3bkwSeaSldn o471B3igu26zIklUoTgU2FgUkeKLTbFEA690aUDJJjAws3sSNJtwHLZFL eCbIJUm6jcC2GWwxcCG/MZzZcQKTKL3E2zw3W3hcmKP+INq+smtq/2Zrt uHx0QMknqZVmOHhO2ss9ipx8Yiw/x40Dl1zdHeTuviqWvIyxRblZk0ZFs 4jz2Ymuwj6JqI1GZubAN5RBVaTiw0Ic0HHREdInyDMuiQD87q34hy69jK w==; X-IronPort-AV: E=Sophos;i="5.33,340,1477911600"; d="scan'208";a="133539110" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Feb 2017 15:46:16 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Feb 2017 15:46:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Mon, 6 Feb 2017 15:46:15 +1300 From: Peter Gutmann To: Nikos Mavrogiannopoulos , Ilari Liusvaara Thread-Topic: [TLS] PSS and TLS 1.3 Thread-Index: AQHSc0S/upLCS1YCIUyVmPRJN/iDg6FE3nMAgAAuuICAFU2ogIABBLCv Date: Mon, 6 Feb 2017 02:46:15 +0000 Message-ID: <1486349166238.64949@cs.auckland.ac.nz> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi>, <1486339925.22876.1.camel@redhat.com> In-Reply-To: <1486339925.22876.1.camel@redhat.com> 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: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:46:22 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >TLS 1.3 requiring a different key type, will provide an incentive for them= to=0A= >update.=0A= =0A= No, it'll be an incentive for them to ignore the requirement, or work aroun= d=0A= it. The S/MIME WG looked at this years ago when they considered tying AES = use=0A= to RSA-PSS/OAEP, the plan being to use the adoption of AES to try and force= =0A= adoption of RSA-not-PKCS1.5. It was canned pretty quickly: No implementati= on=0A= support, no CA support, no HSM/smart card support, and you'd have to someho= w=0A= figure out how to set up keys so they couldn't be used with PKCS # 1.5 any= =0A= more in an environment where everything did PKCS #1.5.=0A= =0A= (I realise this was a long time ago, so now it'll be more like little=0A= implementation support, no CA support, little to no HSM/smart card support,= =0A= and the same thing about the environment. And, as long as you do PKCS #1.5= as=0A= encode-then-compare as per the spec, no particular motivation to move to PS= S).=0A= =0A= Peter.= From nobody Sun Feb 5 21: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 013F9129C12 for ; Sun, 5 Feb 2017 21:27:42 -0800 (PST) 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, 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 9dqNGvhrnbev for ; Sun, 5 Feb 2017 21:27:40 -0800 (PST) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::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 83A2E129C11 for ; Sun, 5 Feb 2017 21:27:40 -0800 (PST) Received: by mail-wr0-x244.google.com with SMTP id o16so2462631wra.2 for ; Sun, 05 Feb 2017 21:27:40 -0800 (PST) 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=Dj3OdYg5YAST/vmEtEuqDl++urkaMr5VnYyF8S3+gm0=; b=DyGVjvfycMniJp8X3uykJ9lpAngcZHvX/72ueBWkwH+au9qJnAoXlE5JfwFPQ+Da+C QMTIGGXKNtw2SS/7e6cplayvLaZQjdDcNwNKtPW/1Roh7u20HsFkVHpNz5nMqFpmBK/A ovKsQz0nOGnmKNcda1bPl8fyMTPe8qREN33tDbylyEUbHTWi1bRv5OMPzJI0QIkoXNyH jZA7+msZG7bGxuoFTHjSrJ/iTiAcyWDFxKFzYjicWWqEnYs4zQv1W+sBsk0nIXIm5g6H v0Jq1PX5/TPjBkrih9jJVH5UfA9TmCxojtiI0PngdN9OhOonCwKLiYj6PbAfIvTqt24j 7Ajw== 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=Dj3OdYg5YAST/vmEtEuqDl++urkaMr5VnYyF8S3+gm0=; b=EBp6hExuOgRZ3+LdwkT5TwLGIadDgBMQuWzTpZAxiq5xenNrQSVZ8M6Kpugh4ogahy V835P/4KD9bDII9hgZs7GhhZgE7QrdvuWzesq1F+8qJORyY5jckspApc6ZbR7HTArHgf w9uxXRUfWd1U59dSZz14W0AGx8k4onrisLd7kZu5EZjcJZ+nhMwqrlLrYurrwlO8H/Ag O9oqfBb3IBrz7d2JpeE4PFp0YOGQtMyo+yaFBrClY5W8TOwkDIcBEd3zjNkBS+UQb0xt ZIud4kUpqscyxBoC2afo2YAQv82wCfMNlM/LrSPxd89E+DzvYq98o3SN/hhn7yuYVzWH bkGw== X-Gm-Message-State: AIkVDXIqQAM0REZSczkFCUMLQhlAHFZaq6xQHgyiX2BDp2nMFsYaufp0vg8glZ6CQdljeQ== X-Received: by 10.223.166.181 with SMTP id t50mr7551123wrc.80.1486358858892; Sun, 05 Feb 2017 21:27:38 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id a13sm10706089wma.13.2017.02.05.21.27.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 21:27:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Yoav Nir In-Reply-To: Date: Mon, 6 Feb 2017 07:27:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B13E99B-2F8E-4A57-AB83-745BE623FFBE@gmail.com> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> <1486339925.22876.1.camel@redhat.com> To: Martin Thomson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 05:27:42 -0000 > On 6 Feb 2017, at 4:36, Martin Thomson = wrote: >=20 > On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos = wrote: >> TLS 1.3 requiring a different key type, will provide an incentive for >> them to update. >=20 >=20 > I don't think that's how this works. More likely, that would become a > reason not to deploy TLS 1.3 if you insist that only RSA-PSS certs are > used. Right. The only reason anyone is currently using RSA rather than ECDSA = is for compatibility with older clients. If those clients are so old = that they don=E2=80=99t support ECDSA keys, they=E2=80=99re not likely = to support RSA-PSS. Yoav From nobody Mon Feb 6 04:19: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 69FBD129D26 for ; Mon, 6 Feb 2017 04:19:23 -0800 (PST) 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 9ucfxBQSokLC for ; Mon, 6 Feb 2017 04:19:21 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDAF129D19 for ; Mon, 6 Feb 2017 04:19:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 192D01EEB4; Mon, 6 Feb 2017 14:19:19 +0200 (EET) 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 OFQPd1Ubn8b2; Mon, 6 Feb 2017 14:19:18 +0200 (EET) 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 CA24521C; Mon, 6 Feb 2017 14:19:18 +0200 (EET) Date: Mon, 6 Feb 2017 14:19:17 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20170206121917.GA30902@LK-Perkele-V2.elisa-laajakaista.fi> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> <1486339925.22876.1.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1486339925.22876.1.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:19:23 -0000 On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote: > > The issue is that we cannot tell for sure. Any proof of security > assumes that the keys are restricted to a single scheme. So I think we > got into a trap where we intended to increase security, while in fact > reduced the protocol's security, by ending-up adding RSA-PSS in a way > that can share keys with PKCS#1 1.5. I think that we should treat RSA- > PSS as the mean to increase security rather than the end-goal. Looking at the signature constructions, I would say it is _extremely_ unlinkely that cross-protocol attacks are possible. And this is with extremely loose criteria and extremely loose attacker resource budget. > Even if the approach of separating keys would mean that RSA-PSS will > not be deployed immediately, it will allow implementors to provide > well-behaved clients that will refuse to mix marked as RSA-PSS keys > with the legacy ones. On the current protocol description it is > impossible for an implementor to do that. The reason is that if one > does that, his software will not be functional, will fail to connect to > several web servers, and thus will have to compromise (functionality > always wins over security). > > > > [2] Some commercial CAs (don't have list) and Let's Encrypt (signed  > > with RSA[3] and even then most ACME software can't handle those).. > > TLS 1.3 requiring a different key type, will provide an incentive for > them to update. More like roadblock to upgrade to TLS 1.3. Getting CA support for RSA-PSS keys would be SLOW to say the least. -Ilari From nobody Mon Feb 6 08: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 54572129F0D for ; Mon, 6 Feb 2017 08:57:36 -0800 (PST) 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_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PIU6qt_wS2Wd for ; Mon, 6 Feb 2017 08:57:34 -0800 (PST) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (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 453DE12959A for ; Mon, 6 Feb 2017 08:57:34 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v16GvU5f043616; Mon, 6 Feb 2017 11:57:31 -0500 Date: Mon, 6 Feb 2017 11:57:30 -0500 (EST) From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Message-ID: <1832853504.27468281.1486400250409.JavaMail.zimbra@redhat.com> In-Reply-To: <20170206121917.GA30902@LK-Perkele-V2.elisa-laajakaista.fi> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> <1486339925.22876.1.camel@redhat.com> <20170206121917.GA30902@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.36.116.125] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF51 (Linux)/8.0.6_GA_5922) Thread-Topic: PSS and TLS 1.3 Thread-Index: etD+T2j6J1csLdwXy+Obq+O80L9zxA== Archived-At: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:57:36 -0000 ----- Original Message ----- > On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote: > > > > The issue is that we cannot tell for sure. Any proof of security > > assumes that the keys are restricted to a single scheme. So I think we > > got into a trap where we intended to increase security, while in fact > > reduced the protocol's security, by ending-up adding RSA-PSS in a way > > that can share keys with PKCS#1 1.5. I think that we should treat RSA- > > PSS as the mean to increase security rather than the end-goal. > > Looking at the signature constructions, I would say it is _extremely_ > unlinkely that cross-protocol attacks are possible. Isn't the whole purpose of moving to formally proved schemes, the fact that there is a proof of security? This support by TLS 1.3 invalidates this proof, thus making any reason to have RSASSA-PSS moot, (unless of course we have a proof that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure). regards, Nikos From nobody Mon Feb 6 13:18: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 499CC1294D2 for ; Mon, 6 Feb 2017 13:18:31 -0800 (PST) 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 GE6Vnpd-uHTi for ; Mon, 6 Feb 2017 13:18:29 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 80778129432 for ; Mon, 6 Feb 2017 13:18:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id D42821DD61; Mon, 6 Feb 2017 23:18:27 +0200 (EET) 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 Qx918-PIf5PN; Mon, 6 Feb 2017 23:18:27 +0200 (EET) 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 8907D21C; Mon, 6 Feb 2017 23:18:27 +0200 (EET) Date: Mon, 6 Feb 2017 23:18:26 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20170206211826.GA31823@LK-Perkele-V2.elisa-laajakaista.fi> References: <1485158728.3068.5.camel@redhat.com> <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi> <1486339925.22876.1.camel@redhat.com> <20170206121917.GA30902@LK-Perkele-V2.elisa-laajakaista.fi> <1832853504.27468281.1486400250409.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1832853504.27468281.1486400250409.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org list" Subject: Re: [TLS] PSS and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:18:31 -0000 On Mon, Feb 06, 2017 at 11:57:30AM -0500, Nikos Mavrogiannopoulos wrote: > > > Isn't the whole purpose of moving to formally proved schemes, the fact that there > is a proof of security? This support by TLS 1.3 invalidates this proof, thus > making any reason to have RSASSA-PSS moot, (unless of course we have a proof > that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure). As to why I said I consider it unlikely: You need to match up a lot of hash output bits (easily over 1,000) with at most 512 bits of input in order to effect a cross-protocol attack. Matching up 1,000 hash output bits would be hard enough. That one has only 512 bits of input makes it with overwhelming probability impossible. -Ilari From nobody Tue Feb 7 08:12: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 604B7127076 for ; Tue, 7 Feb 2017 08:12:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (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 zEZsyBkGnLzx for ; Tue, 7 Feb 2017 08:12:14 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 0B333129CFE for ; Tue, 7 Feb 2017 08:12:14 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id c7so80123022itd.1 for ; Tue, 07 Feb 2017 08:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hMPHl/WKffRdAtEPMV68QA4fZl4QATiWdHcUkbdlFgw=; b=kJ4x3h/j98HzrS8b2+HFL9qgWIj4STBXsbcN7JUs+I4iWyPmdoiAnamscb5kxaXU+1 BxYrYzExj7+GdHIGB0qyAWeThuKDtbznQlaJSnTMe7Fyzc10wP3TWQXA3zmvx1JAWwUg 1OtXJGH6kzgf/wI8BsyMiThUORk6qMybm17PgqSNGzvCYvOnfezWyq2LC5i9xbc1ua/O WOaUEfp1K3b4OGK8n7Qae5PIsE3BIy/7UuqzRq3/WLnwAbipaIJAjc3F7olUea/8klyp 2G++gvSCWHOedlukSz/QhH9QUDek7jIE8MYLRU112nQ4zakrNlPEIroZLleboRUnBlcY Zscw== 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=hMPHl/WKffRdAtEPMV68QA4fZl4QATiWdHcUkbdlFgw=; b=TAQtoOThXuU/MZBRCpAyhX0r5asniAEgCkFSBGiBx90XObEJ9KS748lm9tID5jFOE7 3DbWTtUfdMxyVgEiCS8kvQm4fCID0TncNKQ6B7C90bfZB+8RuENy62EM5ScttMIbbRSK m9a4XfKm445JnFeu7ZwmPokKGkP3hsUUqw8n4d93qA3vtx+8j5P7gXfz7qb2U79TEkMe Pn7UvlAX3S+9SIbEZlLcv9aCgoveEtd7H4f+vMPr1iqUBZLc/MUT6qgtc3svHsd7iLbt 9oIWM18wEP4oJqcvgFa3EZwuWS2xlf+19gTca7wJVEcprdnIor29izXyeraT3J5fVi8T nafA== X-Gm-Message-State: AIkVDXKsDjUGb7gwcYAoArgWA78gfA56cgC3ep4OZYZsEQO5sy789+YNGbQDOoRDyUz4X0MNEpqv89YdAS9aqP0C X-Received: by 10.36.71.207 with SMTP id t198mr12543363itb.98.1486483933040; Tue, 07 Feb 2017 08:12:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 7 Feb 2017 08:12:12 -0800 (PST) From: Ben Schwartz Date: Tue, 7 Feb 2017 11:12:12 -0500 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1145b664cb83d20547f302a1 Archived-At: Subject: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:12:15 -0000 --001a1145b664cb83d20547f302a1 Content-Type: text/plain; charset=UTF-8 Hi TLS, Like a lot of people here, I'm very interested in ways to reduce the leakage of users' destinations in the ClientHello's cleartext SNI. It seems like the past and current proposals to fix the leak are pretty difficult, involving a lot of careful cryptography and changes to clients and servers. While we're trying to figure that out, I think there's a simple trick that could help a lot: just let domain owners tell users an alternate SNI in a DNS entry. Here's the full draft: https://tools.ietf.org/html/draft-schwartz-dns-sni-00 If you just want to glance at it, I recommend Figure 2. Please read and critique! This is a starting point; the contents will change based on your input. Thanks, Ben Schwartz --001a1145b664cb83d20547f302a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi TLS,

Like a lot of people here, I= 9;m very interested in ways to reduce the leakage of users' destination= s in the ClientHello's cleartext SNI.=C2=A0 It seems like the past and = current proposals to fix the leak are pretty difficult, involving a lot of = careful cryptography and changes to clients and servers.

While we're trying to figure that out, I think there's a sim= ple trick that could help a lot: just let domain owners tell users an alter= nate SNI in a DNS entry.

Here's the full draft= :
=
If you just want to glance at it, I recommend Figure 2.

Please read and critique!=C2=A0 This is a starting poi= nt; the contents will change based on your input.

= Thanks,
Ben Schwartz
--001a1145b664cb83d20547f302a1-- From nobody Tue Feb 7 08:49: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 A1227129D6F for ; Tue, 7 Feb 2017 08:48:59 -0800 (PST) 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 O6jdJBL2ANEa for ; Tue, 7 Feb 2017 08:48:57 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4D37D129D6C for ; Tue, 7 Feb 2017 08:48:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 889AB1E997; Tue, 7 Feb 2017 18:48:55 +0200 (EET) 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 So78dIMgJfNU; Tue, 7 Feb 2017 18:48:54 +0200 (EET) 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 B5CA6C4; Tue, 7 Feb 2017 18:48:54 +0200 (EET) Date: Tue, 7 Feb 2017 18:48:53 +0200 From: Ilari Liusvaara To: Ben Schwartz Message-ID: <20170207164853.GA979@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: Cc: tls@ietf.org Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:48:59 -0000 On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote: > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and changes to clients > and servers. > > While we're trying to figure that out, I think there's a simple trick that > could help a lot: just let domain owners tell users an alternate SNI in a > DNS entry. > > Here's the full draft: > https://tools.ietf.org/html/draft-schwartz-dns-sni-00 > > If you just want to glance at it, I recommend Figure 2. > > Please read and critique! This is a starting point; the contents will > change based on your input. What is the reason for treating IPv6 and IPv4 differently? AFAIK, The way clients usually deal with IPv6, splitting will not work properly. I didn't see definition of the wire format of the record, or if it is RFC3597-compliant[1] (all new rrtypes SHOULD be RFC3597-compliant). I earlier had an idea for doing siminar thing via DNS records and a new SNI name type (with just a few bytes of space). The problematic practice with SNI was sending multiple name types, not using new name types with servers declaring support. [1] Basically means that authoritative servers, recursive reolvers, DNS caches, DNS forwarders and stub resolvers can all handle the data part as opaque data, not having to modify it in any way. -Ilari From nobody Tue Feb 7 09:13: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 05924129DC1 for ; Tue, 7 Feb 2017 09:13:12 -0800 (PST) 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 Ei9DkQUwtZbp for ; Tue, 7 Feb 2017 09:13:10 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 4E028129DBC for ; Tue, 7 Feb 2017 09:13:08 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D652120001A; Tue, 7 Feb 2017 17:13:07 +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 BFCFB200002; Tue, 7 Feb 2017 17:13:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486487587; bh=ohopuCsCWa+gaxE6lHfbSHqrVJvyyA/nnZO8wRUbMFQ=; l=5096; h=From:To:Date:References:In-Reply-To:From; b=t7SszxE+gw6hFfgPrPl14IdD/9B3YZHHvYt2Ok9cmFJOvkOszMDo8KVYCN416Uhqc RBzV061z6B4hXWnelkmb2OCOGbzqxFFI3TKekLU0DseDiQQa5YVuv3bxU/lOFE6oC8 UfJaFvQD1DGxviVt4Pio0fZifYDyd6OE2JbcF4iQ= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 886241E08C; Tue, 7 Feb 2017 17:13:07 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 12:13:07 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Tue, 7 Feb 2017 12:13:06 -0500 From: "Salz, Rich" To: Ben Schwartz , "tls@ietf.org" Thread-Topic: [TLS] New Draft: Using DNS to set the SNI explicitly Thread-Index: AQHSgVz2hjn7SSmHEU6HJqlcxXNoy6Fdx0jw Date: Tue, 7 Feb 2017 17:13:06 +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.39.116] Content-Type: multipart/alternative; boundary="_000_f94fe122889f478dae947f960ac048a9usma1exdag1mb3msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:13:12 -0000 --_000_f94fe122889f478dae947f960ac048a9usma1exdag1mb3msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIHRoZSBkb2MuICBJ4oCZbSBhIGxpdHRsZSBkdW1iLCBidXQgSSB0aGluayBhIG1vcmUg ZXhwYW5kZWQgbGFkZGVyIGRpYWdyYW0gZm9yIEZpZ3VyZSAyIHdvdWxkIGhhdmUgaGVscGVkIG1l Lg0KDQpUaGUgYmFzaWMgcHJvY2VzcyBpcyBxdWVyeSBETlMsIGdldCB0aGUgU05JIHJlY29yZCB2 YWx1ZSwgYW5kIHVzZSB0aGF0IGFzIHRoZSBTTkkgdmFsdWUgd2hlbiBjb25uZWN0aW5nIHRvIHRo ZSBkb21haW4sIHJpZ2h0PyBCdXQgSeKAmW0gbm90IHN1cmUgb2YgdGhlIGludGVyYWN0aW9uIG9m IENOQU1FIGVudHJpZXMgaGVyZS4gIERvIHlvdSBrZWVwIHRoZSBTTkkgdmFsdWUgaW4gdGhlIGZp cnN0LCBvciBkb2VzIGNuYW1lLWNoYXNpbmcgZXJhc2Uvb3ZlcnJpZGUgdGhlIGluaXRpYWwgdmFs dWU/DQoNCkFuZCBkb2VzIHRoaXMgcmVhbGx5IHByb3ZpZGUgbXVjaCBhZGRpdGlvbmFsIHByaXZh Y3k/ICBDYW7igJl0IHRoZSBhdHRhY2tlci9yZXByZXNzb3IgYWxzbyBkbyBETlMgcXVlcmllcyBh bmQgZmlndXJlIGl0IG91dD8gIFRoZXJlIHNob3VsZCBwcm9iYWJseSBiZSBzb21lIHRleHQgYXJv dW5kIHRoYXQgaXNzdWUuDQo= --_000_f94fe122889f478dae947f960ac048a9usma1exdag1mb3msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSByZWFkIHRoZSBkb2MuJm5ic3A7IEnigJlt IGEgbGl0dGxlIGR1bWIsIGJ1dCBJIHRoaW5rIGEgbW9yZSBleHBhbmRlZCBsYWRkZXIgZGlhZ3Jh bSBmb3IgRmlndXJlIDIgd291bGQgaGF2ZSBoZWxwZWQgbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgYmFzaWMg cHJvY2VzcyBpcyBxdWVyeSBETlMsIGdldCB0aGUgU05JIHJlY29yZCB2YWx1ZSwgYW5kIHVzZSB0 aGF0IGFzIHRoZSBTTkkgdmFsdWUgd2hlbiBjb25uZWN0aW5nIHRvIHRoZSBkb21haW4sIHJpZ2h0 PyBCdXQgSeKAmW0gbm90IHN1cmUgb2YgdGhlIGludGVyYWN0aW9uDQogb2YgQ05BTUUgZW50cmll cyBoZXJlLiZuYnNwOyBEbyB5b3Uga2VlcCB0aGUgU05JIHZhbHVlIGluIHRoZSBmaXJzdCwgb3Ig ZG9lcyBjbmFtZS1jaGFzaW5nIGVyYXNlL292ZXJyaWRlIHRoZSBpbml0aWFsIHZhbHVlPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QW5kIGRvZXMgdGhpcyByZWFsbHkgcHJvdmlkZSBtdWNoIGFkZGl0aW9uYWwgcHJpdmFj eT8mbmJzcDsgQ2Fu4oCZdCB0aGUgYXR0YWNrZXIvcmVwcmVzc29yIGFsc28gZG8gRE5TIHF1ZXJp ZXMgYW5kIGZpZ3VyZSBpdCBvdXQ/Jm5ic3A7IFRoZXJlIHNob3VsZCBwcm9iYWJseSBiZSBzb21l IHRleHQNCiBhcm91bmQgdGhhdCBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_f94fe122889f478dae947f960ac048a9usma1exdag1mb3msgcorpak_-- From nobody Tue Feb 7 11:11: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 CDD3B129DF0 for ; Tue, 7 Feb 2017 11:11:54 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (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 IxdRzkz9WoEz for ; Tue, 7 Feb 2017 11:11:53 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 11B731295A0 for ; Tue, 7 Feb 2017 11:11:53 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id 203so84157761ith.0 for ; Tue, 07 Feb 2017 11:11:53 -0800 (PST) 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=I5qARLOwF5VH2qTx1E6AgrELX8zC32PEn/3dAIjEeSM=; b=AZkbJ3kCRhXM7wi7Q1ddULXcVlAPTlz1CZvNNIJCpnyFey2C6hWPFXXd1WVxxKPJty 90H/mAj+Q1B94p98RICfcLgKEQvONPSUZ3A9d4rGbUEMAgMannwXki0o7cGO0Z0IxpcT LzAhqDdR5JPPvTmyTjnn32JPxEpxtBB8WAlZvQ/rpO2B5WWHYTWAiZAtkt+71KV0Luxs qlQZClAvYfR3aBXwLksnghGoh5CkXAXOuptN6lJj9+qoQsCcbXGuaq+EiailjJl6pvVA G4sAXi55SJ0uURTtyDyK6p+Q4q/moZAILAmbls3tmEvx4BLCJR93QGP3xsnvuVUeneE+ gPKw== 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=I5qARLOwF5VH2qTx1E6AgrELX8zC32PEn/3dAIjEeSM=; b=nweLajTbvETKnTfmcJS3SJ/H5+VvQBiSlMxzHuct+KOrA9nkOD4D8qohr6Ayt7Gw7P rcS8oJ6Aca8JDq+DClcRjbx+CklLml2iMhJL2INcgYWItFJpD91y4h7yHE6GTeb0INgh /4iL2aX2Xc3l1cB4X+comF4uIglGyueDFTcKrwqF3wYbgdCdRR3Zs72/Km4rwRVYIUVs C38ckVyjqzul34buWEXaUPALKAlaGSKqaCAhanNQBd7WF7LOuDhaeufo7mOYCOPLpa4Q gt28sYB3awxXSGr14mpzZ3dCH82IeVBdQ28k89DFOXxC6jNUTrVeEK+dWVfUerdsVbVC AhAw== X-Gm-Message-State: AIkVDXJ5X6aHuOCrFBNOJUJfxxmX4qn01z0K3I+wxd0Xtc9tlMCZfHfXL7rGk0s1KNLCUs3v6HerAo+BkEXpbTVN X-Received: by 10.36.1.147 with SMTP id 141mr13586384itk.65.1486494712265; Tue, 07 Feb 2017 11:11:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 7 Feb 2017 11:11:51 -0800 (PST) In-Reply-To: <20170207164853.GA979@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170207164853.GA979@LK-Perkele-V2.elisa-laajakaista.fi> From: Ben Schwartz Date: Tue, 7 Feb 2017 14:11:51 -0500 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1143d464496d7d0547f58563 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:11:55 -0000 --001a1143d464496d7d0547f58563 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 11:48 AM, Ilari Liusvaara wrote: > On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote: > > Hi TLS, > > > > Like a lot of people here, I'm very interested in ways to reduce the > > leakage of users' destinations in the ClientHello's cleartext SNI. It > > seems like the past and current proposals to fix the leak are pretty > > difficult, involving a lot of careful cryptography and changes to clients > > and servers. > > > > While we're trying to figure that out, I think there's a simple trick > that > > could help a lot: just let domain owners tell users an alternate SNI in a > > DNS entry. > > > > Here's the full draft: > > https://tools.ietf.org/html/draft-schwartz-dns-sni-00 > > > > If you just want to glance at it, I recommend Figure 2. > > > > Please read and critique! This is a starting point; the contents will > > change based on your input. > > What is the reason for treating IPv6 and IPv4 differently? AFAIK, The > way clients usually deal with IPv6, splitting will not work properly. > I proposed to treat IPv4 and IPv6 separately because a "dual stack" domain owner might reasonably have very different configurations for their IPv4 and IPv6 servers. For example, a domain owner might use shared hosting for IPv4, but assign each domain to a unique IPv6 address. Splitting the DNS record in this way allows the server operator to disable SNI (by publishing an SNI record with empty RDATA) for connections to the IPv6 servers, without affecting requests to the IPv4 servers. You raise a good point: this requires a dual-stack client to be able to generate different ClientHello messages for IPv4 and IPv6 servers during Happy Eyeballs. If that's impractical, then we can remove this split, and just be a little less flexible for "dual stack" server operators. Does anyone know whether it's reasonable for clients to generate ClientHello messages that depend on IPv4 vs IPv6? > > I didn't see definition of the wire format of the record, or if it > is RFC3597-compliant[1] (all new rrtypes SHOULD be RFC3597-compliant). > Thanks for the pointer. It should definitely be RFC 3597 compliant. I'll clarify that in the next version. > > I earlier had an idea for doing siminar thing via DNS records and a new > SNI name type (with just a few bytes of space). The problematic practice > with SNI was sending multiple name types, not using new name types with > servers declaring support. > OK. For now I don't see a reason to switch to a new name type, but having an SNI record might allow us to do so in the future (see the Extensibility section). > > [1] Basically means that authoritative servers, recursive reolvers, > DNS caches, DNS forwarders and stub resolvers can all handle the > data part as opaque data, not having to modify it in any way. > > > -Ilari > --001a1143d464496d7d0547f58563 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 7, 2017 at 11:48 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote:
> Hi TLS,
>
> Like a lot of people here, I'm very interested in ways to reduce t= he
> leakage of users' destinations in the ClientHello's cleartext = SNI.=C2=A0 It
> seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and changes to clie= nts
> and servers.
>
> While we're trying to figure that out, I think there's a simpl= e trick that
> could help a lot: just let domain owners tell users an alternate SNI i= n a
> DNS entry.
>
> Here's the full draft:
> https://tools.ietf.org/html/draft-sc= hwartz-dns-sni-00
>
> If you just want to glance at it, I recommend Figure 2.
>
> Please read and critique!=C2=A0 This is a starting point; the contents= will
> change based on your input.

What is the reason for treating IPv6 and IPv4 differently? AFAIK, Th= e
way clients usually deal with IPv6, splitting will not work properly.

I proposed to treat IPv4 and IPv6 separately= because a "dual stack" domain owner might reasonably have very d= ifferent configurations for their IPv4 and IPv6 servers.=C2=A0 For example,= a domain owner might use shared hosting for IPv4, but assign each domain t= o a unique IPv6 address.=C2=A0 Splitting the DNS record in this way allows = the server operator to disable SNI (by publishing an SNI record with empty = RDATA) for connections to the IPv6 servers, without affecting requests to t= he IPv4 servers.

You raise a good point: this requ= ires a dual-stack client to be able to generate different ClientHello messa= ges for IPv4 and IPv6 servers during Happy Eyeballs.=C2=A0 If that's im= practical, then we can remove this split, and just be a little less flexibl= e for "dual stack" server operators.=C2=A0 Does anyone know wheth= er it's reasonable for clients to generate ClientHello messages that de= pend on IPv4 vs IPv6?
=C2=A0

I didn't see definition of the wire format of the record, or if it
is RFC3597-compliant[1] (all new rrtypes SHOULD be RFC3597-compliant).
<= /blockquote>

Thanks for the pointer.=C2=A0 It should def= initely be RFC 3597 compliant.=C2=A0 I'll clarify that in the next vers= ion.
=C2=A0

I earlier had an idea for doing siminar thing via DNS records and a new
SNI name type (with just a few bytes of space). The problematic practice with SNI was sending multiple name types, not using new name types with
servers declaring support.

OK.=C2=A0 Fo= r now I don't see a reason to switch to a new name type, but having an = SNI record might allow us to do so in the future (see the Extensibility sec= tion).
=C2=A0

[1] Basically means that authoritative servers, recursive reolvers,
DNS caches, DNS forwarders and stub resolvers can all handle the
data part as opaque data, not having to modify it in any way.


-Ilari

--001a1143d464496d7d0547f58563-- From nobody Tue Feb 7 11:33: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 754DF129E5C for ; Tue, 7 Feb 2017 11:33:22 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (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 3ldKexi5pegu for ; Tue, 7 Feb 2017 11:33:18 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 9AED5129E52 for ; Tue, 7 Feb 2017 11:33:18 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id 203so84597859ith.0 for ; Tue, 07 Feb 2017 11:33:18 -0800 (PST) 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=mYtrwUuDuN8kC7tDH5rULFc5jL349wZ3jqw8gmIoPmU=; b=Q/Yzyjzff97E3oLyY5DUqmJfcmxlI/vBHcXx9+y5iKJnS47Lx3xehlB6/w4tcyceAv OxUJmbBxYPK32z20tG73iUvfdGmeaFPAZ/odi4eHeJvN83rglmwcv0QjD4qAiJrT0THW pKuQdUtUJx17t1i/zald/vre0BAL9B7A3xgYDIOAr7g7Pg9+e1aRd2M0/XpyVFN7x/qB cX5NWXZtclh8yTUBk+hCudPfVZ0gs1KLbTe32e/WqMGnYM9hL/Xtj6TY57Syx4yvmfl2 HeKT51kyL6gVj2QcJ8F1Bl/OMuL12rzH8xloYyxHsg7RMB1ydhiXT8+qpVwvntd34NSK Rrdw== 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=mYtrwUuDuN8kC7tDH5rULFc5jL349wZ3jqw8gmIoPmU=; b=ZGLXUk5iVSH0J1CbQIoT3AU3BqZQwWlInw0WU+y5hNOrUSVvZVi/1uK2l1xDhNu/o8 PmUbSFa9McO6XnBsLX6PKR8GrERnkFX+ysxgcB40v7KygN4ddVlGy5LVE4pLrJPYCoBz UQYueZcXte4gAznqn7b+bR2x0Ktkdv4eJm7c0rkJCRLVgYEGMoI4T9XCMHXobHfBFLnd fK2giN/aFzYnbpGLPNHLi2pix4x6NfAtWxKz/JvzrpcZZc9JFN97A33ELKoBpyxInolu CNC4iRSdXCBaEd0yZrEYdp1kNrHLkJAWwaXWRacPhudmUNbf+IwTv7qoJKtlGAHgWDPF 9f6g== X-Gm-Message-State: AIkVDXJ8DsnUoGcEEIMeVP69tCDLrNYLhLPBYOsBxMIOkObv8l+YPwvoiUIt4DZW6lxdQtZfsNOu3MeWQxNbXiQN X-Received: by 10.36.71.207 with SMTP id t198mr13479634itb.98.1486495997831; Tue, 07 Feb 2017 11:33:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 7 Feb 2017 11:33:17 -0800 (PST) In-Reply-To: References: From: Ben Schwartz Date: Tue, 7 Feb 2017 14:33:17 -0500 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a1145b664e9ada10547f5d10c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:33:22 -0000 --001a1145b664e9ada10547f5d10c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 7, 2017 at 12:13 PM, Salz, Rich wrote: > I read the doc. > Thanks! > I=E2=80=99m a little dumb, but I think a more expanded ladder diagram f= or Figure > 2 would have helped me. > OK. I think I included all the packets. Is it unclear what each packet is? Did I miss some? Or would like you more explanation about what each endpoint is "thinking" at each step? > The basic process is query DNS, get the SNI record value, and use that as > the SNI value when connecting to the domain, right? > Yep, that's the whole idea in one sentence. > But I=E2=80=99m not sure of the interaction of CNAME entries here. Do yo= u keep > the SNI value in the first, or does cname-chasing erase/override the > initial value? > I wasn't intending any special interaction with CNAME, and (therefore) no CNAME chasing unless someone specifically CNAMEs _443._tcp.foo.example.com. So yes, you would keep the SNI value at the specified name. (DNAME would cause chasing.) Does that seem reasonable? > And does this really provide much additional privacy? > The examples section says A host that serves many subdomains with a single wildcard certificate could set the SNI of all subdomains to the same fixed subdomain, in order to prevent a passive adversary from learning which subdomain a user is accessing. I think that's a worthwhile benefit that would help real users today. > Can=E2=80=99t the attacker/repressor also do DNS queries and figure it ou= t? There > should probably be some text around that issue. > The section on optimizing privacy says: If the adversary has full knowledge of the contents of the global DNS (a strong adversary), then users of a domain only experience a privacy benefit if another domain at the same IP address uses the same SNI RDATA. The privacy benefit increases as more domains share the same SNI RDATA and the same IP addresses. What else would you like to see? --001a1145b664e9ada10547f5d10c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 7, 2017 at 12:13 PM, Salz, Rich <rsalz@akamai.com> wr= ote:

I read the doc.


Thanks!
=C2=A0

=C2=A0 I=E2= =80=99m a little dumb, but I think a more expanded ladder diagram for Figur= e 2 would have helped me.


OK.=C2=A0 I think I included all the packets.=C2=A0 Is it unclear wha= t each packet is?=C2=A0 Did I miss some?=C2=A0 Or would like you more expla= nation about what each endpoint is "thinking" at each step?
=
=C2=A0

The basic process is query DNS, get the SNI = record value, and use that as the SNI value when connecting to the domain, = right?


Yep, that'= ;s the whole idea in one sentence.
=C2=A0

But I=E2=80= =99m not sure of the interaction of CNAME entries here.=C2=A0 Do you keep the SNI value in the first, or do= es cname-chasing erase/override the initial value?


I wasn't intending any special interacti= on with CNAME, and (therefore) no CNAME chasing unless someone specifically= CNAMEs _443._tcp.foo.example.com.=C2=A0 So yes, you would keep the SNI value at the specified name. =C2=A0= (DNAME would cause chasing.) =C2=A0Does that seem reasonable?

The examples section says
   A host that se=
rves many subdomains with a single wildcard certificate
   could set the SNI of all subdomains to the same fixed subdomain, in
   order to prevent a passive adversary from learning which subdomain a
   user is accessing.

I think that's a worthwhile benefit that woul= d help real users today.

The section on optimizing privacy says:
   If the adversary has full k=
nowledge of the contents of the global DNS
   (a strong adversary), then users of a domain only experience a
   privacy benefit if another domain at the same IP address uses the
   same SNI RDATA.  The privacy benefit increases as more domains share
   the same SNI RDATA and the same IP addresses.

What else would you l= ike to see?

--001a1145b664e9ada10547f5d10c-- From nobody Tue Feb 7 17:14: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 901F31296FF for ; Tue, 7 Feb 2017 17:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 9Ln_Sj0QnRJk for ; Tue, 7 Feb 2017 17:14:51 -0800 (PST) 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 2305D1296F0 for ; Tue, 7 Feb 2017 17:14:50 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cbGqO-00036M-KU for tls@ietf.org; Wed, 08 Feb 2017 02:14:49 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cbGqM-0000MZ-4X for tls@ietf.org; Tue, 07 Feb 2017 20:14:46 -0500 Received: (qmail 22816 invoked from network); 8 Feb 2017 01:14:43 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Feb 2017 01:14:43 -0000 To: Ben Schwartz , Ilari Liusvaara References: <20170207164853.GA979@LK-Perkele-V2.elisa-laajakaista.fi> From: Christian Huitema Message-ID: <2ad02cb5-7ef0-9b27-818c-eb881f250519@huitema.net> Date: Tue, 7 Feb 2017 15:14:42 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------30228A2BAB678E07F8212C7D" X-Originating-IP: 168.144.250.223 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 Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpMT1P6XYz1AUwDDBg1NT8URcOb18WfxGyg6Om6u4YYm+2z8zFgNNTT0xn2 LclGjHY5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKRQRCdMNhge1Unb77YyuZq6s+SIRWXQfQlHyqCmjPsZTRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76Fosz60lBu3d5bfCNNtiN+o6mxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fImIDv5nM6eiChzNVX4AW5QuzGD CsEA6FKlj9/rPsOe4zEvuGslKTrRIXcXpFg5ivY= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 01:14:52 -0000 This is a multi-part message in MIME format. --------------30228A2BAB678E07F8212C7D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/7/2017 9:11 AM, Ben Schwartz wrote: > ... > > I proposed to treat IPv4 and IPv6 separately because a "dual stack" > domain owner might reasonably have very different configurations for > their IPv4 and IPv6 servers. For example, a domain owner might use > shared hosting for IPv4, but assign each domain to a unique IPv6 > address. Splitting the DNS record in this way allows the server > operator to disable SNI (by publishing an SNI record with empty RDATA) > for connections to the IPv6 servers, without affecting requests to the > IPv4 servers. > I am not sure that this is the right trade-off. If some adversary censors based on the SNI, they will also be able to censor based on the IP address of the server (v4 or v6). The resistance to censorship (or monitoring) only happens if the connections are proxied through another service. I would think that you want the name of that proxy service in the DNS, independently of the network configuration. -- Christian Huitema --------------30228A2BAB678E07F8212C7D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 2/7/2017 9:11 AM, Ben Schwartz wrote:

...

I proposed to treat IPv4 and IPv6 separately because a "dual stack" domain owner might reasonably have very different configurations for their IPv4 and IPv6 servers. For example, a domain owner might use shared hosting for IPv4, but assign each domain to a unique IPv6 address. Splitting the DNS record in this way allows the server operator to disable SNI (by publishing an SNI record with empty RDATA) for connections to the IPv6 servers, without affecting requests to the IPv4 servers.


I am not sure that this is the right trade-off. If some adversary censors based on the SNI, they will also be able to censor based on the IP address of the server (v4 or v6). The resistance to censorship (or monitoring) only happens if the connections are proxied through another service. I would think that you want the name of that proxy service in the DNS, independently of the network configuration.

-- Christian Huitema
--------------30228A2BAB678E07F8212C7D-- From nobody Tue Feb 7 18:49: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 4D8081294D8 for ; Tue, 7 Feb 2017 18:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, 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 CevWZROWtC-t for ; Tue, 7 Feb 2017 18:49:24 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 27C99129416 for ; Tue, 7 Feb 2017 18:49:24 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7D897433457; Wed, 8 Feb 2017 02:49:23 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 6744A433412; Wed, 8 Feb 2017 02:49:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486522163; bh=a6NOlQP1logRB92AjFQt+f93u/tTBK8Mw/kVm9Fa0IY=; l=1126; h=From:To:CC:Date:References:In-Reply-To:From; b=zUXr4cQWmBDOsuTXL4cttFvlloBx7gHMtuIYtCJMI7zq2vleM3xsbVP0nR2PR+X0E i5WJkmeapuzhDPJnNG/UJBhUEOLtxGv+jyhZXGqLOdjnyXvX7/mTVXc34uziOEvGBM DiLlmckJ8c6C6h5g9bOL9eGZfsp0mg3Uo0r/oI5o= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5E1EA1FC8B; Wed, 8 Feb 2017 02:49:23 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 21:49:22 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Tue, 7 Feb 2017 21:49:23 -0500 From: "Salz, Rich" To: Ben Schwartz Thread-Topic: [TLS] New Draft: Using DNS to set the SNI explicitly Thread-Index: AQHSgVz2hjn7SSmHEU6HJqlcxXNoy6Fdx0jwgAB734CAACOYsA== Date: Wed, 8 Feb 2017 02:49:22 +0000 Message-ID: <3d8a93baa91240c2bf9d980e3ebfb337@usma1ex-dag1mb3.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.33.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 02:49:25 -0000 DQo+VGhlIGV4YW1wbGVzIHNlY3Rpb24gc2F5cw0KPiAgIEEgaG9zdCB0aGF0IHNlcnZlcyBtYW55 IHN1YmRvbWFpbnMgd2l0aCBhIHNpbmdsZSB3aWxkY2FyZCBjZXJ0aWZpY2F0ZQ0KPiAgIGNvdWxk IHNldCB0aGUgU05JIG9mIGFsbCBzdWJkb21haW5zIHRvIHRoZSBzYW1lIGZpeGVkIHN1YmRvbWFp biwgaW4NCj4gICBvcmRlciB0byBwcmV2ZW50IGEgcGFzc2l2ZSBhZHZlcnNhcnkgZnJvbSBsZWFy bmluZyB3aGljaCBzdWJkb21haW4gYQ0KPiAgIHVzZXIgaXMgYWNjZXNzaW5nLg0KDQo+IEkgdGhp bmsgdGhhdCdzIGEgd29ydGh3aGlsZSBiZW5lZml0IHRoYXQgd291bGQgaGVscCByZWFsIHVzZXJz IHRvZGF5Lg0KDQpBbmQgdGhlbiB0aGUgc2VydmVyIHRydXN0cyB0aGUgSG9zdCBoZWFkZXI/ICBU aGF0IHByb2JhYmx5IHdvcmtzIGlmIHRoZSBzZXJ2ZXIgaGFzIGEgZGVmaW5pdGl2ZSBsaXN0IG9m IHRoZSBob3N0cyBpdCBzZXJ2ZXMuICBCdXQgZG8gbm90IHRoYXQgdGhlcmUgY2FuIGJlIGlzc3Vl cyB3aXRoICJqdXN0IHRydXN0aW5nIiB0aGUgSG9zdCBoZWFkZXIuICBGb3IgZXhhbXBsZSwgaW4g YSBDRE4geW91IG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgeW91IGRvbid0IGJlY29tZSBhbiBvcGVu IHByb3h5LiAgDQoNCkJ1dCBJIGRvIHRoaW5rIHRoYXQgdGhpcyBtaWdodCBiZSB0aGUgbW9zdCBs aWtlbHkgcHJpdmFjeSBiZW5lZml0IC0tIGFnZ3JlZ2F0aW9uIGludG8gYSBsYXJnZXIgYW5vbnlt aXR5IHNldCAtLSBhbmQgc2hvdWxkIGJlIHVwIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50LCBvciBh dCBsZWFzdCB0ZWxlZ3JhcGhlZCA6KQ0K From nobody Tue Feb 7 19:29: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 9BAA212979D for ; Tue, 7 Feb 2017 19:29:42 -0800 (PST) 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=unavailable 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 tSxlk5e92eHA for ; Tue, 7 Feb 2017 19:29:41 -0800 (PST) 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 E45961297CE for ; Tue, 7 Feb 2017 19:20:29 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id l66so106539294ioi.1 for ; Tue, 07 Feb 2017 19:20:29 -0800 (PST) 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=7J7HdJdilfKUwQQG07iu5rBKf2pioEznXQI1nNjj0tU=; b=Ita2oTad3gLOvVnlOA5wX7L7Di3yPtE0OYlevjSQkN7pkN7uvU/BZKR6wbgv05C1pb HhUGba6ltRcVXKg3rKlTpAhKa0b9rK40zIdzjiwFM4ksRh5xxgIe1T073nd0YFjqtMU4 DNRVjSVy4O1kWG3N5qTAVTV/FsHkrkLde+OdASdedTjLt+Ta5UwXPCZSdkEjYGHwPc5G OxIFZJd/gVk+vLIlRoEEXA6e1kjipvE6Psn2bgP2UOiTqwfO1eUp+V9MQ7wJqggBm0gN 4VQ6H3mjQywmGAchWDtyAbsobEs3djPtZ5OPH82WjGKVPRSyVJPz9QJBKgS6G38XSu// JqDQ== 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=7J7HdJdilfKUwQQG07iu5rBKf2pioEznXQI1nNjj0tU=; b=WM4UxI5IkDYsuQ1VmfJiS40tGMmNqLxDlPHW1+STUf6YaiZ+xsh7q2CmY0amf3FIsg GPISQ4r8it3u1NBYHt25NEb9lJQwGRAkOwSJOpOnrISuiuC1NPL6PBBTTZkUwDW5OxvO ufE3UA7gFjq6H5nvdAStykez9offXaOBMnCyf7KCtKnD7ZljuHQFM+hIo61WJX3Y8Ylt MEddlR29X0PY4rAcaLhJx3OwykwjHI9l9iuZkr9h0yq9BPj/T5uvy2v97C7axW5LIWLB ZLAdJt+TVVaCQTXFeIrYhYOrGvqhjpAGHJqMasimLdhn23ePQF8CRjaPV6Ni3fvIEGT4 MSNQ== X-Gm-Message-State: AMke39lZCyd/Fc1nP7vadhDK9ORMWzhs0p1+sn0U8vjh26LT+EJr+zlcRYNd6mAzC4mwdB96sS33hs3bTmBtWMxY X-Received: by 10.107.15.70 with SMTP id x67mr6857602ioi.103.1486524029155; Tue, 07 Feb 2017 19:20:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Tue, 7 Feb 2017 19:20:28 -0800 (PST) In-Reply-To: <2ad02cb5-7ef0-9b27-818c-eb881f250519@huitema.net> References: <20170207164853.GA979@LK-Perkele-V2.elisa-laajakaista.fi> <2ad02cb5-7ef0-9b27-818c-eb881f250519@huitema.net> From: Ben Schwartz Date: Tue, 7 Feb 2017 22:20:28 -0500 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a113ed7feb572230547fc5852 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 03:29:42 -0000 --001a113ed7feb572230547fc5852 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 8:14 PM, Christian Huitema wrote: > On 2/7/2017 9:11 AM, Ben Schwartz wrote: > > ... > > I proposed to treat IPv4 and IPv6 separately because a "dual stack" domain > owner might reasonably have very different configurations for their IPv4 > and IPv6 servers. For example, a domain owner might use shared hosting for > IPv4, but assign each domain to a unique IPv6 address. Splitting the DNS > record in this way allows the server operator to disable SNI (by publishing > an SNI record with empty RDATA) for connections to the IPv6 servers, > without affecting requests to the IPv4 servers. > > > I am not sure that this is the right trade-off. If some adversary censors > based on the SNI, they will also be able to censor based on the IP address > of the server (v4 or v6). The resistance to censorship (or monitoring) only > happens if the connections are proxied through another service. I would > think that you want the name of that proxy service in the DNS, > independently of the network configuration. > > -- Christian Huitema > I agree: against "knowledgeable" adversaries, moving services onto separate IPs hurts instead of helping, so my example isn't great motivation. Based on your and Ilari's feedback, I'll probably remove the v4/v6 split unless we can come up with a more attractive version. --001a113ed7feb572230547fc5852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 7, 2017 at 8:14 PM, Christian Huitema <huitema@huitema.net&g= t; wrote:
=20 =20 =20

On 2/7/2017 9:11 AM, Ben Schwartz wrote:

...

I proposed to treat IPv4 and IPv6 separately because a "dual stack" domain owner might reasonably have ver= y different configurations for their IPv4 and IPv6 servers.=C2= =A0 For example, a domain owner might use shared hosting for IPv4, but assign each domain to a unique IPv6 address.=C2=A0 Splitting the DNS record in this way allows the server operator to disable SNI (by publishing an SNI record with empty RDATA) for connections to the IPv6 servers, without affecting requests to the IPv4 servers.


I am not sure that this is the right trade-off. If some adversary censors based on the SNI, they will also be able to censor based on the IP address of the server (v4 or v6). The resistance to censorship (or monitoring) only happens if the connections are proxied through another service. I would think that you want the name of that proxy service in the DNS, independently of the network configuration.

-- Christian Huitema

I agree: against &q= uot;knowledgeable" adversaries, moving services onto separate IPs hurt= s instead of helping, so my example isn't great motivation.=C2=A0 Based= on your and Ilari's feedback, I'll probably remove the v4/v6 split= unless we can come up with a more attractive version.
--001a113ed7feb572230547fc5852-- From nobody Tue Feb 7 23:13: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 9E8CD129572 for ; Tue, 7 Feb 2017 23:13:21 -0800 (PST) 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, 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 9CCwaO0L4meK for ; Tue, 7 Feb 2017 23:13:20 -0800 (PST) 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 89C491294F3 for ; Tue, 7 Feb 2017 23:13:19 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id o16so54942443wra.1 for ; Tue, 07 Feb 2017 23:13:19 -0800 (PST) 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=KNmR42103SHRHU+fXCAHw623Q9IXEK0fCoNixq1MaY0=; b=E1rczImvRwO2xN4c0ffqM7GUWJYOvoLxX4TFp6GM6ExKyBlple7+edC7qpVXcWoY1N 8JHsHGxKZpwuzsnnhy3dyy5p6IApcJtznBCzmk4l0qeq6dJ5TUhehKv32/t6lL9hry3S TyHC0zFUZB4iuBuF9K/cb+7ivRd2Ciq0pgGAcf350Rn6tiJ8648IOirDjcQognFq4yZ/ SSHql8Sz/rgnI+bc+LSAN5pjOHRtgFhmmpJxe4eKqIlQ2Sqf+dE/qxxjVP6exabR9dDI TFMpnn0A15QscIBpuSk+Sp+TwbdQfGwquJIQ2XUF/cudCml/VAHhePpX01IOkRDF7kND YTgA== 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=KNmR42103SHRHU+fXCAHw623Q9IXEK0fCoNixq1MaY0=; b=rjTIHt/ouvl4eNL5cj0BaQHWFAO5f1rm/6u0GGxOjBlJJyixXh/zAooat3MZb5i4yz RmVMOn99CLd4BpJQRlUkUxpDgV5WPN4eaBmJ2cnQXTgzopgTdQdIDXUaLI2wZxX+d1Xk otpVwHj97co1X5YFAiU5/VzC952dqXjhY5img6U5eYYqbbySIMFP0YbiCZ4vPB2GtNBq Qm0p3wUNkYeiho5aJeK0kVrUhx5dYvRKd8VCNHrM/y7gBBTKxWN1VrYDQ+lpV6elBlfg JBSMhEX1aYx2gyVL0jQdq1Yhfg0QLD4I5IVauaGjOioPIkQ6Mpqve5Q5szhiI1dfdTr4 m/4Q== X-Gm-Message-State: AMke39kcbOQqMGof+7cjYzBl7BEPDLYfc8H+pDAiqmeb0Sm3xD9UR8O5g9A3O72oPQB1rg== X-Received: by 10.223.130.204 with SMTP id 70mr17043999wrc.128.1486537997968; Tue, 07 Feb 2017 23:13:17 -0800 (PST) Received: from users-mbp.mshome.net ([109.253.228.86]) by smtp.gmail.com with ESMTPSA id c9sm1662474wmf.18.2017.02.07.23.13.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 23:13:16 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7FAF0DBF-62A6-4FA4-9C24-F6BB04195294"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 09:12:59 +0200 In-Reply-To: To: Ben Schwartz References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 07:13:21 -0000 --Apple-Mail=_7FAF0DBF-62A6-4FA4-9C24-F6BB04195294 Content-Type: multipart/alternative; boundary="Apple-Mail=_B68ADCB2-1876-4E31-90A1-6E0A079D7E69" --Apple-Mail=_B68ADCB2-1876-4E31-90A1-6E0A079D7E69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 7 Feb 2017, at 18:12, Ben Schwartz wrote: > Hi TLS, >=20 > Like a lot of people here, I'm very interested in ways to reduce the = leakage of users' destinations in the ClientHello's cleartext SNI. It = seems like the past and current proposals to fix the leak are pretty = difficult, involving a lot of careful cryptography and changes to = clients and servers. >=20 > While we're trying to figure that out, I think there's a simple trick = that could help a lot: just let domain owners tell users an alternate = SNI in a DNS entry. >=20 > Here's the full draft: > https://tools.ietf.org/html/draft-schwartz-dns-sni-00 = >=20 > If you just want to glance at it, I recommend Figure 2. >=20 > Please read and critique! This is a starting point; the contents will = change based on your input. Hi, Ben I=E2=80=99m a little surprised that you depend on RFC 7858 (DNS over = TLS), which is fairly new and lightly deployed, but do not depend on = DNSSEC, which is (slowly) getting traction. If you assign a one fake SNI to each real name, then a determined = adversary (especially the police state) can map the fake SNIs for all = domains of interest and you lose the privacy. If you assign one fake SNI for a bunch of real names, then the best an = adversary can do is to associate a visible SNI with a group of names, = some of which may be innocuous. But I=E2=80=99m thinking, why do we need = SNI at all in the TLS handshake? Obvious answer is to select the right = certificate, but under this scenario the certificate already has to have = the names of all domains possibly hosted on the server. So why not instead use secure delegation using signed CNAME records and = a new record (which perhaps should be called =E2=80=9CnoSNI=E2=80=9D). = Then the diagram looks like this: DNS Server Client TLS Server | | | |<=3D=3D=3Dexample.com AAAA?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| = | |<=3D_443._tcp.example.com NOSNI?=3D| = | |=3Dexample.com CNAME a7.cdn.net=3D>| = | |=3D=3Da7.cdn.net AAAA 2001:db8::1=3D>| = | |=3D=3Dexample.com NOSNI cdn.net=3D=3D=3D>| = | | |--------------TCP SYN----------->| | |<------------TCP SYN+ACK---------| | |--------------TCP ACK----------->| | |------ClientHello SNI:none------>| | |<--------- ServerHello ----------| | |<-- Certificate name:cdn.net ----| And the server works it out using the HOST header as Rich said. Of = course this depends heavily on DNSSEC validation, but it would work with = any version of TLS. Yoav --Apple-Mail=_B68ADCB2-1876-4E31-90A1-6E0A079D7E69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Feb 2017, at 18:12, = Ben Schwartz <bemasc@google.com> wrote:

Hi TLS,

Like a lot of people here, I'm very interested in ways to = reduce the leakage of users' destinations in the ClientHello's cleartext = SNI.  It seems like the past and current proposals to fix the leak = are pretty difficult, involving a lot of careful cryptography and = changes to clients and servers.

While we're trying to figure that out, = I think there's a simple trick that could help a lot: just let domain = owners tell users an alternate SNI in a DNS entry.

Here's the full = draft:
https://tools.ietf.org/html/draft-schwartz-dns-sni-00

If = you just want to glance at it, I recommend Figure 2.

Please read and = critique!  This is a starting point; the contents will change based = on your input.

Hi,= Ben

I=E2=80=99m a little surprised = that you depend on RFC 7858 (DNS over TLS), which is fairly new and = lightly deployed, but do not depend on DNSSEC, which is (slowly) getting = traction.

If you assign a one fake = SNI to each real name, then a determined adversary (especially the = police state) can map the fake SNIs for all domains of interest and you = lose the privacy.

If you assign one = fake SNI for a bunch of real names, then the best an adversary can do is = to associate a visible SNI with a group of names, some of which may be = innocuous. But I=E2=80=99m thinking, why do we need SNI at all in the = TLS handshake?  Obvious answer is to select the right certificate, = but under this scenario the certificate already has to have the names of = all domains possibly hosted on the server.

So why not instead use secure delegation using = signed CNAME records and a new record (which perhaps should be called = =E2=80=9CnoSNI=E2=80=9D). Then the diagram looks like = this:

  DNS Server       =                Client   =                    TLS = Server
     |           =                     | =                     =             |
    =  |<=3D=3D=3Dexample.com AAAA?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|   =                     =           |
    =  |<=3D_443._tcp.example.com NOSNI?=3D|         =                     =     |
     |=3Dexample.com CNAME a7.cdn.net=3D>|   =                     =           |
     |=3D=3D<= a href=3D"http://a7.cdn.net" class=3D"">a7.cdn.net AAAA = 2001:db8::1=3D>|               =                   = |
     |=3D=3Dexample.com NOSNI cdn.net=3D=3D=3D>|           =                     =   |
     |           =                     = |--------------TCP SYN----------->|
     | =                     =           |<------------TCP = SYN+ACK---------|
     |       =                     =     |--------------TCP = ACK----------->|
     |       =                     =     |------ClientHello = SNI:none------>|
     |       =                     =     |<--------- ServerHello = ----------|
     |           =                     = |<-- Certificate name:cdn.net= ----|

And = the server works it out using the HOST header as Rich said.  Of = course this depends heavily on DNSSEC validation, but it would work with = any version of TLS.

Yoav

= --Apple-Mail=_B68ADCB2-1876-4E31-90A1-6E0A079D7E69-- --Apple-Mail=_7FAF0DBF-62A6-4FA4-9C24-F6BB04195294 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----- iQEcBAEBCgAGBQJYmsT8AAoJELhJCxUKWMyZwX8H/Ru+qZtZNf7xVaks8XUPSml2 6uJr/s20osd8ECzEq6CsOA1wk2tU9immsb46oZzZwQgNijDrp9/ieDIm5x4Cwcf2 BK812U9VFhWgGuFXaw8LIP3XhqsHq7TVTJNoRyPNJRb04KpzaB4QKGmV6lhzQiLY G97hNQp1bvFy+iyNBqfqWkdLYTWF6u39L7xnYuSM5uFboLKAOKezcBFvV+7ggPq+ qareGlKFEU9mVsUJokecO8HKLEc76eKmIRroglOaZWn0O8XRMG49fbau1t5sMRxb VydTkD/Yg7lbn7E2mKTT2NjHLmi8C0x0F+UAccw5T6cCCVX17FDoa3otsaAunmE= =wdiB -----END PGP SIGNATURE----- --Apple-Mail=_7FAF0DBF-62A6-4FA4-9C24-F6BB04195294-- From nobody Wed Feb 8 06:06: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 25252129ADE for ; Wed, 8 Feb 2017 06:06:23 -0800 (PST) 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=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 z7YzFM0JNlAC for ; Wed, 8 Feb 2017 06:06:21 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 66D0C129AE1 for ; Wed, 8 Feb 2017 06:06:14 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id i68so109738227uad.0 for ; Wed, 08 Feb 2017 06:06:14 -0800 (PST) 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=nWo83wja/qS+LKaSCZ6X8+XiMlffwbj39IjvMqw2/tU=; b=TKWN4yXfSh0foJq6dWQulyu1MfDnX9iFKc0kZwX+ublm7LMnnmwX7JKgBBPKbJpeDY EupYEFor0pKDXDXa0wMl9cQUwC0hADr7NHhLiOGEcsWXAnrCDe5dqDSnppjFTqxPi88p QvJ8Q1hDfSOK2/Kz9Z7ppEOavAkfuwl9K0YAQRIvFCnFA8g8wWjtDbCcbUF6Fm5dseUO YTieL37lf8hkakrtZ1jvxs72my6USeJKr1vRwXzqo97mN2OtkKXSy3m2RTc2PdgaZj+S dCLvBaZQfMz502tIiKiHiqx91AUgYvjCArXtxup1IpvUTWJyogtAlGo4qcBS6/3obBvT jXMw== 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=nWo83wja/qS+LKaSCZ6X8+XiMlffwbj39IjvMqw2/tU=; b=f/BoOTB0mYaG3mnoYzHWhENP9TDtLOVmwFRf44BizKHaYauHJpzDRUVQG3JMTkVMdr Zb8A5kVTf2eSGbqG+YvFc1h5Dg1894FL0RUhfV5gNaoqRlen3aTknckPKKwfn9jCG+Cb HG1pcvmSXeoIwS/YOe9s9C75JYWSM/5twqy7Qdnh0oI0OWgaZFpiNygvKP7TbO+br+Ju 1V3rdXX0MGdhBrjic+lA9B53omlM2ov64nn1UpZVzN1z821/RJlDUJP5BoXKFONJwMHu Sop76PijXP9WFKdFv+mNfJfoyFLhHlsT4JQapo2e3HTlIB7rk0tFlL9lhuEuqZM/Y+Bf 1RoQ== X-Gm-Message-State: AIkVDXKjwkoKBSGUre1q+85izxo4lFnURrQhy3zKOJpT5guL6nmDMOsbv/6nSwe3QF4MBn4YHb+7SpXumtqSzA== X-Received: by 10.176.82.93 with SMTP id j29mr8734293uaa.57.1486562773411; Wed, 08 Feb 2017 06:06:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Wed, 8 Feb 2017 06:06:12 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Wed, 8 Feb 2017 09:06:12 -0500 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c1916a40bf1c70548055ecb Archived-At: Cc: "" Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:06:23 -0000 --94eb2c1916a40bf1c70548055ecb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For me, the main drawback here (besides the futuristic assumptions), is the continued reliance on the DNS infrastructure. Even when using TLS, the DNS is architecturally hostile to privacy, e.g., due to resolvers operated by ISPs or the client subnet extension. I'm sympathetic to the desire to get SNI off the wire or render it meaningless, but much more interested in solutions where information about reachability flows over paths that align with application-layer relationships (vs. lower layers), since these tend to align better with the parties that an endpoint already has to reveal its interests to. For example, the proposed HTTP ORIGIN frame [1] allows a web server to declare itself available to serve origins other than the one the client connected to, so that the client doesn't have to initiate new TLS connections for those origins. That doesn't eliminate the SNI problem, but it can reduce it in some cases by a couple orders of magnitude. --Richard [1] https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-01 On Wed, Feb 8, 2017 at 2:12 AM, Yoav Nir wrote: > > On 7 Feb 2017, at 18:12, Ben Schwartz wrote: > > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and changes to clients > and servers. > > While we're trying to figure that out, I think there's a simple trick tha= t > could help a lot: just let domain owners tell users an alternate SNI in a > DNS entry. > > Here's the full draft: > https://tools.ietf.org/html/draft-schwartz-dns-sni-00 > > If you just want to glance at it, I recommend Figure 2. > > Please read and critique! This is a starting point; the contents will > change based on your input. > > > Hi, Ben > > I=E2=80=99m a little surprised that you depend on RFC 7858 (DNS over TLS)= , which > is fairly new and lightly deployed, but do not depend on DNSSEC, which is > (slowly) getting traction. > > If you assign a one fake SNI to each real name, then a determined > adversary (especially the police state) can map the fake SNIs for all > domains of interest and you lose the privacy. > > If you assign one fake SNI for a bunch of real names, then the best an > adversary can do is to associate a visible SNI with a group of names, som= e > of which may be innocuous. But I=E2=80=99m thinking, why do we need SNI a= t all in > the TLS handshake? Obvious answer is to select the right certificate, bu= t > under this scenario the certificate already has to have the names of all > domains possibly hosted on the server. > > So why not instead use secure delegation using signed CNAME records and a > new record (which perhaps should be called =E2=80=9CnoSNI=E2=80=9D). Then= the diagram looks > like this: > > * DNS Server Client TLS Server= * > * | | |= * > * |<=3D=3D=3Dexample.com AAAA?=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D| > |* > * |<=3D_443._tcp.example.com NOSNI?=3D| > |* > * |=3Dexample.com CNAME a7.cdn.net > =3D>| |* > * |=3D=3Da7.cdn.net AAAA 2001:db8::1=3D>| > |* > * |=3D=3Dexample.com NOSNI cdn.net > =3D=3D=3D>| |* > * | |--------------TCP SYN----------->|= * > * | |<------------TCP SYN+ACK---------|= * > * | |--------------TCP ACK----------->|= * > * | |------ClientHello SNI:none------>|= * > * | |<--------- ServerHello ----------|= * > * | |<-- Certificate name:cdn.net > ----|* > > And the server works it out using the HOST header as Rich said. Of cours= e > this depends heavily on DNSSEC validation, but it would work with any > version of TLS. > > Yoav > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c1916a40bf1c70548055ecb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For me, the main drawback here (besides the futu= ristic assumptions), is the continued reliance on the DNS infrastructure.= =C2=A0 Even when using TLS, the DNS is architecturally hostile to privacy, = e.g., due to resolvers operated by ISPs or the client subnet extension.
=

I'm sympathetic to the desire to get SNI off the w= ire or render it meaningless, but much more interested in solutions where i= nformation about reachability flows over paths that align with application-= layer relationships (vs. lower layers), since these tend to align better wi= th the parties that an endpoint already has to reveal its interests to.
=
For example, the proposed HTTP ORIGIN frame [1] allows a web= server to declare itself available to serve origins other than the one the= client connected to, so that the client doesn't have to initiate new T= LS connections for those origins.=C2=A0 That doesn't eliminate the SNI = problem, but it can reduce it in some cases by a couple orders of magnitude= .

--Richard

[1] https://tools.iet= f.org/html/draft-ietf-httpbis-origin-frame-01


On Wed,= Feb 8, 2017 at 2:12 AM, Yoav Nir <ynir.ietf@gmail.com> wr= ote:
=
On 7 Feb 2017, at 18:12, Ben Schwartz <bemasc@google.com&= gt; wrote:

Hi TLS,

Like a lot of people here, I'm very inte= rested in ways to reduce the leakage of users' destinations in the Clie= ntHello's cleartext SNI.=C2=A0 It seems like the past and current propo= sals to fix the leak are pretty difficult, involving a lot of careful crypt= ography and changes to clients and servers.

While = we're trying to figure that out, I think there's a simple trick tha= t could help a lot: just let domain owners tell users an alternate SNI in a= DNS entry.

Here's the full draft:
<= a href=3D"https://tools.ietf.org/html/draft-schwartz-dns-sni-00" target=3D"= _blank">https://tools.ietf.org/html/draft-schwartz-dns-sni-00
<= /div>

If you just want to glance at it, I recommend Figu= re 2.

Please read and critique!=C2=A0 This is a st= arting point; the contents will change based on your input.

Hi, Ben

I=E2= =80=99m a little surprised that you depend on RFC 7858 (DNS over TLS), whic= h is fairly new and lightly deployed, but do not depend on DNSSEC, which is= (slowly) getting traction.

If you assign a one fa= ke SNI to each real name, then a determined adversary (especially the polic= e state) can map the fake SNIs for all domains of interest and you lose the= privacy.

If you assign one fake SNI for a bunch o= f real names, then the best an adversary can do is to associate a visible S= NI with a group of names, some of which may be innocuous. But I=E2=80=99m t= hinking, why do we need SNI at all in the TLS handshake?=C2=A0 Obvious answ= er is to select the right certificate, but under this scenario the certific= ate already has to have the names of all domains possibly hosted on the ser= ver.

So why not instead use secure delegation usin= g signed CNAME records and a new record (which perhaps should be called =E2= =80=9CnoSNI=E2=80=9D). Then the diagram looks like this:

=C2=A0 DNS Server =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0TLS Server
=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|<=3D=3D=3Dexampl= e.com AAAA?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =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|<=3D_443._tcp.example.com NOSNI?=3D| =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|=3Dexample.com CNAME a7.cdn.net=3D>| =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|=3D=3Da7.cdn.net AAAA 2001:db8::1=3D>| =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|=3D=3Dexample.c= om NOSNI cdn.net=3D=3D= =3D>| =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 |--------------TCP SYN----------->|
=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 |= <------------TCP SYN+ACK---------|
=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 |-------= -------TCP ACK----------->|
=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 |------ClientHe= llo SNI:none------>|
= =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 |<--------- ServerH= ello ----------|
=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 |<-- Certificate name:cdn.net ----|
=

And the server works it out using the HOST = header as Rich said.=C2=A0 Of course this depends heavily on DNSSEC validat= ion, but it would work with any version of TLS.

Yoav


<= /font>

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


--94eb2c1916a40bf1c70548055ecb-- From nobody Wed Feb 8 07:57: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 06996129BF8 for ; Wed, 8 Feb 2017 07:57:48 -0800 (PST) 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, 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 Mv7mSPHogEPE for ; Wed, 8 Feb 2017 07:57:46 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 33316129BED for ; Wed, 8 Feb 2017 07:57:46 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id r185so106171577ita.0 for ; Wed, 08 Feb 2017 07:57:46 -0800 (PST) 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=AcQ/dNLLUOmxgIhgwjKC8+y6nlGaJ9Wkn0KgxZ9a/U8=; b=qV/WyNvQBi6eHPYVEtEuAvdFeBBsDARnWHQWEkwRQxsbQJRRuj/Eduk2GyZPHRKUFt BfxoBiFEZJ7uYDuQibjMvHnNDVPc7eQn99RsdBbIwMWfswEw4IGLwK46Y3lObLVgIgVm IO9I/sdsR25XycPrBlAdDSax6siJ+FVpxmox3wU1KzFbuJA+ZafUNOQatbzhR4bNkVhQ ilBq6hrZRo5XDh1OecWr5W0r3VripclUmT5Kd8YKOdgvSmq7TsmY4bBbZrDsHXW1Zky6 H12VkDxNOH1RXEdjiyZ3zRHKq8w1bec2VpdQCms6V6gOr9el7DS4Nu20o2MCnvw3rdx+ 5y7Q== 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=AcQ/dNLLUOmxgIhgwjKC8+y6nlGaJ9Wkn0KgxZ9a/U8=; b=RhX5fWkqH970qTYN9ErR+LjmpXZIPwhtfEIpTIRJYze1FZnaaOkPtFva4HL6XA28bV ZdTwE6J+r5JJTySmHfkqy5hTGH6tewxazcLSN/BlaEAfhP62TNveLxog3VlHfld4zX2/ /8lB5TDCfg+6fZpLTK3zlG5fuMzlNoOEI4mjE7rAGMfisAm1PoOs+Uox6k2VvlEpcnFc dbJWvxEuz4ln/dAUk+0g4R59MImk+PLMAMjkjXrw/enhziL88xofyp5llahF0Qw1nwF8 JhDMWKdlCTdS7pRJwZrRTPuf424MfhHW6FecrTVHQGJtPrjNKzi9PeKHI1u2JFCQ817h ridA== X-Gm-Message-State: AIkVDXKrecIiVcFJO0I125nEkhWEeV/8BvOXXc5bza1SZWpuj+fvdUBsCeqRLgnwFfk8b8ddFQDEdjT3ryhrezRt X-Received: by 10.36.25.83 with SMTP id b80mr17493321itb.98.1486569465429; Wed, 08 Feb 2017 07:57:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Wed, 8 Feb 2017 07:57:44 -0800 (PST) In-Reply-To: References: From: Ben Schwartz Date: Wed, 8 Feb 2017 10:57:44 -0500 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11440182ec29ea054806ec0f Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:57:48 -0000 --001a11440182ec29ea054806ec0f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 8, 2017 at 2:12 AM, Yoav Nir wrote: > > On 7 Feb 2017, at 18:12, Ben Schwartz wrote: > > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and changes to clients > and servers. > > While we're trying to figure that out, I think there's a simple trick tha= t > could help a lot: just let domain owners tell users an alternate SNI in a > DNS entry. > > Here's the full draft: > https://tools.ietf.org/html/draft-schwartz-dns-sni-00 > > If you just want to glance at it, I recommend Figure 2. > > Please read and critique! This is a starting point; the contents will > change based on your input. > > > Hi, Ben > > I=E2=80=99m a little surprised that you depend on RFC 7858 (DNS over TLS)= , which > is fairly new and lightly deployed, but do not depend on DNSSEC, which is > (slowly) getting traction. > To be clear, the draft only depends on RFC 7858 for privacy, not integrity, against a "near" adversary who otherwise could learn the sensitive information by watching the client's DNS queries. Against that adversary, your proposal here would also need RFC 7858. Against a "far" adversary who can only see traffic to the TLS host, neither proposal needs RFC 7858. If you assign a one fake SNI to each real name, then a determined adversary > (especially the police state) can map the fake SNIs for all domains of > interest and you lose the privacy. > I agree. > If you assign one fake SNI for a bunch of real names, then the best an > adversary can do is to associate a visible SNI with a group of names, som= e > of which may be innocuous. But I=E2=80=99m thinking, why do we need SNI a= t all in > the TLS handshake? Obvious answer is to select the right certificate, bu= t > under this scenario the certificate already has to have the names of all > domains possibly hosted on the server. > > So why not instead use secure delegation using signed CNAME records and a > new record (which perhaps should be called =E2=80=9CnoSNI=E2=80=9D). Then= the diagram looks > like this: > > * DNS Server Client TLS Server= * > * | | |= * > * |<=3D=3D=3Dexample.com AAAA?=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D| > |* > * |<=3D_443._tcp.example.com NOSNI?=3D| > |* > * |=3Dexample.com CNAME a7.cdn.net > =3D>| |* > * |=3D=3Da7.cdn.net AAAA 2001:db8::1=3D>| > |* > * |=3D=3Dexample.com NOSNI cdn.net > =3D=3D=3D>| |* > * | |--------------TCP SYN----------->|= * > * | |<------------TCP SYN+ACK---------|= * > * | |--------------TCP ACK----------->|= * > * | |------ClientHello SNI:none------>|= * > * | |<--------- ServerHello ----------|= * > * | |<-- Certificate name:cdn.net > ----|* > > And the server works it out using the HOST header as Rich said. Of cours= e > this depends heavily on DNSSEC validation, but it would work with any > version of TLS. > > Yoav > > In the scenario where "the certificate already has to have the names of all domains", I think the draft already covers this without DNSSEC. The server operator can just set an SNI record with empty RDATA for _443._ tcp.example.com, indicating to the user that they should omit SNI. The case where we would need DNSSEC is if the default certificate _doesn't_ include example.com. I agree that supporting such cases would be good, but I don't think the marginal benefit justifies restricting the whole feature to only clients that do DNSSEC validation. --001a11440182ec29ea054806ec0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 8, 2017 at 2:12 AM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

On 7 Feb 2017, a= t 18:12, Ben Schwartz <bemasc@google.com> wrote:

Hi TLS,

Like a lot of pe= ople here, I'm very interested in ways to reduce the leakage of users&#= 39; destinations in the ClientHello's cleartext SNI.=C2=A0 It seems lik= e the past and current proposals to fix the leak are pretty difficult, invo= lving a lot of careful cryptography and changes to clients and servers.

While we're trying to figure that out, I think th= ere's a simple trick that could help a lot: just let domain owners tell= users an alternate SNI in a DNS entry.

Here's= the full draft:

If you just want to gl= ance at it, I recommend Figure 2.

Please read and = critique!=C2=A0 This is a starting point; the contents will change based on= your input.

Hi, Ben

I=E2=80=99m a little surprised that you depend on RF= C 7858 (DNS over TLS), which is fairly new and lightly deployed, but do not= depend on DNSSEC, which is (slowly) getting traction.

To be clear, the draft only depends on RFC 7858 for= privacy, not integrity, against a "near" adversary who otherwise= could learn the sensitive information by watching the client's DNS que= ries.=C2=A0 Against that adversary, your proposal here would also need RFC = 7858.=C2=A0 Against a "far" adversary who can only see traffic to= the TLS host, neither proposal needs RFC 7858.

If you assign a one fake SNI to each real name, then a determined = adversary (especially the police state) can map the fake SNIs for all domai= ns of interest and you lose the privacy.

<= /div>
I agree.=C2=A0
=C2=A0
If you assig= n one fake SNI for a bunch of real names, then the best an adversary can do= is to associate a visible SNI with a group of names, some of which may be = innocuous. But I=E2=80=99m thinking, why do we need SNI at all in the TLS h= andshake?=C2=A0 Obvious answer is to select the right certificate, but unde= r this scenario the certificate already has to have the names of all domain= s possibly hosted on the server.

So why not instea= d use secure delegation using signed CNAME records and a new record (which = perhaps should be called =E2=80=9CnoSNI=E2=80=9D). Then the diagram looks l= ike this:

= =C2=A0 DNS Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0TLS Server
=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|<=3D=3D=3Dexample.com AAAA?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =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|<=3D_443._tcp.example.com NOSNI?=3D| =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|=3Dex= ample.com CNAME a7.cdn.= net=3D>| =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|=3D=3Da7.cdn.net AAAA 2001:db8::1=3D>| =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|=3D=3Dexample.com NOSNI cdn.net=3D=3D=3D>| =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 |--------------TCP SYN----------->|
=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 |<------------TCP SYN+ACK---------|
=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 |--------------TCP ACK----------->|
<= font face=3D"Courier New">=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 |------ClientHello SNI:none------>|
=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 |= <--------- ServerHello ----------|
=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 |<-- = Certificate name:cdn.net -= ---|

And the server works i= t out using the HOST header as Rich said.=C2=A0 Of course this depends heav= ily on DNSSEC validation, but it would work with any version of TLS.
<= span class=3D"gmail-HOEnZb">

Yoa= v


In the scenario where "the certificate already = has to have the names of all domains", I think the draft already cover= s this without DNSSEC.=C2=A0 The server operator can just set an SNI record= with empty RDATA for _443._tcp.example.= com, indicating to the user that they should omit SNI.

The case where we wou= ld need DNSSEC is if the default certificate _doesn't_ include example.com.=C2=A0 I agree that supporting such= cases would be good, but I don't think the marginal benefit justifies = restricting the whole feature to only clients that do DNSSEC validation.
--001a11440182ec29ea054806ec0f-- From nobody Wed Feb 8 08:28: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 06BAD129C36 for ; Wed, 8 Feb 2017 08:28:11 -0800 (PST) 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 dt-a_Or2rEN6 for ; Wed, 8 Feb 2017 08:28:08 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 99088129C37 for ; Wed, 8 Feb 2017 08:28:08 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id j18so119747521ioe.2 for ; Wed, 08 Feb 2017 08:28:08 -0800 (PST) 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=R1/f+3fPTc+V2kwdIXfaohumOHC5Gj1Blx7y4QoGFnQ=; b=lEusAUFaITNmatcbPjUTNpYklEKpsu2ihCEW42MDdVw8qk4d4C4x02Iuln8xza5oB9 41Exg1HfE+C7KNXhFs85GJ0iNu+i2tJ1m0vlmO6OR0lThDZ3OSJbvocdCAbJqoD3EXwA b47LogEfFwieD7iaHynOdslmADEhffxXXPYrwlGkJVKvVLhCcAXs97N9WSWyHM+npfU2 XlA4ZFPlm0i5JKTVX/Zzkg8+1vlE/EAi+BUODgmXRo02kdAaOQhAbvD/nWUQndUJ1e5l alvnJ+OELJwuiFV8gqO4WnlXlm1l/X+DSF2N5uhzDVp3zySGYbXX91mSYT8AbUZbblSO 8dDQ== 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=R1/f+3fPTc+V2kwdIXfaohumOHC5Gj1Blx7y4QoGFnQ=; b=IYt4X222uJG23MloeHQt0qsiLkQQ9WzkBeHTbb42zzn+F58sIjSJUdNsgkY0bzDzBV Hu0k6lkk/pspgGNQZSQN1dTZ+8T4tUlZuUS65IxsgwYWq0rl/iawN7jBeU0gNH/5ZD8c e4muQ9SVCor8vMvATSIbWnudboGEQYi68e/H180AC71M3JIVZUJmM+go/6O1tlgJI2G9 POHfz1I7l4OkQQusA143Eo2E+thv2dOvVmwZgps0bgVXns/qwgVmVdqH3BWpqlfnqwEp 79dKO+sNdrTpwQQgONv5XOWA3gjxRRIyKY63WNzRYFR6gCNSKC0hZN0JQDS6YHo8SCcH TCYg== X-Gm-Message-State: AMke39kuifOwSd9Rvj2GwoohPppNEQGZH9HV1BNToWeEzM0YAnJUei21MIgOEQhKeqtKch8m1bzqa9Yq88VATUk+ X-Received: by 10.107.15.70 with SMTP id x67mr9416512ioi.103.1486571287744; Wed, 08 Feb 2017 08:28:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.164 with HTTP; Wed, 8 Feb 2017 08:28:07 -0800 (PST) In-Reply-To: References: From: Ben Schwartz Date: Wed, 8 Feb 2017 11:28:07 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a113ed7fe8a7ece0548075947 Archived-At: Cc: "" Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:28:11 -0000 --001a113ed7fe8a7ece0548075947 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 8, 2017 at 9:06 AM, Richard Barnes wrote: > For me, the main drawback here (besides the futuristic assumptions), is > the continued reliance on the DNS infrastructure. Even when using TLS, t= he > DNS is architecturally hostile to privacy, e.g., due to resolvers operate= d > by ISPs or the client subnet extension. > > I'm sympathetic to the desire to get SNI off the wire or render it > meaningless, but much more interested in solutions where information abou= t > reachability flows over paths that align with application-layer > relationships (vs. lower layers), since these tend to align better with t= he > parties that an endpoint already has to reveal its interests to. > I agree, which is part of why I'm very interested in DNS over HTTP [2] (but I think that's off-topic for this list). > For example, the proposed HTTP ORIGIN frame [1] allows a web server to > declare itself available to serve origins other than the one the client > connected to, so that the client doesn't have to initiate new TLS > connections for those origins. That doesn't eliminate the SNI problem, b= ut > it can reduce it in some cases by a couple orders of magnitude. > Yeah, I'm also very excited about HTTP ORIGIN, TLS Post-Handshake Auth [3], and anything else that lets us reuse our TLS tunnel for the most different stuff. However, I think these proposals are actually very complementary. The SNI record improves privacy on the initial connection to a server; HTTP ORIGIN improves privacy on subsequent connections to the same server. Together, they can make it so the SNI (1) is not proof of anything on its own and (2) is too infrequent for strong statistical attacks. [2] https://tools.ietf.org/html/draft-hoffman-dns-over-http-01 [3] https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00 > > --Richard > > [1] https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-01 > > > On Wed, Feb 8, 2017 at 2:12 AM, Yoav Nir wrote: > >> >> On 7 Feb 2017, at 18:12, Ben Schwartz wrote: >> >> Hi TLS, >> >> Like a lot of people here, I'm very interested in ways to reduce the >> leakage of users' destinations in the ClientHello's cleartext SNI. It >> seems like the past and current proposals to fix the leak are pretty >> difficult, involving a lot of careful cryptography and changes to client= s >> and servers. >> >> While we're trying to figure that out, I think there's a simple trick >> that could help a lot: just let domain owners tell users an alternate SN= I >> in a DNS entry. >> >> Here's the full draft: >> https://tools.ietf.org/html/draft-schwartz-dns-sni-00 >> >> If you just want to glance at it, I recommend Figure 2. >> >> Please read and critique! This is a starting point; the contents will >> change based on your input. >> >> >> Hi, Ben >> >> I=E2=80=99m a little surprised that you depend on RFC 7858 (DNS over TLS= ), which >> is fairly new and lightly deployed, but do not depend on DNSSEC, which i= s >> (slowly) getting traction. >> >> If you assign a one fake SNI to each real name, then a determined >> adversary (especially the police state) can map the fake SNIs for all >> domains of interest and you lose the privacy. >> >> If you assign one fake SNI for a bunch of real names, then the best an >> adversary can do is to associate a visible SNI with a group of names, so= me >> of which may be innocuous. But I=E2=80=99m thinking, why do we need SNI = at all in >> the TLS handshake? Obvious answer is to select the right certificate, b= ut >> under this scenario the certificate already has to have the names of all >> domains possibly hosted on the server. >> >> So why not instead use secure delegation using signed CNAME records and = a >> new record (which perhaps should be called =E2=80=9CnoSNI=E2=80=9D). The= n the diagram looks >> like this: >> >> * DNS Server Client TLS Serve= r* >> * | | = |* >> * |<=3D=3D=3Dexample.com AAAA?=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| >> |* >> * |<=3D_443._tcp.example.com NOSNI?=3D| >> |* >> * |=3Dexample.com CNAME a7.cdn.net >> =3D>| |* >> * |=3D=3Da7.cdn.net AAAA 2001:db8::1=3D>| >> |* >> * |=3D=3Dexample.com NOSNI cdn.net >> =3D=3D=3D>| |* >> * | |--------------TCP SYN----------->= |* >> * | |<------------TCP SYN+ACK---------= |* >> * | |--------------TCP ACK----------->= |* >> * | |------ClientHello SNI:none------>= |* >> * | |<--------- ServerHello ----------= |* >> * | |<-- Certificate name:cdn.net >> ----|* >> >> And the server works it out using the HOST header as Rich said. Of >> course this depends heavily on DNSSEC validation, but it would work with >> any version of TLS. >> >> Yoav >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a113ed7fe8a7ece0548075947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 8, 2017 at 9:06 AM, Richard Barnes <rlb@ipv.sx> 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">
For me, the main drawback here (besides the futuristic assumptions), is th= e continued reliance on the DNS infrastructure.=C2=A0 Even when using TLS, = the DNS is architecturally hostile to privacy, e.g., due to resolvers opera= ted by ISPs or the client subnet extension.

I'm= sympathetic to the desire to get SNI off the wire or render it meaningless= , but much more interested in solutions where information about reachabilit= y flows over paths that align with application-layer relationships (vs. low= er layers), since these tend to align better with the parties that an endpo= int already has to reveal its interests to.

I agree, which is part of why I'm very interested in D= NS over HTTP [2] (but I think that's off-topic for this list).
=C2=A0
For example, the proposed HTTP ORIGIN frame [1] allows a web ser= ver to declare itself available to serve origins other than the one the cli= ent connected to, so that the client doesn't have to initiate new TLS c= onnections for those origins.=C2=A0 That doesn't eliminate the SNI prob= lem, but it can reduce it in some cases by a couple orders of magnitude.

Yeah, I'm also very excit= ed about HTTP ORIGIN, TLS Post-Handshake Auth [3], and anything else that l= ets us reuse our TLS tunnel for the most different stuff.=C2=A0 However, I = think these proposals are actually very complementary.=C2=A0 The SNI record= improves privacy on the initial connection to a server; HTTP ORIGIN improv= es privacy on subsequent connections to the same server.=C2=A0 Together, th= ey can make it so the SNI (1) is not proof of anything on its own and (2) i= s too infrequent for strong statistical attacks.

[3]=C2=A0https://tools.ietf.org/html/draft-sullivan-tls-post-hands= hake-auth-00
=C2=A0

On Wed, Feb 8, 2017 at 2:12 AM, Yoav Nir <ynir.ietf@gmail.com&= gt; wrote:

On 7 Feb 2017, at 18:12, Ben Schwartz <bemasc@google.com> wrote:

Hi TLS,
Like a lot of people here, I'm very interested in way= s to reduce the leakage of users' destinations in the ClientHello's= cleartext SNI.=C2=A0 It seems like the past and current proposals to fix t= he leak are pretty difficult, involving a lot of careful cryptography and c= hanges to clients and servers.

While we're try= ing to figure that out, I think there's a simple trick that could help = a lot: just let domain owners tell users an alternate SNI in a DNS entry.

Here's the full draft:
If you just want to glance at it, I recommend Figure 2.

Please read and critique!=C2=A0 This is a starting point;= the contents will change based on your input.

Hi, Ben

I=E2=80=99m a litt= le surprised that you depend on RFC 7858 (DNS over TLS), which is fairly ne= w and lightly deployed, but do not depend on DNSSEC, which is (slowly) gett= ing traction.

If you assign a one fake SNI to each= real name, then a determined adversary (especially the police state) can m= ap the fake SNIs for all domains of interest and you lose the privacy.

If you assign one fake SNI for a bunch of real names, = then the best an adversary can do is to associate a visible SNI with a grou= p of names, some of which may be innocuous. But I=E2=80=99m thinking, why d= o we need SNI at all in the TLS handshake?=C2=A0 Obvious answer is to selec= t the right certificate, but under this scenario the certificate already ha= s to have the names of all domains possibly hosted on the server.

So why not instead use secure delegation using signed CNAME= records and a new record (which perhaps should be called =E2=80=9CnoSNI=E2= =80=9D). Then the diagram looks like this:

=C2=A0 DNS Server =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLS Server
=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|<=3D= =3D=3Dexample.com AAAA= ?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =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|<= =3D_443._tcp.example.c= om NOSNI?=3D| =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 |
<= div>=C2=A0 =C2=A0 =C2=A0|=3Dexample.com CNAME a7.cdn.net=3D>| =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|=3D=3Da7.cdn.= net AAAA 2001:db8::1=3D>| =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|=3D=3D= example.com NOSNI cdn.net=3D=3D=3D>| =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 |-----------= ---TCP SYN----------->|
= =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 |<------------TC= P SYN+ACK---------|
=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 |--------------TCP ACK----= ------->|
=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 |------ClientHello SNI:none------= >|
=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 |<--------- ServerHello ----------|
=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 |<-- Certificate name:cdn.net ----|

And the server works it out using the HOST header as Rich sai= d.=C2=A0 Of course this depends heavily on DNSSEC validation, but it would = work with any version of TLS.

Yoav

<= /div>

_______= ________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--001a113ed7fe8a7ece0548075947-- From nobody Wed Feb 8 11:34: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 D3D08129FC9 for ; Wed, 8 Feb 2017 11:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 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, RCVD_IN_MSPIKE_H2=-1.887, 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=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 6NOqtKcBYSXk for ; Wed, 8 Feb 2017 11:34:18 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0068.outbound.protection.outlook.com [104.47.36.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C00129FC6 for ; Wed, 8 Feb 2017 11:34:18 -0800 (PST) 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=PiMsN3tCMovAgJCwbxzebBbvoqCHmSFrF7ggd0wCD5Q=; b=IeW7cX/SFQJcgf0g8It1k09zqztpbnRCpAZEXZdOX4yfSU1Vs822uVhCE0SWvRq2rPIst4XkN5NMB8eSTcQKtl8gFvVtGYYEvVHN5P4X6mzWd8e3aPAuNblqMXzi0M0jIQk3E6r3Yzuq8SRkir9FHBcuYGC9B3FLoo28OPeov3E= 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_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 8 Feb 2017 19:34:16 +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.0860.027; Wed, 8 Feb 2017 19:34:16 +0000 From: Timothy Jackson To: "tls@ietf.org" Thread-Topic: TLS RSA-PSS and various versions of TLS Thread-Index: AQHSgkJV4V+iwvmWN0ytZtagmqJf3A== Date: Wed, 8 Feb 2017 19:34:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tjackson@mobileiron.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [198.61.62.10] x-ms-office365-filtering-correlation-id: e401ef00-340f-4283-a882-08d45059785a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR10MB1733; x-microsoft-exchange-diagnostics: 1; CY4PR10MB1733; 7:str5g5M6sIvXRuc/tscWmJe4kEz4eX5DqzRZRA/Z3T32qkD3TGCJUoS+wNUJ1+6ElkJUgzoAWADveCHUbh4BtD2iM1/MRNiG1MyHv0TXZ4jD0CzisXrc4jH5G1FEquQ7X3Gt47ItUZbgIqvxh2gUMWKtp0dpvxJT/YkgFKbaLn2Qj8rrE5e+Sjtf2AY4su0wwenJLktfkC9GHGjoWObxghvIX4/Uv18UvCtraXwsAAoJW5RG4qCgqOLJAmZeDlj0RMnKbyayEJT4wwVqk5BxOhM30JQhCyoQPDCPBN+yW2ZuW46P1ZhqfISFn9/pcTbRMUZCCVrz2rCqBGk01pgac8BHsgCrfhfyXX75of4Lr1hF0mfL8BOc8qtuh2VL/Wr9Vbo72T4Z6dGx/y7t5vQiwoMYt7D89dhTSiQPYIJZ7ufkQJDNFShOM5OH6CkwQ7d8vPGYrWurUeMYY+Ypah/lqXR8yLsmCOEin0h8yv4KcRZVop1CfxYX40csjpx0oZ9peIlCPsjx8ZcmeS0Lg93uzpa8Rwxuf620Gn8hQayrN0JORR8AxBOuv5gmJQRVhfoj x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(35073007944872)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020702029)(5005006)(8121501046)(20170203043)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR10MB1733; BCL:0; PCL:0; RULEID:; SRVR:CY4PR10MB1733; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39830400002)(39450400003)(199003)(189002)(6506006)(2501003)(101416001)(105586002)(189998001)(6116002)(97736004)(5640700003)(106356001)(122556002)(5660300001)(99286003)(102836003)(3846002)(81166006)(6436002)(2906002)(3280700002)(6916009)(66066001)(6486002)(25786008)(450100001)(54356999)(33656002)(68736007)(3660700001)(81156014)(1730700003)(83716003)(77096006)(106116001)(86362001)(82746002)(53936002)(110136004)(8676002)(38730400002)(50986999)(92566002)(6306002)(36756003)(6512007)(7736002)(2900100001)(8936002)(54896002)(2351001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1733; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mobileiron.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E521BA5F456344D2B186B11B7B214A15mobileironcom_" MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 19:34:16.6070 (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: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:34:22 -0000 --_000_E521BA5F456344D2B186B11B7B214A15mobileironcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGEgcXVlc3Rpb24gb24gUkZDNTI0NiAoVExTIDEuMikgYW5kIGhvdyBpdOKAmXMgZ29p bmcgdG8gaW50ZXJhY3Qgd2l0aCBSU0FTU0EtUFNTIGFzIHdlIHJvbGwgb3V0IFRMUyAxLjMuIERv ZXMgdGhlIHByb2hpYml0aW9uIGFnYWluc3QgUlNBU1NBLVBTUyBhcHBseSBvbmx5IHRvIHRoZSBz aWduYXR1cmVzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHNpZ25pbmcgaGFuZHNoYWtlcyBvciBkb2Vz IGl0IGFwcGx5IHRvIHRoZSBlbnRpcmUgY2VydGlmaWNhdGUgY2hhaW4gYXMgd2VsbD8gSSBhc2sg YmVjYXVzZSB3aGlsZSBJIHRoaW5rIHRoZSBsYXR0ZXIgbWF5IGhhdmUgYmVlbiB0aGUgaW50ZW50 IEkgaGF2ZSBub3QgZm91bmQgYW55dGhpbmcgdGhhdCBpbmRpY2F0ZXMgdGhlIGZvcm1lciBpcyBu b3QgYWN0dWFsbHkgd2hhdCB0aGUgUkZDcyByZXF1aXJlLg0KDQpUaGUgcmVsZXZhbnQgc2VjdGlv biBvZiBSRkM0MDU2IHJlYWRzOg0KDQo3LjQuMiBTZXJ2ZXIgQ2VydGlmaWNhdGUNCuKApg0KTm90 ZSB0aGF0IHRoZXJlIGFyZSBjZXJ0aWZpY2F0ZXMgdGhhdCB1c2UgYWxnb3JpdGhtcyBhbmQvb3Ig YWxnb3JpdGhtDQogICBjb21iaW5hdGlvbnMgdGhhdCBjYW5ub3QgYmUgY3VycmVudGx5IHVzZWQg d2l0aCBUTFMuICBGb3IgZXhhbXBsZSwgYQ0KICAgY2VydGlmaWNhdGUgd2l0aCBSU0FTU0EtUFNT IHNpZ25hdHVyZSBrZXkgKGlkLVJTQVNTQS1QU1MgT0lEIGluDQogICBTdWJqZWN0UHVibGljS2V5 SW5mbykgY2Fubm90IGJlIHVzZWQgYmVjYXVzZSBUTFMgZGVmaW5lcyBubw0KICAgY29ycmVzcG9u ZGluZyBzaWduYXR1cmUgYWxnb3JpdGhtLg0KDQpJIGRvbuKAmXQgc2VlIGFueXRoaW5nIGhlcmUg dGhhdCByZXN0cmljdHMgd2hpY2ggc2lnbmF0dXJlcyBjYW4gYmUgdXNlZCBvbiB0aGUgY2VydGlm aWNhdGVzIHRoZW1zZWx2ZXMuIElzIHRoYXQgYWNjdXJhdGU/IElmIHNvLCB0aGVuIEkgdGhpbmsg dGhlIHJlbGV2YW50IHJlc3RyaWN0aW9ucyBhcmUgbm90IGluIFRMUyBSRkNzIGF0IGFsbCwgYnV0 IHJhdGhlciBhcmUgaW4gUkZDcyBzdWNoIGFzIDQwNTUsIDQwNTYsIGFuZCA1NzU2LiBUaGVzZSBS RkNzIGFsbG93IFJTQVNTQS1QU1MuIElzIGl0IHRoZXJlZm9yZSBwZXJtaXNzaWJsZSB0byBoYXZl IGEgQ0EgdGhhdCBpcyBzaWduZWQgd2l0aCBSU0FTU0EtUFNTIHdpdGggVExTIDEuMCwgMS4xLCBv ciAxLjIuDQoNCklzIHRoaXMgd2hhdCB3YXMgaW50ZW5kZWQ/DQoNClRoYW5rcywNCg0KVGltDQo= --_000_E521BA5F456344D2B186B11B7B214A15mobileironcom_ Content-Type: text/html; charset="utf-8" Content-ID: <58DE13B895BD4A49923DF230CFBC4D45@namprd10.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA3NzA5 MjAxNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTkx OTY5MTM5MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDoxNzE0ODg2NDUyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTE5MjQ0Nzc2OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9 DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkkgaGF2ZSBhIHF1ZXN0aW9uIG9uIFJGQzUyNDYgKFRMUyAxLjIpIGFuZCBo b3cgaXTigJlzIGdvaW5nIHRvIGludGVyYWN0IHdpdGggUlNBU1NBLVBTUyBhcyB3ZSByb2xsIG91 dCBUTFMgMS4zLiBEb2VzIHRoZSBwcm9oaWJpdGlvbiBhZ2FpbnN0IFJTQVNTQS1QU1MgYXBwbHkg b25seSB0byB0aGUgc2lnbmF0dXJlcyB0aGF0IGNhbiBiZSB1c2VkIGZvciBzaWduaW5nDQogaGFu ZHNoYWtlcyBvciBkb2VzIGl0IGFwcGx5IHRvIHRoZSBlbnRpcmUgY2VydGlmaWNhdGUgY2hhaW4g YXMgd2VsbD8gSSBhc2sgYmVjYXVzZSB3aGlsZSBJIHRoaW5rIHRoZSBsYXR0ZXIgbWF5IGhhdmUg YmVlbiB0aGUgaW50ZW50IEkgaGF2ZSBub3QgZm91bmQgYW55dGhpbmcgdGhhdCBpbmRpY2F0ZXMg dGhlIGZvcm1lciBpcyBub3QgYWN0dWFsbHkgd2hhdCB0aGUgUkZDcyByZXF1aXJlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHJlbGV2YW50IHNlY3Rpb24g b2YgUkZDNDA1NiByZWFkczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjcuNC4yIFNlcnZlciBDZXJ0aWZpY2F0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Tm90ZSB0aGF0IHRoZXJlIGFyZSBjZXJ0aWZpY2F0ZXMgdGhhdCB1c2UgYWxn b3JpdGhtcyBhbmQvb3IgYWxnb3JpdGhtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBj b21iaW5hdGlvbnMgdGhhdCBjYW5ub3QgYmUgY3VycmVudGx5IHVzZWQgd2l0aCBUTFMuJm5ic3A7 IEZvciBleGFtcGxlLCBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBjZXJ0aWZpY2F0 ZSB3aXRoIFJTQVNTQS1QU1Mgc2lnbmF0dXJlIGtleSAoaWQtUlNBU1NBLVBTUyBPSUQgaW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IFN1YmplY3RQdWJsaWNLZXlJbmZvKSBjYW5ub3Qg YmUgdXNlZCBiZWNhdXNlIFRMUyBkZWZpbmVzIG5vPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAm bmJzcDtjb3JyZXNwb25kaW5nIHNpZ25hdHVyZSBhbGdvcml0aG0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGRvbuKAmXQgc2VlIGFueXRoaW5nIGhlcmUgdGhh dCByZXN0cmljdHMgd2hpY2ggc2lnbmF0dXJlcyBjYW4gYmUgdXNlZCBvbiB0aGUgY2VydGlmaWNh dGVzIHRoZW1zZWx2ZXMuIElzIHRoYXQgYWNjdXJhdGU/IElmIHNvLCB0aGVuIEkgdGhpbmsgdGhl IHJlbGV2YW50IHJlc3RyaWN0aW9ucyBhcmUgbm90IGluIFRMUyBSRkNzIGF0IGFsbCwgYnV0IHJh dGhlcg0KIGFyZSBpbiBSRkNzIHN1Y2ggYXMgNDA1NSwgNDA1NiwgYW5kIDU3NTYuIFRoZXNlIFJG Q3MgYWxsb3cgUlNBU1NBLVBTUy4gSXMgaXQgdGhlcmVmb3JlIHBlcm1pc3NpYmxlIHRvIGhhdmUg YSBDQSB0aGF0IGlzIHNpZ25lZCB3aXRoIFJTQVNTQS1QU1Mgd2l0aCBUTFMgMS4wLCAxLjEsIG9y IDEuMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklzIHRoaXMg d2hhdCB3YXMgaW50ZW5kZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E521BA5F456344D2B186B11B7B214A15mobileironcom_-- From nobody Wed Feb 8 12: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 8D25812941C for ; Wed, 8 Feb 2017 12:20:54 -0800 (PST) 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 eiuvra4GcHWe for ; Wed, 8 Feb 2017 12:20:51 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 EE1391295BC for ; Wed, 8 Feb 2017 12:20:50 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id t18so53029258wmt.0 for ; Wed, 08 Feb 2017 12:20:50 -0800 (PST) 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=Fr38+tWwolSgNipq0Fum/b8cEYhHlxEMyaHwHjROmZU=; b=puq2poQjW3xbxl3uZV+wfDabvAFZdqGVmM2WKctw6XCjMtmYWsu49lig/cimDSHRB6 bpOukNG27mJE/OMP8sqL0bl7xcBFGp/pOoKEmww/1QU67wWsKn/bU93SU+1wf8wfJAzd Widsl1vespIrbytEao/ccENczxdtBbKO02SQkfNYpcPxOoumgqh6udtVWMuvA9EEATOn IP4CTnquZGPsK1MYEEkS3AZu5a9TBTJGUtrck9PruEl0kGFiSqZhjUHFfPsfWGqdUbxD 0bNI1/ty0l8mDKVdrdjMuSMPH8cXh9cr7EH/nkqI+CKo+Mitstdw8q8jdg1QI0Gg3M+R ZMfw== 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=Fr38+tWwolSgNipq0Fum/b8cEYhHlxEMyaHwHjROmZU=; b=uc7fNkwdoIE1poOElQCEyGn8qaBU9mqZgCYAKtsLznNeHP0fInCnlrbEWZiriXwZa3 aOlhrs6TKN72a1fMK9ng53rPHNO0aDJ9RmybQ1qj60Q9EEyq78Nig609GYRi3mvJ3Vkl 8rpikYacFqapPO32rh9Ii1DXhzyTkGAwxJiYWoJXbh8jyWd6E6TBMfE4KUcDW0J8mqbw HbGILs3/44vlvxzaewoswSYZn1Cdpxkp3HseKeDVvfxLW7kdbr+NNjGuJYJ9xc5peJn/ CUtH467bfjFhTzPX5vPX5I4/UJJI3N5N8SNF9Jd1FMRRl8zh1/oRKIaVIPYvcr0bSeDR IBmA== X-Gm-Message-State: AMke39k04ZZZDNFTmzYvgX6wNw6+DjIU+bySCHX4GzGSB6Lp8GVn6+Ya0X08AVrIE7J74g== X-Received: by 10.28.234.66 with SMTP id i63mr19926698wmh.43.1486585249482; Wed, 08 Feb 2017 12:20:49 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id o81sm5108347wmb.14.2017.02.08.12.20.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 12:20:48 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EEA2E3F4-EB7C-4A6A-90A7-D935B9FB55C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 22:20:46 +0200 In-Reply-To: To: Timothy Jackson References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 20:20:54 -0000 --Apple-Mail=_EEA2E3F4-EB7C-4A6A-90A7-D935B9FB55C9 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BCB81D1-0F27-43A7-8C56-6F76B0185CEB" --Apple-Mail=_8BCB81D1-0F27-43A7-8C56-6F76B0185CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Feb 2017, at 21:34, Timothy Jackson = wrote: >=20 > I have a question on RFC5246 (TLS 1.2) and how it=E2=80=99s going to = interact with RSASSA-PSS as we roll out TLS 1.3. Does the prohibition = against RSASSA-PSS apply only to the signatures that can be used for = signing handshakes or does it apply to the entire certificate chain as = well? I ask because while I think the latter may have been the intent I = have not found anything that indicates the former is not actually what = the RFCs require. >=20 > The relevant section of RFC4056 reads: >=20 > 7.4.2 Server Certificate > =E2=80=A6 > Note that there are certificates that use algorithms and/or algorithm > combinations that cannot be currently used with TLS. For example, = a > certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in > SubjectPublicKeyInfo) cannot be used because TLS defines no > corresponding signature algorithm. >=20 > I don=E2=80=99t see anything here that restricts which signatures can = be used on the certificates themselves. Is that accurate? No. A few paragraphs up: If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. And it doesn=E2=80=99t help if the client does not provide the = extension. The extension can restrict from among the set of supported = algorithms, Its absence does not allow undefined algorithms. Yoav --Apple-Mail=_8BCB81D1-0F27-43A7-8C56-6F76B0185CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Feb 2017, at 21:34, Timothy Jackson <tjackson@mobileiron.com> wrote:

I have a question on RFC5246 (TLS = 1.2) and how it=E2=80=99s going to interact with RSASSA-PSS as we roll = out TLS 1.3. Does the prohibition against RSASSA-PSS apply only to the = signatures that can be used for signing handshakes or does it apply to = the entire certificate chain as well? I ask because while I think the = latter may have been the intent I have not found anything that indicates = the former is not actually what the RFCs require.
 
The relevant section of RFC4056 = reads:
 
7.4.2 Server Certificate
=E2=80=A6
Note that there are certificates = that use algorithms and/or algorithm
   combinations that = cannot be currently used with TLS.  For example, a
   certificate with = RSASSA-PSS signature key (id-RSASSA-PSS OID in
   SubjectPublicKeyInfo) = cannot be used because TLS defines no
   corresponding = signature algorithm.
 
I don=E2=80=99t see anything here = that restricts which signatures can be used on the certificates = themselves. Is that = accurate?

No.  A few paragraphs up:

   If the client provided a =
"signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that =
extension.

And = it doesn=E2=80=99t help if the client does not provide the extension. =  The extension can restrict from among the set of supported = algorithms, Its absence does not allow undefined algorithms.

Yoav

= --Apple-Mail=_8BCB81D1-0F27-43A7-8C56-6F76B0185CEB-- --Apple-Mail=_EEA2E3F4-EB7C-4A6A-90A7-D935B9FB55C9 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----- iQEcBAEBCgAGBQJYm32fAAoJELhJCxUKWMyZAK0H/i/fhCT+rB0m/APR98QorQG0 zt4GxPcr3UI0YpUpTJYJAsDxQvFdA3PSxXsPeOc4eWa8jj2ErOcd8c89IrRYemCA TeoYiQf/OGXrr6tGh2l59UptgnbU3wIWnl0oqXuJsoyYH4ntmMzoSIi2b+d3mHhX EeaUDgeRku013gFI0ToaNMRvezK4IZwVXZByow8+JihFTOnx8oTyFH+P6ldP4wI4 NnfVwkupQzGQQ9ohVWbijxgNIMPg4hdMNv56ilOg/7BINOLf/jfSLRIJ6wy7kUyB ensdKFKDnn5TclZvwWxqfPYypBNlyli83ci6N5pPvPAsI++lKPvimJEeKfCaRx8= =kZ32 -----END PGP SIGNATURE----- --Apple-Mail=_EEA2E3F4-EB7C-4A6A-90A7-D935B9FB55C9-- From nobody Wed Feb 8 13:05: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 20E531294C7 for ; Wed, 8 Feb 2017 13:05:45 -0800 (PST) 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 P1y-sud3EU7E for ; Wed, 8 Feb 2017 13:05:44 -0800 (PST) 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 255C71295D8 for ; Wed, 8 Feb 2017 13:05:44 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id v23so178274917qtb.0 for ; Wed, 08 Feb 2017 13:05:44 -0800 (PST) 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=RwvrkqKS9/kOdz+JssUzyBdbiXpF0mP91HEl8SkALzo=; b=EVnTZ4nZVSur8bUHGU4sUWbIe8eSzivYTO1ww3IQWTjGMO4wuXxeY7pG4EMgllBj1m 66uUyTVN1yuUS0lKMNpEuJvlIZZVTVLZUIDcehz4T61BUvx2UZuvR2rQZo/6YaW1tGL8 7h2rH+m1q74qbpMk2JTZAzLj7uhipQOFll1fM4jG60HycnNeP5mu+QULF8x4eAcL5wE6 Uu9YOaloPTPg3odH6fw3eXfiChw6nDGCEFYttcuYLXki4InH5nj3CTv7ap4eZsKZjdXR X4+GXmyqRG2ENyJRSwW145MNFTj6fhbWF+II4bsLan6/oApRwRZTkxsCCDk7Cw4pwkCr VQYg== 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=RwvrkqKS9/kOdz+JssUzyBdbiXpF0mP91HEl8SkALzo=; b=hMi57GUXN+2Uxpylh//wGCjlKYxHx6UEzWh+7eXvEkc4LJaM7veaBH28pfdlu6u9em ajBmQ5TuBBb7gIzWNiZRCsI3pvUCpYtTm7SfmTYMlgD6BeP7KM1GZb7rDV3zWCJiHSt5 b/qkQ3jZUttYirS+NmFLoYvJASmvN2oDiDB4O6ftKFsH32VV6VGLMtGp5iLuMF2KcuVw oODhClxOAD3V97EylG2+CxEp76PernQ0jdOPEJaX2Q0VVtoNpgHcBTnC/KDjq/Kh5QHh eck/uLkzbgbhwCDs5UG32ACC3rkj3uQi7yL/Av4PGELI4QlCBe58teuBEIEyL+gUzt1q xgXw== X-Gm-Message-State: AMke39kiUsMl3W4ao+SE5UMWX5CY/ROPl3SxHLudHfqx2BYSkeR7tp38pF/o+9JyOy9udOoKixn35QC/qzZdag== X-Received: by 10.200.55.112 with SMTP id p45mr24066827qtb.278.1486587943174; Wed, 08 Feb 2017 13:05:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Feb 2017 13:05:42 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Feb 2017 08:05:42 +1100 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:05:45 -0000 On 9 February 2017 at 07:20, Yoav Nir wrote: > And it doesn=E2=80=99t help if the client does not provide the extension.= The > extension can restrict from among the set of supported algorithms, Its > absence does not allow undefined algorithms. Since TLS 1.3 defines code points for RSA-PSS, perhaps this is no longer accurate - at least for PSS. NSS supports PSS signatures in TLS 1.2. It caused a small amount of compatibility pain deploying them thanks to some infrequently used, but overzealous implementations. From nobody Wed Feb 8 13:24: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 5AE85129478 for ; Wed, 8 Feb 2017 13:24:56 -0800 (PST) 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 eaq-QKQPeTIA for ; Wed, 8 Feb 2017 13:24:53 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0400212954D for ; Wed, 8 Feb 2017 13:24:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id DDDF81F22F; Wed, 8 Feb 2017 23:24:47 +0200 (EET) 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 6ZzZ9Gvl9GoD; Wed, 8 Feb 2017 23:24:47 +0200 (EET) 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 BD58721C; Wed, 8 Feb 2017 23:17:39 +0200 (EET) Date: Wed, 8 Feb 2017 23:17:38 +0200 From: Ilari Liusvaara To: Timothy Jackson Message-ID: <20170208211738.GB17727@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: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:24:56 -0000 On Wed, Feb 08, 2017 at 07:34:16PM +0000, Timothy Jackson wrote: > I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with > RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS > apply only to the signatures that can be used for signing handshakes or > does it apply to the entire certificate chain as well? I ask because while > I think the latter may have been the intent I have not found anything that > indicates the former is not actually what the RFCs require. > > The relevant section of RFC4056 reads: > > 7.4.2 Server Certificate > … > Note that there are certificates that use algorithms and/or algorithm > combinations that cannot be currently used with TLS. For example, a > certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in > SubjectPublicKeyInfo) cannot be used because TLS defines no > corresponding signature algorithm. > > I don’t see anything here that restricts which signatures can be used on > the certificates themselves. Is that accurate? If so, then I think the > relevant restrictions are not in TLS RFCs at all, but rather are in RFCs > such as 4055, 4056, and 5756. These RFCs allow RSASSA-PSS. Is it > therefore permissible to have a CA that is signed with RSASSA-PSS with > TLS 1.0, 1.1, or 1.2. > > Is this what was intended? My interpretation: If client includes RSA-PSS codepoints in its signature_algorithms, then: - The server handshake signature MAY be signed using RSA-PSS in TLS 1.2 or later. Yes, 1.2, not 1.3. - The certificate chain MAY contain certificates signed with RSA-PSS in any TLS version (however, the salt length must match hash length). In converse case: - The server MUST NOT sign handshake using RSA-PSS in any TLS version - The certificate chain SHOULD NOT contain certificates signed with RSA-PSS in any TLS version. -Ilari From nobody Wed Feb 8 15:49: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 BB29912957D for ; Wed, 8 Feb 2017 15:49:19 -0800 (PST) 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 caH1QkyHWF2r for ; Wed, 8 Feb 2017 15:49:18 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 8C732129543 for ; Wed, 8 Feb 2017 15:49:18 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id s140so140485281qke.0 for ; Wed, 08 Feb 2017 15:49:18 -0800 (PST) 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=d11jNFlUFYafIoeeO3v5MaFNfg933+o489JKWs1kuc4=; b=to4wb3/8ViHxivOSR/CCMx/dWBIDp/+1reITpsIJ1sY9WOG3tm0ot1VRvRsR40BudC 7UyH4g7jztinPLOhF4saPCAPLjK7ufqE6xyuyuopUCR95mqNN97Yx6p5g4g5YM3u243n +gouA2ytQ7ZNvdXEvXzNBZkP5vVk/ZkdxesmFKVD3Nbij3bvJmdRQhYHFR5ovWw+YcDz /n1qoyirJO8DQMu5N4TffRVBWdOSDSMYunjTIzc3yKyF/q8Ovv+kOkOWEKOqmE6TiODQ 29c7I3ibaFWvcSZVQOCor5HouKJeiN8XFAh2Wn3j8C/VZMqrcpPVLp8rAybZV7M541LS YseA== 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=d11jNFlUFYafIoeeO3v5MaFNfg933+o489JKWs1kuc4=; b=JqX0PlecQ6mBpwxy6UCIFNFqx1Yaj8DdT79dkSlPYx1ZWhnZg+EW4QFo0gbYtO+W5l OuvhN6i2IpQ340xFr77nF5dFuDuEocKUThkKGH8JfdhV4jGXCG+Yhmc7jgh4Cbfykn5Z eDywMljqoW+AucNqXL6EhcG0Oz313AbtQ+abfs2Ix/azkib5ZsWPV3dT0UVdQjZiJyiV LqJhB8NlV7bfkR/uGrSUCQpxUzWzeNzYkyXAPuqAmpWzZPZ1Vwgu/X30bjLYMoOZpJ/S QxW5KEkFT67MkkuR/dJn3dLIwhEXofXPKOWHg4ri+oXlC6TIRAGyK9dgfSEDDJwZoDii mL/Q== X-Gm-Message-State: AMke39mPyWQZxeNCFcW08//4tL+G2IdPUYKBSZxOU2Su9Brko2c+2hNHMSLONChxVVtaYIzvKPhtxcLDG8XGgQ== X-Received: by 10.55.21.84 with SMTP id f81mr173360qkh.5.1486597757729; Wed, 08 Feb 2017 15:49:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Feb 2017 15:49:17 -0800 (PST) In-Reply-To: <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Thu, 9 Feb 2017 10:49:17 +1100 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:49:19 -0000 On 9 February 2017 at 08:17, Ilari Liusvaara wrote: > If client includes RSA-PSS codepoints in its signature_algorithms, > then: > > - The server handshake signature MAY be signed using RSA-PSS in TLS > 1.2 or later. Yes, 1.2, not 1.3. > - The certificate chain MAY contain certificates signed with RSA-PSS > in any TLS version (however, the salt length must match hash length). This is consistent with TLS 1.3 (and the discussion we had on the same subject previously). RSASSA-PSS algorithms: Indicates a signature algorithm using RSASSA-PSS [RFC3447] with mask generation function 1. The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in [SHS]. When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest output. This codepoint is also defined for use with TLS 1.2. From mark.dunn@objectiveintegration.uk Thu Feb 9 04:39: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 86CA31299D6 for ; Thu, 9 Feb 2017 04:39:16 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 fJ5FMKGH5V10 for ; Thu, 9 Feb 2017 04:39:15 -0800 (PST) Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E905B1299C8 for ; Thu, 9 Feb 2017 04:39:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 946DD1A02E40 for ; Thu, 9 Feb 2017 12:39:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhymPVnZS-eP for ; Thu, 9 Feb 2017 12:38:50 +0000 (UTC) Received: from gamma (host86-157-188-235.range86-157.btcentralplus.com [86.157.188.235]) by mail.objectiveintegration.uk (Postfix) with ESMTPA id D4F171A01A96 for ; Thu, 9 Feb 2017 12:38:50 +0000 (UTC) From: "Mark Dunn" To: Date: Thu, 9 Feb 2017 12:38:50 -0000 Message-ID: <000001d282d1$7769bdc0$663d3940$@objectiveintegration.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D282D1.776E78B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKCz+xcEVNI4lxORaa5rhflb37RVQ== Content-Language: en-gb Archived-At: X-Mailman-Approved-At: Thu, 09 Feb 2017 04:59:44 -0800 Subject: [TLS] ticket_lifetime and generic network layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 12:49:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D282D1.776E78B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am reading your TLS 3.1 Standard and the mailing list. It looks great. I am particularly interested in using the 0-RTT feature for IoT timestamped data, which would seem immune from replay attacks I have a couple of questions 1) The maximum ticket lifetime is set to 7 days. Is this based on hard science or arbitrary? If it is arbitrary then 8 days for weekly intervals or 32 for days for monthly intervals would make better commercial sense (allowing for variability in wake-up times for constrained devices) 2) Have you considered using TLS for a generic network layer? I am thinking along the lines of a protocol like geneve (https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ ) Use cases would be Insert TLS 1.3 between the physical layer and the MAC (data link) layer For WAN and WWAN devices Insert TLS 1.3 between the MAC layer and IP layer or IP/TLS/VXLAN/IP Use any of your favourite virtualisation protocols here. For securing virtual networks Insert TLS 1.3 between IP layer and UDP/TCP layers For securing legacy network applications (SIP, RTP and RTCP for example) It looks, from my point of view, that a small addition could transform this protocol from an application oriented security mechanism, into a general internet workhorse. Providing a simpler solution for both the IoT and Cloud Other protocols call this Protocol (IPv4) Next Header (IPv6) Ethertype (Ethernet) And then you would also need to register this generic TLS 1.3 protocol with Iana to register your own protocol Id ------=_NextPart_000_0001_01D282D1.776E78B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = reading your TLS 3.1 Standard and the mailing list.

It looks great.

I = am particularly interested in using the 0-RTT feature for IoT = timestamped data, which would seem immune from replay = attacks

 

I have a couple of questions

 

1) The = maximum ticket lifetime is set to 7 days. Is this based on hard science = or arbitrary?

If it is arbitrary then 8 days for weekly = intervals or 32 for days for monthly intervals would  make better = commercial sense

         &= nbsp;     (allowing for variability in wake-up times = for constrained devices)

=

2) Have you considered using TLS for = a generic network layer?

         &= nbsp;     I am thinking along the lines of a = protocol like geneve (https:/= /datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ )

 

Use cases = would be

         &= nbsp;     Insert TLS 1.3 between the physical layer = and the MAC (data link) layer

         &= nbsp;     For WAN and WWAN devices

 

         &= nbsp;     Insert TLS 1.3 between the MAC layer and = IP layer or IP/TLS/VXLAN/IP

         &= nbsp;     Use any of your favourite virtualisation = protocols here.

         &= nbsp;     For securing virtual = networks

 

         &= nbsp;     Insert TLS 1.3 between IP layer and = UDP/TCP layers

For securing  legacy network = applications (SIP, RTP and RTCP for example)

 

It looks, from my point of view, that a small addition =  could transform this protocol from an application = oriented

security mechanism, into a = general internet workhorse. Providing a simpler solution for both the = IoT and Cloud

Other protocols call = this

         &= nbsp;     Protocol (IPv4)

         &= nbsp;     Next Header (IPv6)

         &= nbsp;     Ethertype (Ethernet)

And then you would also need to register this generic = TLS 1.3 protocol with Iana to register your own protocol = Id

 

------=_NextPart_000_0001_01D282D1.776E78B0-- From nobody Thu Feb 9 10:11:31 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 6EDE61294E1; Thu, 9 Feb 2017 10:11:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148666388940.532.2292322444031330792.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 10:11:29 -0800 Archived-At: Cc: tls@ietf.org, tls-chairs@ietf.org Subject: [TLS] tls - New Meeting Session Request for IETF 98 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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, 09 Feb 2017 18:11:29 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: curdle uta acme cfrg dane 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 Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Thu Feb 9 11:05: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 5FD14129C3F for ; Thu, 9 Feb 2017 11:05:46 -0800 (PST) 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 ROnJzvNkD3zF for ; Thu, 9 Feb 2017 11:05:34 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A12851296CD for ; Thu, 9 Feb 2017 11:05:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 015FE1F03F; Thu, 9 Feb 2017 21:05:33 +0200 (EET) 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 6mu55xebu8De; Thu, 9 Feb 2017 21:05:32 +0200 (EET) 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 BA5DFC4; Thu, 9 Feb 2017 21:05:32 +0200 (EET) Date: Thu, 9 Feb 2017 21:05:30 +0200 From: Ilari Liusvaara To: Mark Dunn Message-ID: <20170209190530.GA20340@LK-Perkele-V2.elisa-laajakaista.fi> References: <000001d282d1$7769bdc0$663d3940$@objectiveintegration.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <000001d282d1$7769bdc0$663d3940$@objectiveintegration.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] ticket_lifetime and generic network layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:05:46 -0000 On Thu, Feb 09, 2017 at 12:38:50PM -0000, Mark Dunn wrote: > I am reading your TLS 3.1 Standard and the mailing list. > > It looks great. > > I am particularly interested in using the 0-RTT feature for IoT timestamped > data, which would seem immune from replay attacks > > > > I have a couple of questions > > > > 1) The maximum ticket lifetime is set to 7 days. Is this based on hard > science or arbitrary? > > If it is arbitrary then 8 days for weekly intervals or 32 for days for > monthly intervals would make better commercial sense > > (allowing for variability in wake-up times for constrained > devices) AFAIK, it is arbitrary. However, long validity periods bring security issues, with having to store and protect symmetric keys for a long time. > 2) Have you considered using TLS for a generic network layer? Note that TLS requires in-order reliable delivery (DTLS doesn't, but DTLS 1.3 is currently just handwaving), and neither is available below transport layer. -Ilari From nobody Thu Feb 9 13:16: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 414341295CD for ; Thu, 9 Feb 2017 13:16:35 -0800 (PST) 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 MaWk8HWIybtt for ; Thu, 9 Feb 2017 13:16:34 -0800 (PST) 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 E98D2129484 for ; Thu, 9 Feb 2017 13:16:33 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l19so10068251ywc.2 for ; Thu, 09 Feb 2017 13:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6/yiItTWgg4Mu6W9g3KJtjrl+naH7alhl0ORGuY+qKg=; b=oKFSwb+83GIClwlKDzs2eksMzMCwXnW6AVbfYp10syCg2S1NbpkDoUKZzEiWR5VuKT 9lNWlIQWpnChuF378mlV9ACiwGpYZfZmR2EDlhCv7PP5A9mi2AWbgF9/CcyMefaea8o8 917BBvSX1MURXehbCQtyrD01+pFceDfVMzIETpgEfW/5m4n/Fo43mQDYXkTfZ48+sjtr XborBIII6ANFl7XEOoDwcPkYabvxJVVYiukkAGwvqOJRLb1HcHGbhcjVAaVQfhFScAu/ rr6nO48ei1Q20J3Tj6r86wGJFhe8buoAYaj+7sUbhRpRGR7nIFW93Sww4MonRyjXQaak JjZQ== 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=6/yiItTWgg4Mu6W9g3KJtjrl+naH7alhl0ORGuY+qKg=; b=jpSavjE0jnQwDmUJRavBe4y13G6ZSECzu8aOQHBUGUqU8D+8s5sVGOSfG6GC8gcO9p u7m0ynGqKcd4pO42Uh36VLoi4uqe4GTUR95Jl13bJ9+y33Lv+RNdzrbtLxXnfcdOryv4 tq617bx0yDWE7WbOh+B7ApCuXTowr6rBlwMWVwVQVxo4rwmQYFc45W1HyYTsu0BQF9+2 1Lvq9j7MaYGQUfyFbDUgnWIBQFj3JJ8bTlVIXK70DHK0HV8O01OtmlK5g+IAKYM4DmuG 6Y7rPpvV6Zcfvt4kS3RLwY16MRScwz/yrdaFOf7An/Os/JIOSRJK/kEo201ykatBRUX0 yNtA== X-Gm-Message-State: AMke39kBC9DoZ7UxxL/Lu/jro5Bsx+UW/grx4W4NJDO9SsXPTvq7jnbVLHivSXnE3pH2HUE9IcqiKIcSsqepxA== X-Received: by 10.129.162.130 with SMTP id z124mr4316682ywg.276.1486674992773; Thu, 09 Feb 2017 13:16:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 9 Feb 2017 13:15:52 -0800 (PST) From: Eric Rescorla Date: Thu, 9 Feb 2017 13:15:52 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c129292d7856905481f7e04 Archived-At: Subject: [TLS] PR#875: Additional Derive-Secret Stage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:16:35 -0000 --94eb2c129292d7856905481f7e04 Content-Type: text/plain; charset=UTF-8 I've just posted a pull request which slightly adjusts the structure of key derivation. PR#875 adds another Derive-Secret stage to the left side of the key ladder between each pair of HKDF-Extracts. There are two reasons for this: - Address a potential issue raised by Trevor Perrin where an attacker somehow forces the IKM value to match the label value for Derive-Secret, in which case the output of HKDF-Extract would match the derived secret. This doesn't seem like it should be possible for any of the DH variants we are using, and it's not clear that it would lead to any concrete attack, but in the interest of cleanliness, it seemed good to address. - Restore Extract/Expand parity which gives us some flexibility in case we want to replace HKDF. I don't expect this change to be controversial and I'll merge it on Monday unless I hear objections. Thanks, -Ekr --94eb2c129292d7856905481f7e04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've just posted a pull request which slightly ad= justs the structure of key derivation.
PR#875 adds another Derive= -Secret stage to the left side of the key ladder
between each= pair of HKDF-Extracts. There are two reasons for this:

- Address a potential issue raised by Trevor Perrin where an attacker=
=C2=A0 somehow forces the IKM value to match the label value for= Derive-Secret,
=C2=A0 in which case the output of HKDF-Extract w= ould match the derived secret.
=C2=A0 This doesn't seem like = it should be possible for any of the DH variants
=C2=A0 we are us= ing, and it's not clear that it would lead to any concrete
= =C2=A0 attack, but in the interest of cleanliness, it seemed good to addres= s.

- Restore Extract/Expand parity which gives us = some flexibility in
=C2=A0 case we want to replace HKDF.

I don't expect this change to be controversial and I&#= 39;ll merge it on Monday
unless I hear objections.

=
Thanks,
-Ekr


<= br>



--94eb2c129292d7856905481f7e04-- From nobody Thu Feb 9 13:18: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 09FD31294CF for ; Thu, 9 Feb 2017 13:18:16 -0800 (PST) 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 ko-e2li5csIs for ; Thu, 9 Feb 2017 13:18:14 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 5B276129484 for ; Thu, 9 Feb 2017 13:18:14 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v200so10078795ywc.3 for ; Thu, 09 Feb 2017 13:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sdxyC8H8P4Omvh+NegEvncPQ9l8ko2CACRPz5VBqfVg=; b=dgneLn8kGDHA9iGaapIFlCUfWGP+qzRpDFgW2b+H2EkpDeQ1G5OX3/n4VM8XyPoHaE EmN2buCJaafdIuu21qsac2+umtoipL058LM3wYW7vV9iY6Sk43lPqmL0t0GgZrkK8yjN QlbQmwihKNpw9gpekDo+KoiZIQ4q/A1yFtckEfXkEuoe0s84ELuLjFOXzIe9YFKMxUTH iSQlCEZ8ZTADH+v+fhNMZ106fJ8R/gB4mfF54Wo8KeAMrX6FsWbylP7AXEAWOGQlveAN /fx24ukt4KKBDs+weuLqU9jcComNPOXv/WEhfu2JiCNb26yU99avuyxKPf245VXtVrF+ KwMQ== 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=sdxyC8H8P4Omvh+NegEvncPQ9l8ko2CACRPz5VBqfVg=; b=Khv8QPgjqRDe16nR8jiwdPqqxvjgRsK/VbjfugwLkNx0fPaZEzOqsrbFFgIy/HtW83 zDNAgD0BzvBrzBtmORYx+5llhrHtTSqBKwJpjdzHMM8bry/9DPNDqyztpWqf2aDGM3H6 grNojmoVJDUZll0cE9tsFXxofPSD8hBn1SVF5/StSkIpOqRyng3LDLYusGLRw41OgiYh z4OBY8fRi9D6uxoXDzy8Ad0B13Lz6WpyTPlj5KHx8nTcM61//aETBpW9WX1SUfA8yR9N u6VT/+A9nMfuWOIY2p19375sy7+a2BOUjqCLFIAmeDvCVzT8U3cio8DmuY6g2ZnH2CKG Hg+w== X-Gm-Message-State: AMke39kDuo86z2OLhlk1yvblBvmtqDFyTSpVJT5sIXX3t1EQCFXJ6ht0kMZzW+VnSoeCZkT8XXPurcvFyxeOKA== X-Received: by 10.129.132.77 with SMTP id u74mr3960752ywf.125.1486675093496; Thu, 09 Feb 2017 13:18:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 9 Feb 2017 13:17:33 -0800 (PST) From: Eric Rescorla Date: Thu, 9 Feb 2017 13:17:33 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114f0996d876c605481f840d Archived-At: Subject: [TLS] (no subject) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:18:16 -0000 --001a114f0996d876c605481f840d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks, We need to close on an issue about the size of the state in the HelloRetryRequest. Because we continue the transcript after HRR, if you want a stateless HRR the server needs to incorporate the hash state into the cookie. However, this has two issues: 1. The "API" for conventional hashes isn't designed to be checkpointed at arbitrary points (though PKCS#11 at least does have support for this.) 2. The state is bigger than you would like b/c you need to store both the compression function and the "remainder" of bytes that don't fit in [0] Opinions differ about how severe all this is, but it's certainly unaesthetic, and it would be nice if the state that was stored in the HRR cookie was just a hash output. There seem to be three major approaches for this (aside from "do nothing"). 1. Special case HRR and say that the transcript is either CH || SH .... (no HRR) or Hash(CH1) || HRR || CH ... (HRR) [1] 2. Pre-hash the messages, so that the handshake hash becomes: Handshake_hash_N =3D Hash(Hash(msg_1) || Hash(msg_2) ... Hash(msg_N)) 3. Recursively hash, so that the handshake hash becomes: Handshake_hash_N=3D Hash(Handshake_hash_N-1 || msg_N) [As Antoine Delignat-Lavaud points out, this is basically making a new Merkle-Damgard hash with H as the compression function.] I've posted PR#876, which implements version #2, but we could do any one of the three. and they all have the same state size. The argument for #1 seems to be that it's the minimal change, and also the minimal overhead, and the argument against is that it's non-uniform because CH1 is treated differently. We might imagine making it seem more uniform by also hashing HRR but that doesn't make the code any simpler. Versions #2 and #3 both are more uniform but also more complicated changes. The arguments for #2 versus #3 are that #3 is somewhat faster (consider the case where you have a short message to add, #2 always needs to run the compression function twice whereas #3 can run it once). However, with #3 it is possible to take a hash for an unknown transcript and create a new hash that matches that unknown transcript plus an arbitrary suffix. This is already a property of the M-D hashes we are using but it's worse here because those hashes add padding and length at the end before finalizing, so an extension wouldn't generally reflect a valid handshake transcript, whereas in this case you get to append a valid message, because the padding is added with every finalization stage. I don't know of any reason why this would be a security issue, but I don't have any proof it's not, either. I'd like to get the WG's thoughts on how to resolve this issue over the nex= t week or so so we can close this out. -Ekr [0] The worst-case overhead for SHA-256 is > 64 bytes and for SHA-512 it=E2=80=99s > 128 bytes. The average is half that. [1] We actually need to do something to make it injective, because H(CH1) might look like a handshake message, but that should be easy. --001a114f0996d876c605481f840d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

We need to close o= n an issue about the size of the
state in the HelloRetryRequest. = Because we continue the transcript
after HRR, if you want a state= less HRR the server needs to incorporate
the hash state into the = cookie. However, this has two issues:

1. The "= ;API" for conventional hashes isn't designed to be checkpointed
=C2=A0 =C2=A0at arbitrary points (though PKCS#11 at least does have= support
=C2=A0 =C2=A0for this.)
2. The state is bigger= than you would like b/c you need to store both
=C2=A0 =C2=A0the = compression function and the "remainder" of bytes that don't<= /div>
=C2=A0 =C2=A0fit in [0]

Opinions differ = about how severe all this is, but it's certainly
unaesthetic,= and it would be nice if the state that was stored in
the HRR coo= kie was just a hash output. There seem to be three
major approach= es for this (aside from "do nothing").

1= . Special case HRR and say that the transcript is either

=C2=A0 =C2=A0CH || SH .... =C2=A0 (no HRR)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0or
=C2=A0 =C2=A0 =C2=A0
= =C2=A0 =C2=A0Hash(CH1) || HRR || CH ... (HRR) =C2=A0[1]


2. Pre-hash the messages, so that the handshake hash
=C2=A0 =C2=A0becomes:

=C2=A0 =C2=A0Handsh= ake_hash_N =3D Hash(Hash(msg_1) || Hash(msg_2)
=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... Hash(msg_N))

3. Recursively hash, so tha= t the handshake hash becomes:

=C2=A0 =C2=A0Handsha= ke_hash_N=3D Hash(Handshake_hash_N-1 || msg_N)

[As= Antoine Delignat-Lavaud points out, this is basically making
a n= ew Merkle-Damgard hash with H as the compression function.]

<= /div>

I've posted PR#876, which implements version #= 2, but we could do any one of the three.
and they all have the sa= me state size. The argument for #1 seems to be
that it's the = minimal change, and also the minimal overhead, and the
argument a= gainst is that it's non-uniform because CH1 is treated
differ= ently.=C2=A0 We might imagine making it seem more uniform by also
hashing HRR but that doesn't make the code any simpler. Versions #2
and #3 both are more uniform but also more complicated changes.

The arguments for #2 versus #3 are that #3 is somewha= t faster
(consider the case where you have a short message to add= , #2 always
needs to run the compression function twice whereas #= 3 can run it
once). However, with #3 it is possible to take a has= h for an unknown
transcript and create a new hash that matches th= at unknown transcript
plus an arbitrary suffix.=C2=A0 This is alr= eady a property of the M-D
hashes we are using but it's worse= here because those hashes add
padding and length at the end befo= re finalizing, so an extension
wouldn't generally reflect a v= alid handshake transcript, whereas in
this case you get to append= a valid message, because the padding is
added with every finaliz= ation stage. I don't know of any reason
why this would be a s= ecurity issue, but I don't have any proof it's
not, eithe= r.

I'd like to get the WG's thoughts on ho= w to resolve this issue over the next
week or so so we can close = this out.

-Ekr

[0] T= he worst-case overhead for SHA-256 is > 64 bytes and for SHA-512
it=E2=80=99s > 128 bytes. The average is half that.

[1] We actually need to do something to make it injective, because<= /div>
H(CH1) might look like a handshake message, but that should be ea= sy.


--001a114f0996d876c605481f840d-- From nobody Thu Feb 9 15:46: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 C404412945D for ; Thu, 9 Feb 2017 15:46:15 -0800 (PST) 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 SnnWPa8D5inc for ; Thu, 9 Feb 2017 15:46:14 -0800 (PST) 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 71D421288B8 for ; Thu, 9 Feb 2017 15:46:14 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so19980289qtb.0 for ; Thu, 09 Feb 2017 15:46:14 -0800 (PST) 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=WcRxZ79JWhp0ardTM1Lm3sRM3b0+/NbnxumggUq9w2I=; b=ABp/vtdzrlonyoAnAAqVWM9HTu5lEmlY6J7xYApx1jNawiHCSs07aYFiJNnrUnpL8v LwDsVV9xr03753H/9gU26XKsPgIT3mRIdH9c8amoxYQIzsZsSGWGwyJrN8S4XeVJFqVO tIxQTngCcz3wZKuRVnfIlU0NUsp+ZFjcuSBapdf+Jgd3ErrKPyG/8zXiYDkWCRVzTCIZ c3tOXJV9CfHbk4xUoBzvvS15UAzukS+v2V9/0v/3LQxU+KvRBRzsPLZ1DD5Hy1BQf1M/ n8xC0Hlub+eEnVcXR6yn8/YwS+UH4Puf9qH3LuYYOfJVfhiUrnyGY5MBfdTUjFqdbu8G KT0A== 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=WcRxZ79JWhp0ardTM1Lm3sRM3b0+/NbnxumggUq9w2I=; b=EXUE8fQ1U5B7XbqdRs4VsjLUUdZ2wVMBAucsJf1ldqrLnehuyZRvpY/0wzwBjNIA9r UjWrD92/lUm+sSKKcpihvqfipsGcDRoZ0YRRUqoxJBlttLUdxTYU+qpmXTE2iVOplFbK 5iE7it6gVUFA5Qp5Cs42IOBs8aNI0UJxSQIfMPHmt/d3KyY2xtX+y1Mie7Lg4iA3HFJT /oCuC0lWjFn5znoaUhpZyia3ipEUmZ4dHxXRMJCIRnicN+gXnt6Sb5tOm2zJLG5SyLII lmzBhfDNYEOCUOfe840jwbs63ctlq1mdYtTShoB9+xplzYpjdNffJsg/vpys1rWwF/Xr a6sg== X-Gm-Message-State: AMke39keFiidHOWGhMUHMInK0yBuhDFdOEMxCclXqrxRbMOe8hJVeDYsNHTDUc0UuSzfEIqz+iOK+wclS1YCAQ== X-Received: by 10.200.53.247 with SMTP id l52mr5567231qtb.144.1486683973625; Thu, 09 Feb 2017 15:46:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Feb 2017 15:46:13 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 10 Feb 2017 10:46:13 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#875: Additional Derive-Secret Stage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:46:16 -0000 This is a good idea. On 10 February 2017 at 08:15, Eric Rescorla wrote: > - Address a potential issue raised by Trevor Perrin where an attacker > somehow forces the IKM value to match the label value for Derive-Secret, > in which case the output of HKDF-Extract would match the derived secret. > This doesn't seem like it should be possible for any of the DH variants > we are using, and it's not clear that it would lead to any concrete > attack, but in the interest of cleanliness, it seemed good to address. Just to highlight this point: if we need to add a PQ key exchange, there is no guarantee that it will have exactly the same properties as the key exchange methods we have today. I expect that need to arise relatively soon, so that's an extra good reason to make this change. From nobody Thu Feb 9 21:07: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 E18D6129EEA for ; Thu, 9 Feb 2017 21:07:40 -0800 (PST) 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=unavailable 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 rsbt3iIdm1Vm for ; Thu, 9 Feb 2017 21:07:40 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 09BF9129EF0 for ; Thu, 9 Feb 2017 21:07:39 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id v23so25073261qtb.0 for ; Thu, 09 Feb 2017 21:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=sF3S+goNt9Bc/mv7lBJdR9RN0+hom/uJoQlvQeZaObU=; b=Yu944ksgP4BNAUzg5nZz4QG0MKpvHkSfZzhaIPdr5piLeK6sVTEHFPBTUDTBB4CVP8 B4qHoXskiWVR7t7qyZ1gchheCRdOVkPakteuWO1ekDoiJoZG2gyi5IqAZU7/Wb6gDfah bEODu0HySXN0xubhCKTjw5egw6uJcjcq+q+C8= 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:subject:date :message-id:cc:to:mime-version; bh=sF3S+goNt9Bc/mv7lBJdR9RN0+hom/uJoQlvQeZaObU=; b=GEekLiMC/h9MraZFkhJaMy9kxr1yRunmIJnWU4AG6F3d4UT/98eHy0n/nBNRkpLImC 2waUJgR3ZEBZeYDa75aHG9faDZjXQZy2GEUaSpmr+OuCW5ewjxspdWHlpurDKxVcZjMw hUjAmHcXBgD0ZZ8nESulNOHYwZo3192q7vD+IVhmEP6aI5QqA71XQPrSoSJPaOdlvFrE bLrTJTpkKMHvrPfke5peEm6SV4YUGfJlaC3Jcmw08tbqSi83IqvS7TGQtQeA3UJqWIsu F4bEChRk5W71E4s4HFUQI7hzQjpdWK2g0zYWRad74ShzIPwaPEjQoa2BSkgBEiPD+qsz 7yPA== X-Gm-Message-State: AMke39klwg5iKzPeHWDgho/QqEOVKs3WgxLQ7Ou5li9y1o6Xkh+JT2LkfPKhjfexf3sgZw== X-Received: by 10.200.47.46 with SMTP id j43mr6313569qta.178.1486703257918; Thu, 09 Feb 2017 21:07:37 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id m143sm550421qke.18.2017.02.09.21.07.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Feb 2017 21:07:36 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2017 00:07:35 -0500 Message-Id: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IRTF CFRG Subject: [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 05:07:41 -0000 All, We=E2=80=99ve got two outstanding PRs that propose changes to = draft-ietf-tls-tls13 Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D. = As it relates to rekeying, these limits have been discussed a couple of = times and we need to resolve once and for all whether the TLS WG wants = to: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] Please indicate you preference to the TLS mailing list before Feb 17. = Note that unless there=E2=80=99s clear consensus to change the text will = remain as is (i.e., option a). J&S [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 [1] https://github.com/tlswg/tls13-spec/pull/765 [2] https://github.com/tlswg/tls13-spec/pull/769= From nobody Thu Feb 9 21:19: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 03888129FAA for ; Thu, 9 Feb 2017 21:19:08 -0800 (PST) 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 fH1M-scvEc6o for ; Thu, 9 Feb 2017 21:19:06 -0800 (PST) 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 82568129FA5 for ; Thu, 9 Feb 2017 21:19:06 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id k15so25186395qtg.3 for ; Thu, 09 Feb 2017 21:19:06 -0800 (PST) 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=31zLHJdGvGGCK8k+YPPH34KWJ/Sz+jwocUlewf0+kBw=; b=TZa67SiCkYBBoV0c4tc4RRWy30M6Z0leN6kNFwWfPqzdQ6xbdtckbe5l9nY5vmbFn9 m112+h/QDgK6Ww/MRhrvgkeejE6kDTcLimpA0KHuWQQZhJGz769Vp5DVZn5NTAyEHkO3 f0LAiKuheF2HFbJAVDx+qMfNarm8kvi09O1bPyMArfanDnR8R2vYgIsiNEacOI5gfivz yWtkHKKjfYHqM4ZOT07I+K46Ou+JpaOtDbUoTRYJvgaRIT9k81HilHrxU0hTCbobXY8U HKdHY4SoD7m2+IYSg+2Ue+EkzcTLctw/sfwxKhKq3zLULyOWAyS0Lek0l/nwmEilPcok AopQ== 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=31zLHJdGvGGCK8k+YPPH34KWJ/Sz+jwocUlewf0+kBw=; b=RKp0wdtVTup7W/Xyip2LJVK19lc7z2ZlyeWOqON4PfU37VW2vx7OYoUC1678on8YXQ C09rNjHkFEvMGwQlJtcslayi/mtB1+Ah0yNblsn50TynEoiwALCuSVU3ENbYj2yclug8 OduwNo516ks9kOHT13rxVQDDVGWHlR51yccH4yzzZ3XML/3zaVBXuBoV7cjk0+Yc3E4k 82hYetxK547ksVGXQFVBjuSn/wLlOLgJh4qf265VGcDWGXZiIvTmnsefjwiL7+q+0gjY St+UPpC+JYI7dnPbi5F0atbTnTYKyqBhDNzZRcxm4BYkUQ1twtMQrm3fHvZhbOO9SnPy RsRw== X-Gm-Message-State: AMke39lqvF4x3TDSDK0cu9FgljsRBX4972Xp56k4pCxW9K0jndsq52bULG9H+o/GtUdAguJMhcr392NslVYMXg== X-Received: by 10.200.37.183 with SMTP id e52mr6848789qte.166.1486703945651; Thu, 09 Feb 2017 21:19:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 9 Feb 2017 21:19:05 -0800 (PST) In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> From: "Stanislav V. Smyshlyaev" Date: Fri, 10 Feb 2017 08:19:05 +0300 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a1141fcbc91383d0548263c60 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 05:19:08 -0000 --001a1141fcbc91383d0548263c60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Sean, dear all, I find the existing limits quite reasonable and would prefer that we'll stay conservative here, so I'd prefer option a) go with the existing text. Best regards, Stanislav Smyshlyaev 2017-02-10 8:07 GMT+03:00 Sean Turner : > All, > > We=E2=80=99ve got two outstanding PRs that propose changes to draft-ietf-= tls-tls13 > Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D. As it relates to reke= ying, these limits > have been discussed a couple of times and we need to resolve once and for > all whether the TLS WG wants to: > > a) Close these two PRs and go with the existing text [0] > b) Adopt PR#765 [1] > c) Adopt PR#769 [2] > > Please indicate you preference to the TLS mailing list before Feb 17. > Note that unless there=E2=80=99s clear consensus to change the text will = remain as > is (i.e., option a). > > J&S > > [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 > [1] https://github.com/tlswg/tls13-spec/pull/765 > [2] https://github.com/tlswg/tls13-spec/pull/769 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a1141fcbc91383d0548263c60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Sean, dear all,

=
I find the existing limits quite reasonable and would prefer that we&#= 39;ll stay conservative here, so I'd prefer option a) go with the exist= ing text.


Best regards,
Stanislav Smyshlyaev
=


2017-02-10 8:07 GMT+03:00 Sean Turner <sean@sn= 3rd.com>:
https://tlswg.github.io/tls13-spec/#rfc.= section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a1141fcbc91383d0548263c60-- From nobody Thu Feb 9 21:45: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 01C33129FD2 for ; Thu, 9 Feb 2017 21:45:01 -0800 (PST) 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=unavailable 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 lt3bV66qbDRd for ; Thu, 9 Feb 2017 21:45:00 -0800 (PST) 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 BB30C129FD3 for ; Thu, 9 Feb 2017 21:44:59 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id 11so28603712qkl.3 for ; Thu, 09 Feb 2017 21:44:59 -0800 (PST) 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=pEtd0fEv8U6PQOY3b8h8LYIS+jtgiM/ZK3qdRssSQA8=; b=DW9veGmHWC8l6IejdO54hCUeH9G38cZW7v1+zMQm7avCsPea5+6KGcH9ghraHy+Kky eFVKQL0hc4MwOyJ95D77ofu6N773JDLpzdM4ZHM1mDZk4MT2on48nwTpM2hd/qv/Gbyc ksRvFhVeP6/h5CXZsLETM/Im5W8SRMpPEXKFGpdqUV5LRDkIlj+64tFOHKXfdBRxMAdl zsfs9FgCYcR6uEQ2HXqhrZQR6ptGf5HmBOXewG1IESNLMVJl6IrQIqwiXSAI29TVQF6m FuUVVaixpqhpfkwQ888tPnZIo9RR/vbHCv+TP52q/GoPj6uwEi0MQkVtwck1dE5XEfJD pwkw== 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=pEtd0fEv8U6PQOY3b8h8LYIS+jtgiM/ZK3qdRssSQA8=; b=qF57eKHzOxOAE/IHzBXv96wDhA6kr7J83wuAQRlMtRSkDPcT4vKm7omrEMstZ3MmJu KB67RL0Ca8JEPeiSmtWHWFigsHls4NExhdKjgN9Vk0Q5QoH9+KuMEYRR8f3xmjW2kl4K jgy4/+XdzGoJ0KlIa+nezsBInzI4PirAr3+ziaUNVkTad/XZj7hNtBaZ8lj0kmRl1cSU DTLSDb4Y61JfVwAuT/QZ/yAEPmWuAy4mw1ZW9vLsUNL7XlpPFhZEEHw87wpIKNmOZyo7 KuGV/0F+bcqVGKu2Yi+/viRpMvjTiUXU+S83LY8t/8OWuErvjROsXCq9559rk04HFjk2 gM/g== X-Gm-Message-State: AMke39kOzIHmd+hV+Su+3s4R2RogIOhiU04CcmsXNtKOtVP+yYrshEpk1pCf6d6N3zAcOv23sZPLaIPUCjGjCQ== X-Received: by 10.55.151.7 with SMTP id z7mr7060987qkd.316.1486705498946; Thu, 09 Feb 2017 21:44:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Feb 2017 21:44:58 -0800 (PST) In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> From: Martin Thomson Date: Fri, 10 Feb 2017 16:44:58 +1100 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 05:45:01 -0000 On 10 February 2017 at 16:07, Sean Turner wrote: > a) Close these two PRs and go with the existing text [0] > b) Adopt PR#765 [1] > c) Adopt PR#769 [2] a) I'm happy enough with the current text (I've implemented that any it's relatively easy). I could live with c, but I'm opposed to b. It just doesn't make sense. It's not obviously wrong any more, but the way it is written it is very confusing and easily open to misinterpretation. From nobody Fri Feb 10 01:06: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 93FEC1294B9 for ; Fri, 10 Feb 2017 01:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 JkQ3bWMeclrI for ; Fri, 10 Feb 2017 01:06:10 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50071.outbound.protection.outlook.com [40.107.5.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE36129410 for ; Fri, 10 Feb 2017 01:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XVhFIPgYnQorX5k4zcwGPLJ4e//ZP+2qn4OTlPF594c=; b=ro+SmDlHSq69EWfLPb37Ndbv+CFgbyz8TyH+r6Ke5I1LrQaeHklBvHNDUDhj02NNb42WZEjnflGU0uo4L/GjdGEkDOXVHmKAH9q4IohOEvM2xuxtBbfTG8+kJs1HOM1zCVFVIwP39ZcDVgaMdTGCXtg0bt1xuY51CJtdrkVuk5w= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 09:06:07 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 09:06:07 +0000 From: "Paterson, Kenny" To: Sean Turner Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koA= Date: Fri, 10 Feb 2017 09:06:07 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [78.146.76.254] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:Q90T0VHKTJU0ye1bHUqTpTTD0FhszZITv44tPIMbYfxWFyA47pBzSujqwOva3ViCmsDOn6DX5tnsSllDPbDrQ7fOhnEunojhhZrn5MG6Qp/Nlj3ZxK09xfRzoQWuuqSSXj9FDzcTzKHvkN0jCcfuvgKnnE03pMeWdpXjRYn8XS+YlCIbnLz06wdaMreWeXMKqx0cmskjUsd4XnUP1D7L6uddbra1xDUh/Od/BS5L5qxLwjoQqqKtLR0vn/tkZVhqK9jX9GVhKfGMcSPZfSxVxXAu9zILay/2Z4AShjOWf79XLM425fI4+KaKL3TjuhSZXvgdJz0wsFf0e5pvqqk2p9Diz6QwjxDV0TqsvrEuzOetogQ0xa6dGABqhUIUE1aLFyyltfCmYZ36nf2dTG9wH1jPaGwqIZTO+gl5xvm8FD/9nIrNJKLoLDlx6ELAMEiivZ0SreCdqZHCnNoOhMrhPF3Yx1xgxSyLMEUDbgzPTeDw77Rv3qeH8hZzbxbY3rQqMbYkITniknmUqJITBn+JVw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(101416001)(8936002)(106356001)(2950100002)(6916009)(106116001)(42882006)(74482002)(68736007)(105586002)(2906002)(4326007)(122556002)(86362001)(36756003)(7736002)(66066001)(3846002)(102836003)(6116002)(81156014)(5660300001)(53546003)(6246003)(229853002)(8676002)(53936002)(92566002)(2900100001)(81166006)(3280700002)(99286003)(54906002)(6486002)(4001350100001)(76176999)(50986999)(77096006)(6506006)(3660700001)(38730400002)(189998001)(25786008)(110136004)(83506001)(97736004)(6512007)(54356999)(68196006)(6436002)(305945005)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: e4265914-066f-468c-03a8-08d451940cca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1907; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907; x-forefront-prvs: 0214EB3F68 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <702D4EBAC6C88847AC69B3266840936D@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 09:06:07.5436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 09:06:12 -0000 SGksDQoNCk15IHByZWZlcmVuY2UgaXMgdG8gZ28gd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgb3B0 aW9uIGEpLg0KDQpGcm9tIHRoZSBnaXRodWIgZGlzY3Vzc2lvbiwgSSB0aGluayBvcHRpb24gYykg aW52b2x2ZXMgYSBsZXNzIGNvbnNlcnZhdGl2ZQ0Kc2VjdXJpdHkgYm91bmQgKHN1Y2Nlc3MgcHJv YmFiaWxpdHkgZm9yIElORC1DUEEgYXR0YWNrZXIgYm91bmRlZCBieQ0KMl57LTMyfSBpbnN0ZWFk IG9mIDJeey02MH0pLiBJIGNhbiBsaXZlIHdpdGggdGhhdCwgYnV0IHRoZSBXRyBzaG91bGQgYmUN CmF3YXJlIG9mIHRoZSB3ZWFrZXIgc2VjdXJpdHkgZ3VhcmFudGVlcyBpdCBwcm92aWRlcy4NCg0K SSBkbyBub3QgdW5kZXJzdGFuZCBvcHRpb24gYikuIEl0IHNlZW1zIHRvIHJlbHkgb24gYW4gYW5h bHlzaXMgb2YNCmNvbGxpc2lvbnMgb2YgY2lwaGVydGV4dCBibG9ja3MgcmF0aGVyIHRoYW4gdGhl IGVzdGFibGlzaGVkIHNlY3VyaXR5IHByb29mDQpmb3IgQUVTLUdDTS4NCg0KUmVnYXJkcywNCg0K S2VubnkNCg0KT24gMTAvMDIvMjAxNyAwNTo0NCwgIkNmcmcgb24gYmVoYWxmIG9mIE1hcnRpbiBU aG9tc29uIg0KPGNmcmctYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YgbWFydGluLnRob21z b25AZ21haWwuY29tPiB3cm90ZToNCg0KPk9uIDEwIEZlYnJ1YXJ5IDIwMTcgYXQgMTY6MDcsIFNl YW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQo+PiBhKSBDbG9zZSB0aGVzZSB0d28g UFJzIGFuZCBnbyB3aXRoIHRoZSBleGlzdGluZyB0ZXh0IFswXQ0KPj4gYikgQWRvcHQgUFIjNzY1 IFsxXQ0KPj4gYykgQWRvcHQgUFIjNzY5IFsyXQ0KPg0KPg0KPmEpIEknbSBoYXBweSBlbm91Z2gg d2l0aCB0aGUgY3VycmVudCB0ZXh0IChJJ3ZlIGltcGxlbWVudGVkIHRoYXQgYW55DQo+aXQncyBy ZWxhdGl2ZWx5IGVhc3kpLg0KPg0KPkkgY291bGQgbGl2ZSB3aXRoIGMsIGJ1dCBJJ20gb3Bwb3Nl ZCB0byBiLiBJdCBqdXN0IGRvZXNuJ3QgbWFrZSBzZW5zZS4NCj5JdCdzIG5vdCBvYnZpb3VzbHkg d3JvbmcgYW55IG1vcmUsIGJ1dCB0aGUgd2F5IGl0IGlzIHdyaXR0ZW4gaXQgaXMNCj52ZXJ5IGNv bmZ1c2luZyBhbmQgZWFzaWx5IG9wZW4gdG8gbWlzaW50ZXJwcmV0YXRpb24uDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DZnJnIG1haWxpbmcg bGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NmcmcNCg0K From nobody Fri Feb 10 03:26: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 6D88A1294F6 for ; Fri, 10 Feb 2017 03:26:25 -0800 (PST) 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=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 unIKtpCP5cPz for ; Fri, 10 Feb 2017 03:26:23 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 32C23129552 for ; Fri, 10 Feb 2017 03:26:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 575141CEBB; Fri, 10 Feb 2017 13:26:21 +0200 (EET) 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 pK1LaYVhC7ln; Fri, 10 Feb 2017 13:26:19 +0200 (EET) 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 E4F8921C; Fri, 10 Feb 2017 13:26:19 +0200 (EET) Date: Fri, 10 Feb 2017 13:26:17 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20170210112617.GA21741@LK-Perkele-V2.elisa-laajakaista.fi> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.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: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:26:25 -0000 On Fri, Feb 10, 2017 at 04:44:58PM +1100, Martin Thomson wrote: > On 10 February 2017 at 16:07, Sean Turner wrote: > > a) Close these two PRs and go with the existing text [0] > > b) Adopt PR#765 [1] > > c) Adopt PR#769 [2] > > > a) I'm happy enough with the current text (I've implemented that any > it's relatively easy). > > I could live with c, but I'm opposed to b. It just doesn't make sense. > It's not obviously wrong any more, but the way it is written it is > very confusing and easily open to misinterpretation. I couldn't make out what b) says, c) is much clearer. However, even in a), let alone b) or c), the limits are so high that one should do some greasing, or this feature seems like a prime candidate for rusting shut. -Ilari From nobody Fri Feb 10 04:38: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 26D0C1295B2 for ; Fri, 10 Feb 2017 04:38:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=nistgov.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 yqBTCN4hVEjP for ; Fri, 10 Feb 2017 04:38:36 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0101.outbound.protection.outlook.com [23.103.201.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 8781A1295E0 for ; Fri, 10 Feb 2017 04:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FgRpksH1PX5jNzPkwBaheUWRuxHGFvtj8oE+6jvC41Y=; b=v7dugR6zuCShPGLspiMWxw+JdzjcSELC9MPqIVcCQPnzt3LL3hJIpdYW5ARXbfAHrBInDTJZr7Ai2u+Ug4vhfPyNpFSD/w2nxanRLmunjTYNh/MrKTjc18EgYwUKtaL/Inmu+qvfwnWLv+VUIWmfw1XneipJlv01jGO+Morr4p8= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 12:38:35 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 12:38:35 +0000 From: "Dang, Quynh (Fed)" To: Sean Turner , "" Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg1ujO2IdKSxzmEyFi9zUyMXxM6FiINGq Date: Fri, 10 Feb 2017 12:38:34 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 7cf13fea-527e-4362-0fc3-08d451b1bac0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:Hq/mF2Aq8CpakIfcCLl18q0Wk1cJdXc+EwjKT0ZzUTGubGBubzGRoYYCZH1uObQ/Lhz5I/g0ZbG2tlaVEkSx0z4bbzmxHnIoljKoWSSzqYBcJEvpwyZPJRaYSHtF3I89BlPgAtWHT3PM/NEJTJsu1hTFcWsvl9Xg2MCrBbBUwmg8+iyj3CUXJt6zYjfo5K9TUkMc8c26I66MU595z86jiwd5qlEL/VnBToQlPMI4vOYDccX/WYHSSaeGiOunCmuR+56N/BJDMfOYemK46jDkdyhSj5UUIq2RkQIzW1gQy/gh9FvjIt13vS48JWiZbt8r/aoJzLphtWTj0bQH230zthKMigCostYuoHZQX4EyRPCmVwwq+6XmajiyBCoyUywHetfEXPOkGV8z7NPI3DHz245TyFMvRpVq0+613Rzpj1B6PjWwrUjlXr6oo0vr7w/CMosKYDwX1fF6O1H8Dl4wUBaJqI1QZefzxkByq+ZMPCpyCEtZMtmzJi3BDtwxEk4dwtJvOuuufGzZKuVFsIkbMQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39410400002)(39450400003)(199003)(377454003)(189002)(6116002)(54356999)(76176999)(3660700001)(50986999)(92566002)(25786008)(53936002)(74316002)(2950100002)(6436002)(55016002)(54896002)(606005)(3280700002)(77096006)(7906003)(9686003)(6306002)(3846002)(6506006)(81156014)(5660300001)(8676002)(101416001)(122556002)(81166006)(8936002)(7736002)(33656002)(4326007)(7696004)(102836003)(86362001)(97736004)(236005)(66066001)(2900100001)(68736007)(229853002)(99286003)(106356001)(189998001)(106116001)(38730400002)(105586002)(6246003)(53546003)(2906002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 12:38:34.8621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Cc: IRTF CFRG Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:38:39 -0000 --_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sean and all, I agree with everyone that the text in (b) was not very good text. The problem with (c) is that it is not precise at places and it leaves out = a lot of informative discussions which users should know. The sentence "The maximum amount of plaintext data that can be safely encry= pted with AES-GCM in a session is 2^48 128-bit blocks (2^52 bytes), assumi= ng probability of success at 1/2^32" is not clear. What is the success he= re? And, with 2^48 (full or partial) blocks, the collision probability is b= elow (not at) 2^(-32). And, "safely encrypted", what does this mean? I would like not having a col= lision among 128-bit blocks of ciphertexts, but I dont see any damage to th= e data owner who sends the encrypted data over a TLS session. I copied the text that I later proposed under the discussion of PR#769 belo= w. " To use AES-GCM to provide authenticity of authenticated data, confidentia= lity of plaintext content, and information leakage [0] protection for the p= laintext safely, the limit of total ciphertext under a single key is ( (TLS= CipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 = 128-bit blocks. When the data limit is reached, the chance of having a collision among 128-= bit blocks of the ciphertext is below 2^(-32) which is negligible. Since the block size of AES is 128 bits, there will be collisions among dif= ferent sets of ciphertext from multiple sessions using GCM (or any other mo= des of AES) when the total amount of the ciphertext of all considered sessi= ons is more than 2^64 128-bit blocks. This fact does not seem to create a p= ractical security weakness of using AES GCM. For ChaCha20/Poly1305, the record sequence number would wrap before the saf= ety limit is reached. See [AEAD-LIMITS] for further analysis. [0]: Information leakage in the context of TLS is a chosen-plaintext distin= guishing attack where the attacker provides 2 128-bit plaintext blocks to a= GCM encryption engine, after seeing one encrypted block for one of the 2 p= laintext blocks, the attacker knows which plaintext block was encrypted. Or= , it means that there is a collision among 128-bit blocks of the ciphertext= . " 1. The text above uses blocks instead of bytes or records of ciphertext. 2. The partial block situation is taken into account. " Or, using good text from PR769 provided by brainhub, the first paragraph co= uld be replaced by the following. "To use AES-GCM to provide authenticity of authenticated data, confidential= ity of plaintext content, and information leakage [0] protection for the pl= aintext, the limit of total ciphertext under a single key is 2^48 128-bit b= locks with the ciphertext size being rounded up to the next 16-byte boundar= y. " Regards, Quynh. ________________________________ From: Cfrg on behalf of Sean Turner Sent: Friday, February 10, 2017 12:07:35 AM To: Cc: IRTF CFRG Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) All, We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1= 3 Section 5.5 =93Limits on Key Usage=94. As it relates to rekeying, these = limits have been discussed a couple of times and we need to resolve once an= d for all whether the TLS WG wants to: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] Please indicate you preference to the TLS mailing list before Feb 17. Note= that unless there=92s clear consensus to change the text will remain as is= (i.e., option a). J&S [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 [1] https://github.com/tlswg/tls13-spec/pull/765 [2] https://github.com/tlswg/tls13-spec/pull/769 _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Sean and all,


I agree with everyone that the text in (b) was not very good text.


The problem with (c) is that it is not precise at places and it lea= ves out a lot of informative discussions which users should know. 


The sentence "The maximum amount of plaintext data that can b= e safely encrypted with  AES-GCM in a session is 2^48 128-bit blocks (= 2^52 bytes), assuming  probability of success at 1/2^32" is not c= lear.  What is the success here? And, with 2^48 (full or partial) blocks, the collision probability is below (not at) 2^(-3= 2). 


" <= span style=3D"color:rgb(51,51,51); font-size:14px">To use AES-GCM to provid= e authenticity of authenticated data, confidentiality of plaintext conten= t, and informati= on leakage [0] protection for the plaintext safely, the limit of total ciph= ertext under a single key is ( (TLSCipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 128-bit blocks.


When t= he data limit is reached, the chance of having a collision among 128-bit bl= ocks of the ciphertext is below 2^(-32) which is negligible.

Since = the block size of AES is 128 bits, there will be collisions among different= sets of ciphertext from multiple sessions using GCM (or any other modes of= AES) when the total amount of the ciphertext of all considered sessions is more than 2^64 128-bit blocks. Th= is fact does not seem to create a practical security weakness of using AES = GCM.

For Ch= aCha20/Poly1305, the record sequence number would wrap before the safety li= mit is reached. See [AEAD-LIMITS] for further analysis.

[0]: I= nformation leakage in the context of TLS is a chosen-plaintext distinguishi= ng attack where the attacker provides 2 128-bit plaintext blocks to a GCM e= ncryption engine, after seeing one encrypted block for one of the 2 plaintext blocks, the attacker knows whic= h plaintext block was encrypted. Or, it means that there is a collision amo= ng 128-bit blocks of the ciphertext. "

  1. The text above uses blocks instead of bytes o= r records of ciphertext.
  2. The partial block situation is taken into account.
" 

"To use AES-GCM to provide authenticity of authenticated data, confident= iality of plaintext content, and information leakage [0] protec= tion for the plaintext, the limit of total ciphertext under a single key is= 2^48 128-bit blocks with the ciphertext size being rounded up to the next 16-byte boundary. "


Regards,

Quynh.  

From: Cfrg <cfrg-bounc= es@irtf.org> on behalf of Sean Turner <sean@sn3rd.com>
Sent: Friday, February 10, 2017 12:07:35 AM
To: <tls@ietf.org>
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" P= Rs (#765/#769)
 
All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1= 3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, t= hese limits have been discussed a couple of times and we need to resolve on= ce and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17. = Note that unless there=92s clear consensus to change the text will remain = as is (i.e., option a).

J&S

[0] https:/= /tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github= .com/tlswg/tls13-spec/pull/765
[2] https://github= .com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org= /mailman/listinfo/cfrg
 --_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_-- From nobody Fri Feb 10 04:44: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 37E8F12962B for ; Fri, 10 Feb 2017 04:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 sijLcHcLLwBq for ; Fri, 10 Feb 2017 04:44:19 -0800 (PST) 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 D2D381295E0 for ; Fri, 10 Feb 2017 04:44:18 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id x1so20687544lff.0 for ; Fri, 10 Feb 2017 04:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=FVlpW/jcXyOw6/HfkFxoRlbwVO9F0guo62LstWMyirg=; b=pOGjKXVsbo1jixY+hP71B7JnyArKeoABzGYQqfhjYafgnabW9KZxK6P0FcOwBdoG5a f25VgbhMjU3COzNYKs3fs9DKpdIGjXuDq57chTX9rPSQtw+tgPoVfmC/MaBoetCRq4aH Kr/M1rlSm/CXCN2zR0zRTdOlUBoa+V2C6zBa8PioXvkFV0k7ae+oMMtootOomuIyGt4X kLhQJlZd+ZrJTaQaPz98kw+dYqtT/71EpFva4m2stdPYJpY1hprhZuIPM4LcnpU+bw4j hoPSrG5qL696dHms6NeINNrp85P8RFm0ZWygLlyCrzjP6XM2e76dkQ/Xzefn2M6f+mKe OI5Q== 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:from:date:message-id:subject :to; bh=FVlpW/jcXyOw6/HfkFxoRlbwVO9F0guo62LstWMyirg=; b=RsOfZzoRu8SCjWSOsYaLGWDg/O/9spCt7rmqRkdLRmTXmm9MEFvocSTDFEHjNqKXVa Cz9K3O2PXNE47dUfvAq1NEgGenWO3ecEbF2yMXRF/tZE0eW9A2jJXVnkiiJOWx3KHPuF TddPDW1EZLdO2/BsRQLmRWU2NXwrkv8cu5mQvguojKkWo6wOeMTzp8gLIUf5v3C8bglU nNVmbnQAX/8O28CgP48WNc468VV4TCMTELLfChj6ETdy7BaGtBr64KL/LYQlnb3iU7qy HZ+qFpRh/fMvrVrStq7FtH5+GlHT7D2UASwYx7zXDrrUAl8VynG4iAlAajOmLw/NjkdP HM8A== X-Gm-Message-State: AMke39kWOmYeiVx4KU99b8bU+IyzJl3RpjFaIC5Xsg29Te+eFzmbmwvZvLRlYpsQ1EmEuDHZ6BeA8rnWvw2RmQ== X-Received: by 10.25.40.4 with SMTP id o4mr2986443lfo.1.1486730656873; Fri, 10 Feb 2017 04:44:16 -0800 (PST) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.46.0.164 with HTTP; Fri, 10 Feb 2017 04:43:56 -0800 (PST) From: Cas Cremers Date: Fri, 10 Feb 2017 12:43:56 +0000 X-Google-Sender-Auth: pV01NsbctYxnYURN7FF9jsrPw18 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11410e58ae04ce05482c743f Archived-At: Subject: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:44:22 -0000 --001a11410e58ae04ce05482c743f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, In the process of completing our Tamarin analysis of TLS 1.3 revision 18, we hit upon some behaviour that may lead to applications making incorrect assumptions. It is not an immediate attack, but we can imagine scenarios where it can cause problems. We describe it below, and show that it is possible to adapt the protocol (leveraging existing mechanisms) to avoid a mismatch. Currently, the post-handshake client authentication does not cause updates to the transcript, and does not necessarily trigger key updates. As a result, the post-handshake client authentication offers substantially lower guarantees *for the client* than the normal mutual authentication. To see why this is the case, consider the following two properties that hold for the mutually authenticated handshake: (A) After the mutually authenticated handshake, a client who sends some data can be sure that if the server receives it, the server will be aware that it comes from an authenticated client. (B) After the mutually authenticated handshake, a client who receives some data can be sure that when the server sent it, the server was aware that it was sending it to an authenticated client. (Formally: upon receiving data, the client has agreement with the server on the status (unilateral/mutual) of the connection.) >From our analysis we have concluded that no such properties hold for the post-handshake client authentication. The reason is that the post-handshake client authentication does not change the transcript, and does not trigger a key update: effectively, the server has no way of informing the client that it has actually processed the post-handshake client authentication. Thus, the client will get identical future messages, irrespective of whether the server received the client authentication. Generally speaking, a unilaterally authenticated connection should have a different context, and therefore different keys, than a mutually authenticated connection. Currently, this is not the case for the post-handshake authentication. Potential problem scenario Assume that the server has two security policies: if a message is received from an authenticated client, it is marked as "top secret" and stored safely. If a message is received from an unauthenticated client, it is stored in plaintext or even published in a log. After a mutual authentication handshake, if the client sends some critical data then it can be sure this is stored securely. However, this is not the case for a post-handshake client authentication. After performing a post-handshake authentication (in which the client sends its certificate), and possibly after exchanging further messages with the server, the client may send some critical data. This data may be stored insecurely as there will be a mismatch between the client and server=E2=80= =99s respective views of authentication if the post-handshake authentication messages are not processed by the server and/or dropped by an attacker. Option 1: Fix In our view, the unilateral/mutual authentication status should be part of the context, and thus correspond to different keys. We are aware that the server=E2=80=99s request for post-handshake authentication is desired to be asynchronous (since user input might be needed). The most natural fix to the problem therefore is to include the client's response authentication messages (certificate etc.) in the message transcript, and require key updates. Option 2: Partial fix It is also possible to simply update the keys, leaving the transcript as is. This allows the client to infer whether his authentication message was received. However it does still allow for re-ordering of some messages. This has the disadvantage that the client certificate is still not included in the context, which may be problematic further down the line. Option 3: Don=E2=80=99t fix (=E2=80=9CSomebody Else=E2=80=99s Problem shiel= d=E2=80=9D) If we do not change the protocol, the draft should be updated to explicitly state that after a post-handshake authentication, the client can make no assumptions on the authentication status of the connection (mutual or unilateral). If the client would like to know the perceived status, it could ask the application layer. We do not advocate this solution, since the resulting difference between the guarantees of a regular mutually authenticated handshake and a post-handshake client authentication will surely lead to problems somewhere, and client applications will wrongly assume that after they send the post-handshake certificate, the server is aware that the connection is mutually authenticated. Tamarin analysis Using Tamarin, we showed that the properties (A) and (B) hold for the normal mutually authenticated handshake. We also showed that similar properties do not hold after the post-handshake client authentication, and we obtain the obvious counter-examples. If we apply the partial fix (2), the counter-examples indeed disappear. Conclusion In revision 18, the client can not be sure that the server agrees on the client=E2=80=99s authentication status after post-handshake authentication,= even after exchanging further messages. To avoid problems at the application level, we would prefer this agreement to be ensured. Best wishes, Cas Cremers, Marko Horvat, Jonathan Hoyland, Sam Scott, and Thyla van der Merwe. --001a11410e58ae04ce05482c743f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear all,<= br>


In the process of completing our Tamarin analysis of TLS 1.3 revision 18, = we hit upon some behaviour that may lead to applications making incorrect a= ssumptions. It is not an immediate attack, but we can imagine scenarios whe= re it can cause problems. We describe it below, and show that it is possibl= e to adapt the protocol (leveraging existing mechanisms) to avoid a mismatc= h.


Currently, the post-handshake client authentication does not cause u= pdates to the transcript, and does not necessarily trigger key updates. As = a result, the post-handshake client authentication offers substantially low= er guarantees *for the client* than the normal mutual authentication. To se= e why this is the case, consider the following two properties that hold for= the mutually authenticated handshake:


(A) After the mutually authent= icated handshake, a client who sends some data can be sure that if the serv= er receives it, the server will be aware that it comes from an authenticate= d client.


(B) After the mutually authenticated handshake, a client who= receives some data can be sure that when the server sent it, the server wa= s aware that it was sending it to an authenticated client. (Formally: upon = receiving data, the client has agreement with the server on the status (uni= lateral/mutual) of the connection.)


From our analysis we have concluded= that no such properties hold for the post-handshake client authentication.= The reason is that the post-handshake client authentication does not chang= e the transcript, and does not trigger a key update: effectively, the serve= r has no way of informing the client that it has actually processed the pos= t-handshake client authentication. Thus, the client will get identical futu= re messages, irrespective of whether the server received the client authent= ication.


Generally speaking, a unilaterally authenticated connection sh= ould have a different context, and therefore different keys, than a mutuall= y authenticated connection. Currently, this is not the case for the post-ha= ndshake authentication.


Potential problem scenario


Assume that the = server has two security policies: if a message is received from an authenti= cated client, it is marked as "top secret" and stored safely. If = a message is received from an unauthenticated client, it is stored in plain= text or even published in a log. After a mutual authentication handshake, i= f the client sends some critical data then it can be sure this is stored se= curely.


However, this is not the case for a post-handshake client auth= entication. After performing a post-handshake authentication (in which the = client sends its certificate), and possibly after exchanging further messag= es with the server, the client may send some critical data. This data may b= e stored insecurely as there will be a mismatch between the client and serv= er=E2=80=99s respective views of authentication if the post-handshake authe= ntication messages are not processed by the server and/or dropped by an att= acker.


Option 1: Fix


In our view, the unilateral/mutual authenticat= ion status should be part of the context, and thus correspond to different = keys. We are aware that the server=E2=80=99s request for post-handshake aut= hentication is desired to be asynchronous (since user input might be needed= ). The most natural fix to the problem therefore is to include the client&#= 39;s response authentication messages (certificate etc.) in the message tra= nscript, and require key updates.


Option 2: Partial fix


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">It is also = possible to simply update the keys, leaving the transcript as is. This allo= ws the client to infer whether his authentication message was received. How= ever it does still allow for re-ordering of some messages. This has the dis= advantage that the client certificate is still not included in the context,= which may be problematic further down the line.


Option 3: Don=E2=80= =99t fix (=E2=80=9CSomebody Else=E2=80=99s Problem shield=E2=80=9D)<= /p>

If = we do not change the protocol, the draft should be updated to explicitly st= ate that after a post-handshake authentication, the client can make no assu= mptions on the authentication status of the connection (mutual or unilatera= l). If the client would like to know the perceived status, it could ask the= application layer. We do not advocate this solution, since the resulting d= ifference between the guarantees of a regular mutually authenticated handsh= ake and a post-handshake client authentication will surely lead to problems= somewhere, and client applications will wrongly assume that after they sen= d the post-handshake certificate, the server is aware that the connection i= s mutually authenticated.


Tamarin analysis


Using Tamarin, we showed= that the properties (A) and (B) hold for the normal mutually authenticated= handshake. We also showed that similar properties do not hold after the po= st-handshake client authentication, and we obtain the obvious counter-examp= les. If we apply the partial fix (2), the counter-examples indeed disappear= .


Conclusion


In revision 18, the client can not be sure that the se= rver agrees on the client=E2=80=99s authentication status after post-handsh= ake authentication, even after exchanging further messages.

To avoid probl= ems at the application level, we would prefer this agreement to be ensured.=


Best wishes,


Cas Cremers,

Marko Horvat,

Jonathan Hoyland,

Sam Scot= t, and

Thyla van der Merwe.


=
--001a11410e58ae04ce05482c743f-- From nobody Fri Feb 10 04:48: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 B2BFF129653 for ; Fri, 10 Feb 2017 04:48:44 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=nistgov.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 zqZl6OhnkEyR for ; Fri, 10 Feb 2017 04:48:43 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2546F129483 for ; Fri, 10 Feb 2017 04:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VDJW7fswKUh9lKl3szACBtUEmkwvCD/WAZmiOSQ4ozY=; b=BFYe+rJCm8d3GEq16EVL1QC6zysmRsO53QdTF53B0a4z2ipZLuY+sw9zgTZYDQiT8DAPTUjG1a1chykqBkgnTD+Tbjf7UPDWnbeLO0rX/X0h6cnNWmGlOYU0/kvzrDAF4WWRf1YNuRnzZLHFPS9eWjjP892jf/eCIksEKJPr4t0= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 12:48:41 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 12:48:41 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , Sean Turner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlg== Date: Fri, 10 Feb 2017 12:48:41 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 3c2cc685-ee47-4611-669c-08d451b3244a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:FNaw6j0epX9NwZAnWwwKsErqCnbjdjshHGKpmr6UTDLyAUJ0Gy+94I5CoqxF+ejEQPzOMdk7vgsWb+16zfyOdbletZWp9LeEzSCfzGeK3Ju3LChqVyn8a8BTjVHiiDnoHgwfvRRxpmyqlWi7YNlyOnX2zmnU4OzGxM598FBKJ7zXKCfgFoUD+rNCJaDE2KXyGoyHhSKAUMxqV/dsaT31kZ8dd0Y46eDsF1GDyz8SMtsK0K+s489e5NeIvGa9Y182kyhk9d8fill7TfkBKU4Ypw1QMna25Qo/8ElEear2/LZ0UTXjP22CjnTcMtBeSdFWLB9cot1wZwjAotZ/hBF/gwxLJ1QuZjhgOB9ur7ez2/MkfCvE58mtobENFE4QG7P8QG6igL3ROMjeempZHvkuSwN3Eovc0pMq1fG9wPOXkCHQYzj4CXKggsW0GNZcuclt5UzT/MpCIakzPXl0hnIuWibhccGhab/iXmmZj2PdjloUfje1EtMAR68fM+KBJ3iQ/++/LqcqgsCymBzmGq0DKA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(24454002)(189002)(377454003)(199003)(229853002)(2950100002)(77096006)(6436002)(5660300001)(92566002)(3846002)(102836003)(6116002)(6506006)(25786008)(606005)(6306002)(8656002)(54896002)(53936002)(236005)(97736004)(6512007)(99286003)(54906002)(101416001)(50986999)(66066001)(2900100001)(4001350100001)(2906002)(54356999)(3280700002)(68736007)(3660700001)(189998001)(76176999)(6486002)(122556002)(86362001)(4326007)(106356001)(105586002)(6246003)(106116001)(36756003)(53546003)(7906003)(81156014)(81166006)(7736002)(8676002)(8936002)(83506001)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4C31FC42F5AFqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 12:48:41.4623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:48:44 -0000 --_000_D4C31FC42F5AFqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kenny, From: TLS > on behalf of = "Paterson, Kenny" > Date: Friday, February 10, 2017 at 4:06 AM To: Sean Turner > Cc: IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Hi, My preference is to go with the existing text, option a). >From the github discussion, I think option c) involves a less conservative security bound (success probability for IND-CPA attacker bounded by 2^{-32} instead of 2^{-60}). I can live with that, but the WG should be aware of the weaker security guarantees it provides. I do not understand option b). It seems to rely on an analysis of collisions of ciphertext blocks rather than the established security proof for AES-GCM. My suggestion was based on counting. I analyzed AES-GCM in TLS 1.3 as bei= ng a counter-mode encryption and each counter is a 96-bit nonce || 32-bit c= ounter. I don=92t know if there is another kind of proof that is more preci= se than that. Regards, Quynh. Regards, Kenny On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson" on behalf of martin.th= omson@gmail.com> wrote: On 10 February 2017 at 16:07, Sean Turner > wrote: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] a) I'm happy enough with the current text (I've implemented that any it's relatively easy). I could live with c, but I'm opposed to b. It just doesn't make sense. It's not obviously wrong any more, but the way it is written it is very confusing and easily open to misinterpretation. _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_D4C31FC42F5AFqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <81E61802C2AE14439A23D47F0A847436@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Kenny, 

From: TLS <tls-bounces@ietf.org> on behalf of "Paterson= , Kenny" <Kenny.Paters= on@rhul.ac.uk>
Date: Friday, February 10, 2017 at = 4:06 AM
To: Sean Turner <sean@sn3rd.com>
Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ie= tf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Hi,

My preference is to go with the existing text, option a).

From the github discussion, I think option c) involves a less conserva= tive
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should b= e
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security p= roof
for AES-GCM.

My suggestion was based on counting.  I analyzed AES-GCM in TLS 1= .3  as being a counter-mode encryption and each counter is a 96-bit no= nce || 32-bit counter. I don=92t know if there is another kind of proof tha= t is more precise than that.

Regards,
Quynh. 



Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

On 10 February 2017 at 16:07, Sean Turner <sean@sn3rd.com> wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.=
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

_______________________________________________
Cfrg mailing list

_______________________________________________
TLS mailing list

 --_000_D4C31FC42F5AFqdangnistgov_-- From nobody Fri Feb 10 07:51: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 BE68E1299F9 for ; Fri, 10 Feb 2017 07:51:47 -0800 (PST) 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 w041itkntLLr for ; Fri, 10 Feb 2017 07:51:45 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 9988B1299D0 for ; Fri, 10 Feb 2017 07:51:45 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id v96so53510407ioi.0 for ; Fri, 10 Feb 2017 07:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=y4aQbk4tvRIWe00fHBCRnkJ0HlLhsiKKAlMnvRRl63Y=; b=XPcXuB1iZWatzlaMyfATf2inUYKE9S/QLvLWARGRuDfvY5flgKlz2+OgLqXbqZSniZ z9ID57H8e5dYi8LWxlLA6rIqsXf7a8zGJIxrxePN31i7hxiRrN9mounL2IS6Atlg4i4y iAa+J+ACOqvOIdK+gZgWvGgADJLLhUMbyCvp/XUcd/gDn9xp9PqtOiiCxY27buffT1Aj pbSbj1w5PDVJx074WVssWmPuGXBLC6ocAnx7YBIdN+eMoIXwik3nSn4FHKgF+AVSCKA0 r7+3Pxmv+k0TUvk4j64x9QguWSPY7K4/3zASuGpnHLS8XlNCcgjOf3Yey44a+cRGRv6d P3Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=y4aQbk4tvRIWe00fHBCRnkJ0HlLhsiKKAlMnvRRl63Y=; b=QHdATtYg0pLEqXp7E3WCc8xoYV82orFd/KrjKSh49zlufPQ5ulVmDPT7pkY++SdN2s zZaw1NWhmflHTft7hVr9XxSLkL1ieUa9maUQdCzXoxAyA5eE2mUGFkjDyQVJSlOBawo2 SptPIxFZE3dNDt59fsizSlCDYzG0/CfrYD5/Et9MECQOzIcJQa4BVP/bUqpw8hLlOi1T 1EwyLBrnNkBPFLZMtJpm3BgTLyOJba7dj9dyXXduLvVagAQoHfq8RLu2nq7puqeCH8U5 5W9gxPN0BbVzYX1vH/3UyC6nyIEmQC4V+hNxVX11FYAMLPuKbZjo8I4ocBuEgQuvmdWP N1Fg== X-Gm-Message-State: AMke39nS/qTM1YJrurYuZXTBR0pSLR8ShsPu3j6m40gX5oHAZjvFeu8xujTu6gep4AZIHg== X-Received: by 10.107.20.13 with SMTP id 13mr9054953iou.0.1486741904935; Fri, 10 Feb 2017 07:51:44 -0800 (PST) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id h15sm508251ita.20.2017.02.10.07.51.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 07:51:44 -0800 (PST) To: Sean Turner , "" References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> From: Rene Struik Message-ID: Date: Fri, 10 Feb 2017 10:51:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> Content-Type: multipart/alternative; boundary="------------6F183E4431F40EF448049DCE" Archived-At: Cc: IRTF CFRG Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:51:48 -0000 This is a multi-part message in MIME format. --------------6F183E4431F40EF448049DCE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear colleagues: I would suggest adding the following paragraph at the end of Section 5.5: [current text of Section 5.5] There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.[AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key updateSection 4.6.3 prior to reaching these limits. For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached. [suggested additional text] The above upper limits do not take into account potential side channel attacks, which - in some implementations - have been shown to be successful at recovering keying material with a relatively small number of messages encrypted using the same key. While results are highly implementation-specific, thereby making it hard to provide precise guidance, prudence suggests that implementations should not reuse keys ad infinitum. Implementations SHALL therefore always implement the key update mechanism of Section 4.6.3. {editorial note: perhaps, one should impose the limit 2^20, just to make sure people do not "forget" to implement key updates?} See also my email of August 29, 2016: https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno On 2/10/2017 12:07 AM, Sean Turner wrote: > All, > > We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”. As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to: > > a) Close these two PRs and go with the existing text [0] > b) Adopt PR#765 [1] > c) Adopt PR#769 [2] > > Please indicate you preference to the TLS mailing list before Feb 17. Note that unless there’s clear consensus to change the text will remain as is (i.e., option a). > > J&S > > [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 > [1] https://github.com/tlswg/tls13-spec/pull/765 > [2] https://github.com/tlswg/tls13-spec/pull/769 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------6F183E4431F40EF448049DCE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update Section 4.6.3 prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel attacks, which - in some implementations - have been shown to be successful at recovering keying material with a relatively small number of messages encrypted using the same key. While results are highly implementation-specific, thereby making it hard to provide precise guidance, prudence suggests that implementations should not reuse keys ad infinitum. Implementations SHALL therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure people do not "forget" to implement key updates?}  


See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:
All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------6F183E4431F40EF448049DCE-- From nobody Fri Feb 10 08:04: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 63CD0129A27 for ; Fri, 10 Feb 2017 08:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DoQveGrsKynC for ; Fri, 10 Feb 2017 08:04:36 -0800 (PST) Received: from minos.uwaterloo.ca (minos.uwaterloo.ca [129.97.128.78]) (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 CBE22129A26 for ; Fri, 10 Feb 2017 08:04:35 -0800 (PST) Received: from localhost (jschanck.iqc.uwaterloo.ca [129.97.40.236]) (authenticated bits=0) by minos.uwaterloo.ca (8.14.4/8.14.4) with ESMTP id v1AG4XOL007886 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Feb 2017 11:04:33 -0500 Date: Fri, 10 Feb 2017 11:04:33 -0500 From: John Schanck To: Martin Thomson Message-ID: <20170210160432.o7izhdybswufv2vu@xyphr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-UUID: 4e0f3993-b1cb-46b0-9b89-e689fed397cb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#875: Additional Derive-Secret Stage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:04:37 -0000 Martin Thomson wrote: > This is a good idea. +1 > Just to highlight this point: if we need to add a PQ key exchange, > there is no guarantee that it will have exactly the same properties as > the key exchange methods we have today. I expect that need to arise > relatively soon, so that's an extra good reason to make this change. For the same reason, I think the labels for these new Derive-Secret calls should anticipate extensions that provide additional input secrets. This PR specifies labels for the PSK and (EC)DHE inputs Derive-Secret(., "derived early secret", "") Derive-Secret(., "derived handshake secret", ""), but the draft seems to allow arbitrarily many input secrets. Just above the diagram it says "Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc." So we might want the labels in the new Derive-Secret calls to indicate which InputSecret is being incorporated, e.g. Derive-Secret(., "derived secret 1", "") Derive-Secret(., "derived secret 2", "") Derive-Secret(., "derived secret 3", "") etc. I should also note that the draft does not specify how an extension would produce an additional input secret. So, alternatively, we could just strike out the "Given a set of n InputSecrets" line. I personally think there should be a way for extensions to provide additional input secrets. I can submit a PR along those lines if there is interest. -John From nobody Fri Feb 10 09:22: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 6C5D9129A65 for ; Fri, 10 Feb 2017 09:22:31 -0800 (PST) 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 dFnc4-wgmeJ7 for ; Fri, 10 Feb 2017 09:22:29 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5D129A61 for ; Fri, 10 Feb 2017 09:22:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1215E1EE5F; Fri, 10 Feb 2017 19:22:27 +0200 (EET) 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 Kh7btRsSs81B; Fri, 10 Feb 2017 19:22:26 +0200 (EET) 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 6EBB4C4; Fri, 10 Feb 2017 19:22:26 +0200 (EET) Date: Fri, 10 Feb 2017 19:22:24 +0200 From: Ilari Liusvaara To: Cas Cremers Message-ID: <20170210172224.GA22473@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: Cc: tls@ietf.org Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:22:31 -0000 On Fri, Feb 10, 2017 at 12:43:56PM +0000, Cas Cremers wrote: > Dear all, > > In the process of completing our Tamarin analysis of TLS 1.3 revision 18, > we hit upon some behaviour that may lead to applications making incorrect > assumptions. It is not an immediate attack, but we can imagine scenarios > where it can cause problems. We describe it below, and show that it is > possible to adapt the protocol (leveraging existing mechanisms) to avoid a > mismatch. Ah, Post-HS auth, one of the two things in TLS 1.3 that scare me. :-) > Currently, the post-handshake client authentication does not cause updates > to the transcript, and does not necessarily trigger key updates. As a > result, the post-handshake client authentication offers substantially lower > guarantees *for the client* than the normal mutual authentication. To see > why this is the case, consider the following two properties that hold for > the mutually authenticated handshake: > > (A) After the mutually authenticated handshake, a client who sends some > data can be sure that if the server receives it, the server will be aware > that it comes from an authenticated client. AFAICT, this fails even for TLS 1.3 in-handshake authentication. > (B) After the mutually authenticated handshake, a client who receives some > data can be sure that when the server sent it, the server was aware that it > was sending it to an authenticated client. (Formally: upon receiving data, > the client has agreement with the server on the status (unilateral/mutual) > of the connection.) And this too (failure of (A) already impiles this fails). > However, this is not the case for a post-handshake client authentication. > After performing a post-handshake authentication (in which the client sends > its certificate), and possibly after exchanging further messages with the > server, the client may send some critical data. This data may be stored > insecurely as there will be a mismatch between the client and server’s > respective views of authentication if the post-handshake authentication > messages are not processed by the server and/or dropped by an attacker. In TLS, the messages can't be dropped without tearing the entiere client- server link, but the server may indeed fail to process them. DTLS is another can of worms. > Option 1: Fix > > In our view, the unilateral/mutual authentication status should be part of > the context, and thus correspond to different keys. We are aware that the > server’s request for post-handshake authentication is desired to be > asynchronous (since user input might be needed). The most natural fix to > the problem therefore is to include the client's response authentication > messages (certificate etc.) in the message transcript, and require key > updates. This would require ACK/NAK for the authentication and restricting server to just one pending authentication in order to properly serialize the message order. And ACK/NAK is needed because otherwise this AFAICT won't solve the problem. And if you have the ACK/NAK, that should take care of the problem in cases not involving weak algorithms. > Option 2: Partial fix > > It is also possible to simply update the keys, leaving the transcript as > is. This allows the client to infer whether his authentication message was > received. However it does still allow for re-ordering of some messages. > This has the disadvantage that the client certificate is still not included > in the context, which may be problematic further down the line. I don't see how this helps: The client already knows its authentication block was delivered before any further data it sent. What it doesn't know is if the server acted on it. > Option 3: Don’t fix (“Somebody Else’s Problem shield”) > > If we do not change the protocol, the draft should be updated to explicitly > state that after a post-handshake authentication, the client can make no > assumptions on the authentication status of the connection (mutual or > unilateral). If the client would like to know the perceived status, it > could ask the application layer. We do not advocate this solution, since > the resulting difference between the guarantees of a regular mutually > authenticated handshake and a post-handshake client authentication will > surely lead to problems somewhere, and client applications will wrongly > assume that after they send the post-handshake certificate, the server is > aware that the connection is mutually authenticated. AFICT, This isn't just for post-handshake authentication. And also, the TLS stack has pretty limited view. It can't realistically assumed to know the actual authentication status of the connection. -Ilari From nobody Fri Feb 10 09:22: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 6F4F2129A6D for ; Fri, 10 Feb 2017 09:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 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=-1.887, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 TDo6TPqLVMvC for ; Fri, 10 Feb 2017 09:22:36 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0068.outbound.protection.outlook.com [104.47.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F21129A68 for ; Fri, 10 Feb 2017 09:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n/LRRwKHM6QBMFVVxjJ/3tsQYtdVZW9VtPZJT7oHpzM=; b=p4tyD2Vw7s451TZtqhgKEy4r+cryOi4dEyOCAEJcZQAG4T52vyJwg4pGutO4WBbk4VS1sZpmlaGjcl0csnFplHQx3PBTqWh0UBTevZIIRmHwDTwD1PsCi5agOF9gYjU66ApM5svTxBHk17tk/R3AyINswRh221sqVcXU6Xe4Ju8= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 17:22:33 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 17:22:33 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , Sean Turner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koCAAD3QgIAATPYA Date: Fri, 10 Feb 2017 17:22:32 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:pmFdocvmAxGE4SFBIix1OWUiObAnRMVo5ClVojqetHA+H9RosZ+yrvdXiIRlKDTRP/Nn+CpfFf/OOTX/v+1fEQTl5jIIU5wzu9u/nGECg8yCvGfbZH/T+LX9F6wTcCSniyToYQnXY+tzMh4Z6kYUoYqNuwOTyd326LD4xr3sQHz13Ybu9cEQSHm7EJSV7JhfVYULtK+BTLjKb1t6xc/oMv/uRz57bfpiVBLki5KA8ZZwCFjS6Ck658jGiyfk6I2l+AHPDELPSfdUaFhbbrwJsnyXO8QngzHfIfochof0iMeYQOhMQmgzlWB+FDcKlQcZb8t+oM9GWkiyQN/T5sIKd30Atr/bd9OAECbHFP3l0PEEdo8t28nva6DBKxx+w/edLkaQoWKQ4rAKM36gj4B6vwNOinfRB+RtXClhKSng2OnpTIlvzSQTK2nyhbQ89y25AviVVjp6ie2TwW4mRGCH2KeiZZwBiA+lnS0+xoU/i/ki2hAT0t+RQQKSLcJZWes9cYd64OkgL/6bgM00WHz9/Q== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(53546003)(8656002)(966004)(6246003)(5660300001)(81156014)(53936002)(8676002)(229853002)(3846002)(66066001)(7736002)(6116002)(102836003)(92566002)(83506001)(25786008)(189998001)(38730400002)(305945005)(6306002)(97736004)(6512007)(6436002)(54356999)(3280700002)(99286003)(2900100001)(54906002)(81166006)(76176999)(6506006)(77096006)(50986999)(3660700001)(4001350100001)(6486002)(8936002)(101416001)(2950100002)(106116001)(106356001)(42882006)(93886004)(86362001)(36756003)(68736007)(105586002)(2906002)(74482002)(122556002)(4326007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 5890bdce-02e8-42b5-84c0-08d451d96641 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1907; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907; x-forefront-prvs: 0214EB3F68 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <928EBE543230574E92C16DBD0D5BB4EC@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 17:22:32.9273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:22:45 -0000 RGVhciBRdXluaCwNCg0KT24gMTAvMDIvMjAxNyAxMjo0OCwgIkRhbmcsIFF1eW5oIChGZWQpIiA8 cXV5bmguZGFuZ0BuaXN0Lmdvdj4gd3JvdGU6DQoNCj5IaSBLZW5ueSwgDQo+DQo+PkhpLA0KPj4N Cj4+DQo+Pk15IHByZWZlcmVuY2UgaXMgdG8gZ28gd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgb3B0 aW9uIGEpLg0KPj4NCj4+DQo+PkZyb20gdGhlIGdpdGh1YiBkaXNjdXNzaW9uLCBJIHRoaW5rIG9w dGlvbiBjKSBpbnZvbHZlcyBhIGxlc3MNCj4+Y29uc2VydmF0aXZlDQo+PnNlY3VyaXR5IGJvdW5k IChzdWNjZXNzIHByb2JhYmlsaXR5IGZvciBJTkQtQ1BBIGF0dGFja2VyIGJvdW5kZWQgYnkNCj4+ Ml57LTMyfSBpbnN0ZWFkIG9mIDJeey02MH0pLiBJIGNhbiBsaXZlIHdpdGggdGhhdCwgYnV0IHRo ZSBXRyBzaG91bGQgYmUNCj4+YXdhcmUgb2YgdGhlIHdlYWtlciBzZWN1cml0eSBndWFyYW50ZWVz IGl0IHByb3ZpZGVzLg0KPj4NCj4+DQo+PkkgZG8gbm90IHVuZGVyc3RhbmQgb3B0aW9uIGIpLiBJ dCBzZWVtcyB0byByZWx5IG9uIGFuIGFuYWx5c2lzIG9mDQo+PmNvbGxpc2lvbnMgb2YgY2lwaGVy dGV4dCBibG9ja3MgcmF0aGVyIHRoYW4gdGhlIGVzdGFibGlzaGVkIHNlY3VyaXR5DQo+PnByb29m DQo+PmZvciBBRVMtR0NNLg0KPj4NCj4+DQo+DQo+DQo+TXkgc3VnZ2VzdGlvbiB3YXMgYmFzZWQg b24gY291bnRpbmcuICBJIGFuYWx5emVkIEFFUy1HQ00gaW4gVExTIDEuMyAgYXMNCj5iZWluZyBh IGNvdW50ZXItbW9kZSBlbmNyeXB0aW9uIGFuZCBlYWNoIGNvdW50ZXIgaXMgYSA5Ni1iaXQgbm9u Y2UgfHwNCj4zMi1iaXQgY291bnRlci4gSSBkb27igJl0IGtub3cgaWYgdGhlcmUgaXMgYW5vdGhl ciBraW5kIG9mIHByb29mIHRoYXQgaXMNCj5tb3JlIHByZWNpc2UgdGhhbiB0aGF0Lg0KDQpUaGFu a3MgZm9yIGV4cGxhaW5pbmcuIEkgdGhpbmssIHRoZW4sIHRoYXQgd2hhdCB5b3UgYXJlIGRvaW5n IGlzIChpbg0KZWZmZWN0KSBhY2NvdW50aW5nIGZvciB0aGUgUFJQL1BSRiBzd2l0Y2hpbmcgbGVt bWEgdGhhdCBpcyB1c2VkIChpbiBhDQpzdGFuZGFyZCB3YXkpIGFzIHBhcnQgb2YgdGhlIElORC1D UEEgc2VjdXJpdHkgcHJvb2Ygb2YgQUVTLUdDTS4gT25lIGNhbg0Kb2J0YWluIGEgZ3JlYXRlciBk ZWdyZWUgb2YgcHJlY2lzaW9uIGJ5IHVzaW5nIHRoZSBwcm92ZW4gYm91bmRzIGZvcg0KSU5ELUNQ QSBzZWN1cml0eSBvZiBBRVMtR0NNLiBUaGVzZSBpbmNvcnBvcmF0ZSB0aGUgInNlY3VyaXR5IGxv c3MiIGNvbWluZw0KZnJvbSB0aGUgUFJQL1BSRiBzd2l0Y2hpbmcgbGVtbWEuIFRoZSBjdXJyZW50 IGJlc3QgZm9ybSBvZiB0aGVzZSBib3VuZHMgaXMNCmR1ZSB0byBJd2F0YSBldCBhbC4uIFRoaXMg aXMgcHJlY2lzZWx5IHdoYXQgd2UgYW5hbHlzZSBpbiB0aGUgbm90ZSBhdA0KaHR0cDovL3d3dy5p c2cucmh1bC5hYy51ay9+a3AvVExTLUFFYm91bmRzLnBkZiAtIHNwZWNpZmljYWxseSwgc2VlDQpl cXVhdGlvbnMgKDUpIC0gKDcpIG9uIHBhZ2UgNiBvZiB0aGF0IG5vdGUuDQoNClJlZ2FyZHMsDQoN Cktlbm55IA0KDQo+DQo+DQo+UmVnYXJkcywNCj5RdXluaC4gDQoNCg== From nobody Fri Feb 10 10:48: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 A5FDA129A95 for ; Fri, 10 Feb 2017 10:48:01 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=nistgov.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 YPZa2Y-_vO-m for ; Fri, 10 Feb 2017 10:47:59 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0101.outbound.protection.outlook.com [23.103.200.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 7A21E12958B for ; Fri, 10 Feb 2017 10:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SWlHQSGNzXrUwlpYkIj1FyMXLO0pcIvMaQf70BdFMmk=; b=do9qw8Iha7GPBa5Ou/X8/luBqD92nOn29KfDFkRqn+vJPFyzbVXzQd4bgjxcS2lp5zdPCqaEcBKhT8u4rNo3epQ2mVh0PBkKgpwcLIYaPh42D5h1SdCcL9MlhzUUuGcGng4VssEaU4P6tLH/ntJMdXIyNfIjs5zhXDekSFJh1Ws= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 18:47:57 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 18:47:57 +0000 From: "Dang, Quynh (Fed)" To: Rene Struik , Sean Turner , "" Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg84y+88vw5exDE6fOqGEW6ep0A== Date: Fri, 10 Feb 2017 18:47:57 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: bb897306-0c91-4a53-d16e-08d451e554db x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:vjCOHdPXo2e/bEetYR/p871QNDIolpEpy6yRCuI8k+eFAXOfmAsennoSqAwWQP2S62VqElVPUCk+ZoNlwzYTlrZX40u9oinHZWqzIhqn6uujFk86kgqDHY78I6QFzO3EPARk43qfQtqKu3Y1pYh9xURBxN+U5k+1t4kMxm24wil1/mNQxv7P4dkiTBcjfduiTipu4jUdqyUgaHE1QsJNhCMcipQCmW8YR2v6aSa0LLlRVuQOQbyjG+T45yaddT56sSMdvKiN1zp/GONXxn1npnc7pa76JxOh7wvnkiztx3VVydqNxHGOrEo8MYdVZMw6XywpdepAScBBV45faGq+syOgki7s1llYvDfRpyC9QX/ke4BlW/Hd+ilG8UN47PehihcUlIFYyzjy6CziE/w4A8783ExEgXSH4peJJOhWFsw8mzo5cV0nmyVjVKih33eVjvR/AC5b6awhlpXYjzsnR2uDFjuPOQJvun1KJ+WaJivyXVfLWwhjWoDUEymbhruUED6g7PINt4rhQGyH9mUgrg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(199003)(189002)(377454003)(24454002)(2900100001)(2906002)(8936002)(3280700002)(3846002)(81156014)(2950100002)(102836003)(4326007)(6116002)(53936002)(5660300001)(81166006)(8676002)(38730400002)(105586002)(92566002)(106116001)(6246003)(189998001)(53546003)(106356001)(66066001)(76176999)(4001350100001)(54356999)(3660700001)(50986999)(6486002)(97736004)(77096006)(6436002)(325944008)(39060400001)(6506006)(229853002)(6306002)(101416001)(6512007)(99286003)(54896002)(236005)(25786008)(606005)(86362001)(68736007)(7906003)(36756003)(122556002)(575784001)(83506001)(7736002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4C3749F2F856qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:47:57.6983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Cc: IRTF CFRG Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:48:02 -0000 --_000_D4C3749F2F856qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Rene, From: TLS > on behalf of = Rene Struik > Date: Friday, February 10, 2017 at 10:51 AM To: Sean Turner >, ">" > Cc: IRTF CFRG > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Dear colleagues: I would suggest adding the following paragraph at the end of Section 5.5: [current text of Section 5.5] There are cryptographic limits on the amount of plaintext which can be safe= ly encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the = assumption that the underlying primitive (AES or ChaCha20) has no weaknesse= s. Implementations SHOULD do a key update Section 4.6.3 prior to reaching these limits. For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry= pted on a given connection while keeping a safety margin of approximately 2= ^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the= record sequence number would wrap before the safety limit is reached. [suggested additional text] The above upper limits do not take into account potential side channel atta= cks, which - in some implementations - have been shown to be successful at = recovering keying material with a relatively small number of messages encry= pted using the same key. While results are highly implementation-specific, = thereby making it hard to provide precise guidance, prudence suggests that = implementations should not reuse keys ad infinitum. Implementations SHALL t= herefore always implement the key update mechanism of Section 4.6.3. {editorial note: perhaps, one should impose the limit 2^20, just to make su= re people do not "forget" to implement key updates?} How do you do side channel attacks on TLS ? Do these side-channel attacks w= ork for AES-GCM only in TLS 1.3 ? See also my email of August 29, 2016: https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno On 2/10/2017 12:07 AM, Sean Turner wrote: All, We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1= 3 Section 5.5 =93Limits on Key Usage=94. As it relates to rekeying, these = limits have been discussed a couple of times and we need to resolve once an= d for all whether the TLS WG wants to: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] Please indicate you preference to the TLS mailing list before Feb 17. Note= that unless there=92s clear consensus to change the text will remain as is= (i.e., option a). J&S [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 [1] https://github.com/tlswg/tls13-spec/pull/765 [2] https://github.com/tlswg/tls13-spec/pull/769 _______________________________________________ Cfrg mailing list Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cf= rg -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_D4C3749F2F856qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Rene, 

From: TLS <tls-bounces@ietf.org> on behalf of Rene Struik &l= t;rstruik.ext@gmail.com> Date: Friday, February 10, 2017 at = 10:51 AM
To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tl= s@ietf.org>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:
[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be safe= ly encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primi= tive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key u= pdate Section 4.6.3 prior to reach= ing these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry= pted on a given connection while keeping a safety margin of approximately 2= ^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the= record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel atta= cks, which - in some implementations - have been shown to be successful at = recovering keying material with a relatively small number of messages encry= pted using the same key. While results are highly implementation-specific, thereby making it hard to provide prec= ise guidance, prudence suggests that implementations should not reuse keys = ad infinitum. Implementations SHALL therefore always implement the key upda= te mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make su= re people do not "forget" to implement key updates?}  

How do you do side channel attacks on TLS ? Do these side-channel atta= cks work for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/m= sg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:
All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.=
5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@ir=
tf.orghttps://www.irtf.org/mailman/listinfo/cfrg


--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
 --_000_D4C3749F2F856qdangnistgov_-- From nobody Fri Feb 10 10:56: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 6868C12944E for ; Fri, 10 Feb 2017 10:56:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=nistgov.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 6SEcp68UbfmV for ; Fri, 10 Feb 2017 10:56:39 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0091.outbound.protection.outlook.com [23.103.200.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C0D129AA0 for ; Fri, 10 Feb 2017 10:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0+sLTh04fK1cyaZhIJisGeM0u/+qNgKrsCb5IHXD3Ac=; b=0IT/dlgl9GlRlFeo0aSPWdxm8py6NXIldW4x9u781GCXT1QHfP5T6ih1GoSD5zhmTLZlsbtOasHw225YftpCzDUKrTRhCpEkuKRI1akor6c1LFgsxjasR59gQf3vycvy+IzW00bZDfzbRUdIVSrxnx7WsoVa5gNNiBMnHEoPwqg= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 18:56:37 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 18:56:36 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Sean Turner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlqFifU4A///GdAA= Date: Fri, 10 Feb 2017 18:56:36 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:DhTKf2QAA3QnW4l7eidfclmEg7si5fgLD5l/CCGf3XSZ9TX6UfwGKHJp0Knyv9EJ0VItzxiPqqm0r6+lGx0gapH+Z6hq9Odcpqop8dsDBpF1Pn5jQYGqMYUlZ5cMhrnxbGiKMxonDeYfr0YwJPV2saWviL9xjrjPYoEbT5esDm/K01hca59eUjabtYpasv0mA0AB0bWEykHeUTCfmBvtUhLHxZG/Yv0/jDBUUqYeIO5Xq5OBvx3tOiFoIWzZ33W3u3v00gZh195Ad1199epovHXgckcdQDJUTcrT7loOKw7TkhQgbS2xRTtXDG2idJK9BbA4jrlzholBrLDeF107PkbtHrIzNTWcWxpns9Sqz0Kc15mjq8qg3Ia/7Q3oem402lFfQCxn7x1gCa9jAPY9jw5291ZHn9Vuh5U1pIv6ImBBF2iKvudVzzRmWoTaRAXEwy9VNUpaOWOpjsypoeE3L/xS0Fe0VwZ+VF+XpGHbr+yv4G3e5A4UUusyb4bz7vIr3p3y1jvQ3uhQ4v3d19auYw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(377454003)(24454002)(199003)(189002)(101416001)(6306002)(236005)(54906002)(6512007)(54896002)(99286003)(97736004)(77096006)(6486002)(93886004)(6506006)(229853002)(6436002)(7736002)(83506001)(86362001)(606005)(68736007)(7906003)(25786008)(8656002)(122556002)(36756003)(50986999)(53936002)(8676002)(81166006)(5660300001)(2900100001)(2906002)(8936002)(102836003)(4326007)(81156014)(2950100002)(966004)(6116002)(3280700002)(3846002)(4001350100001)(66066001)(76176999)(54356999)(3660700001)(92566002)(106116001)(38730400002)(105586002)(106356001)(53546003)(6246003)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 866149e0-fbde-4faa-2d93-08d451e68a34 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 0214EB3F68 received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4C375192F85Fqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:56:36.7844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 18:56:41 -0000 --_000_D4C375192F85Fqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Kenny, From: "Paterson, Kenny" > Date: Friday, February 10, 2017 at 12:22 PM To: 'Quynh' >, Sean Turner = > Cc: IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Dear Quynh, On 10/02/2017 12:48, "Dang, Quynh (Fed)" > wrote: Hi Kenny, Hi, My preference is to go with the existing text, option a). >From the github discussion, I think option c) involves a less conservative security bound (success probability for IND-CPA attacker bounded by 2^{-32} instead of 2^{-60}). I can live with that, but the WG should be aware of the weaker security guarantees it provides. I do not understand option b). It seems to rely on an analysis of collisions of ciphertext blocks rather than the established security proof for AES-GCM. My suggestion was based on counting. I analyzed AES-GCM in TLS 1.3 as being a counter-mode encryption and each counter is a 96-bit nonce || 32-bit counter. I don=92t know if there is another kind of proof that is more precise than that. Thanks for explaining. I think, then, that what you are doing is (in effect) accounting for the PRP/PRF switching lemma that is used (in a standard way) as part of the IND-CPA security proof of AES-GCM. One can obtain a greater degree of precision by using the proven bounds for IND-CPA security of AES-GCM. These incorporate the "security loss" coming from the PRP/PRF switching lemma. The current best form of these bounds is due to Iwata et al.. This is precisely what we analyse in the note at http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see equations (5) - (7) on page 6 of that note. I reviewed the paper more than once. I highly value the work. I suggested t= o reference your paper in the text. I think the result in your paper is t= he same with what is being suggested when the collision probability allowed= is 2^(-32). Regards, Quynh. Regards, Kenny Regards, Quynh. --_000_D4C375192F85Fqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0020D91BE04D324A82B75F5B07AB0C36@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Dear Kenny, 


From: "Paterson, Kenny" &= lt;Kenny.Paterson@rhul.ac.uk>
Date: Friday, February 10, 2017 at = 12:22 PM
To: 'Quynh' <Quynh.Dang@nist.gov>, Sean Turner <sean@sn3rd.com>
Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ie= tf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Dear Quynh,

On 10/02/2017 12:48, "Dang, Quynh (Fed)" <quynh.dang@nist.gov> wrote:

Hi Kenny,

Hi,


My preference is to go with the existing text, option a).


From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should b= e
aware of the weaker security guarantees it provides.


I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.




My suggestion was based on counting.  I analyzed AES-GCM in = TLS 1.3  as
being a counter-mode encryption and each counter is a 96-bit nonce ||<= /div>
32-bit counter. I don=92t know if there is another kind of proof that = is
more precise than that.

Thanks for explaining. I think, then, that what you are doing is (in
effect) accounting for the PRP/PRF switching lemma that is used (in a<= /div>
standard way) as part of the IND-CPA security proof of AES-GCM. One ca= n
obtain a greater degree of precision by using the proven bounds for
IND-CPA security of AES-GCM. These incorporate the "security loss= " coming
from the PRP/PRF switching lemma. The current best form of these bound= s is
due to Iwata et al.. This is precisely what we analyse in the note at<= /div>
equations (5) - (7) on page 6 of that note.

I reviewed the paper more than once. I highly value the work. I sugges= ted to reference  your paper in the text.  I think the result in = your paper is the same with what is being suggested when the collision prob= ability allowed is 2^(-32).

Regards,
Quynh. 


Regards,

Kenny



Regards,
Quynh.


--_000_D4C375192F85Fqdangnistgov_-- From nobody Fri Feb 10 11:02: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 DC5E8129AA5 for ; Fri, 10 Feb 2017 11:02:24 -0800 (PST) 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=unavailable 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 ESasPf2QImsh for ; Fri, 10 Feb 2017 11:02:22 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 E12AB129AA8 for ; Fri, 10 Feb 2017 11:02:21 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id c7so39410852itd.1 for ; Fri, 10 Feb 2017 11:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=VshVjuaGnYDoLIfeWhr1N/FEJ4yP8/Y08IFsFVtMBwg=; b=Y+5OT/eleXl0i8kTpKj04UFZMK5me73C9inIIeC1IJ/YaIDIlY+s8lvXEGb9o+sUQM I+aLD0byMTNywUZDQ0wQjsSWXEyBfdid3O+J2ll8uEvPgozL6dhkLxHFQj+NMaPXFfrE 4W9WJfIYwnLwi+8mDSwcba9SMGVNtXZwyqHzbs7AmzxSV95J4lW4r+CKD19xmmZRvHel pJx4uLfHOVrKq6RylIBrms+jhe3uQvcBykN8z0FJspGeieKxvjwVvTA4IEwf0og6OlMP REuLbSI6hior9wp++lH5OeaVL1PhMWZuFpSJK/KXnv1HYKe3WmUwdXfCZPEnRDA3mphY N5XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=VshVjuaGnYDoLIfeWhr1N/FEJ4yP8/Y08IFsFVtMBwg=; b=f68AG15XNrZOq70yza9tf6mt4EnoNE01EAa/JEIE7KbEVrcvM/Zl+plKNRJ7zyeI6R QSmmt5bMeZ6iKXFfvmglUBYzWn9aJOL+4r5s5GrI+eHAl2x9jQXPFU+vJgf3/c7kIGAM FZPAejjpvISHlT4L+BJUWyWwb3v6Bd4xk5fXbL9gGnBhureHMsVEq7BCYCGdgE2wOYo2 iIRrPfjD49BbUbE6NXKJVWr+eRKmOEU9OJcCKK/kxB6YIbuvzL1VJ4fgeZCitAxp1DiT 2A47+XbpEvcOCC80obW0nbUFJwjuRnaiWcG5f2AjXN7iLINzJWto78JiaEQVcGVcZVPa UINw== X-Gm-Message-State: AMke39kD6QyLPWADgjUxfL6vu91INErdLl6qUBtMkz1Y6BpuPyr15z763TEVBI4Fw2Upfw== X-Received: by 10.36.217.150 with SMTP id p144mr10276224itg.90.1486753341219; Fri, 10 Feb 2017 11:02:21 -0800 (PST) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id v85sm1367421iov.34.2017.02.10.11.02.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 11:02:20 -0800 (PST) To: "Dang, Quynh (Fed)" , Sean Turner , "" References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> From: Rene Struik Message-ID: <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com> Date: Fri, 10 Feb 2017 14:02:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F0B747543E16567D336E241B" Archived-At: Cc: IRTF CFRG Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:02:25 -0000 This is a multi-part message in MIME format. --------------F0B747543E16567D336E241B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Quynh: Not sure where to start (there is vast literature on side channel attacks and other implementation attacks). A good starting point would be the book [1], but one could also look at some NIST publications [2]. Side channel attacks differs from cryptanalytic attacks in that it does not merely study I/O behavior of crypto contructs, but also looks into what information can be obtained from what is going on "under the hood" of the computations (power consumption, radiation, timing, etc; or even invasive attacks). Most commonly one looks at crypto building blocks, but ultimately side channels can comprise any system behavior ("Lucky13" does, e.g., exploit this, if I remember correctly). From the last page of [2]: Finally, the most important conclusion from this paper is that it is not only a necessity but also a must, in the coming version of FIPS 140-3 standard, to evaluate cryptographic modules for their resistivity against SCA attacks. Ref: [1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks - Revealing the Secrets of Smart Cards", Springer, 2007. [2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf [2] On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote: > Hi Rene, > > From: TLS > on > behalf of Rene Struik > > Date: Friday, February 10, 2017 at 10:51 AM > To: Sean Turner >, > ">" > > Cc: IRTF CFRG > > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs > (#765/#769) > > Dear colleagues: > > I would suggest adding the following paragraph at the end of > Section 5.5: > > [current text of Section 5.5] > > There are cryptographic limits on the amount of plaintext which > can be safely encrypted under a given set of keys.[AEAD-LIMITS] > provides an > analysis of these limits under the assumption that the underlying > primitive (AES or ChaCha20) has no weaknesses. Implementations > SHOULD do a key updateSection 4.6.3 > prior to reaching > these limits. > > For AES-GCM, up to 2^24.5 full-size records (about 24 million) may > be encrypted on a given connection while keeping a safety margin > of approximately 2^-57 for Authenticated Encryption (AE) security. > For ChaCha20/Poly1305, the record sequence number would wrap > before the safety limit is reached. > > [suggested additional text] > > The above upper limits do not take into account potential side > channel attacks, which - in some implementations - have been shown > to be successful at recovering keying material with a relatively > small number of messages encrypted using the same key. While > results are highly implementation-specific, thereby making it hard > to provide precise guidance, prudence suggests that > implementations should not reuse keys ad infinitum. > Implementations SHALL therefore always implement the key update > mechanism of Section 4.6.3. > > {editorial note: perhaps, one should impose the limit 2^20, just > to make sure people do not "forget" to implement key updates?} > > > How do you do side channel attacks on TLS ? Do these side-channel > attacks work for AES-GCM only in TLS 1.3 ? > > > > > See also my email of August 29, 2016: > https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno > > On 2/10/2017 12:07 AM, Sean Turner wrote: >> All, >> >> Weve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 Limits on Key Usage. As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to: >> >> a) Close these two PRs and go with the existing text [0] >> b) Adopt PR#765 [1] >> c) Adopt PR#769 [2] >> >> Please indicate you preference to the TLS mailing list before Feb 17. Note that unless theres clear consensus to change the text will remain as is (i.e., option a). >> >> J&S >> >> [0]https://tlswg.github.io/tls13-spec/#rfc.section.5.5 >> [1]https://github.com/tlswg/tls13-spec/pull/765 >> [2]https://github.com/tlswg/tls13-spec/pull/769 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------F0B747543E16567D336E241B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Quynh:

Not sure where to start (there is vast literature on side channel attacks and other implementation attacks). A good starting point would be the book [1], but one could also look at some NIST publications [2].

Side channel attacks differs from cryptanalytic attacks in that it does not merely study I/O behavior of crypto contructs, but also looks into what information can be obtained from what is going on "under the hood" of the computations (power consumption, radiation, timing, etc; or even invasive attacks). Most commonly one looks at crypto building blocks, but ultimately side channels can comprise any system behavior ("Lucky13" does, e.g., exploit this, if I remember correctly).

From the last page of [2]: Finally, the most important conclusion from this paper is that it is not only a necessity but also a must, in the coming version of FIPS 140-3 standard, to evaluate cryptographic modules for their resistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
Hi Rene,

From: TLS <tls-bounces@ietf.org> on behalf of Rene Struik <rstruik.ext@gmail.com>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.[AEAD-LIMITS]provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key updateSection 4.6.3prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel attacks, which - in some implementations - have been shown to be successful at recovering keying material with a relatively small number of messages encrypted using the same key. While results are highly implementation-specific, thereby making it hard to provide precise guidance, prudence suggests that implementations should not reuse keys ad infinitum. Implementations SHALL therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks work for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:
All,

Weve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 Limits on Key Usage.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless theres clear consensus to change the text will remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
 


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------F0B747543E16567D336E241B-- From nobody Fri Feb 10 11:06: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 8B729129AB1 for ; Fri, 10 Feb 2017 11:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 Ze_0SneiQsu0 for ; Fri, 10 Feb 2017 11:06:49 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00042.outbound.protection.outlook.com [40.107.0.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA0A129AAE for ; Fri, 10 Feb 2017 11:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6OzyjzLP4WJShn+EviFTB8rJm0DEwLTxO2uFz5XZZS0=; b=1zdo3QaGqbYnRrcryKHpxTeOkIhLmDQFmtVn1btWMH8+5HEa6UYwmo7bO6dKkxM34MQycERnT5BN0WAwK1+wPv3sLM0nNnRgqKSouiLVkJIGGC8kNXVxVpfXH8otgqvUvAh4b8J+mzc1srwYzdnjeeBN/bHZQ8FY1Z+phN4AgJ4= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 19:06:47 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 19:06:46 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , Sean Turner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koCAAD3QgIAATPYAgAAZ1gCAAANQAA== Date: Fri, 10 Feb 2017 19:06:46 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:H/2lUTPrOyXAtY+2gLqUbtqRo8ML8FVIXma7sQleAuLcnRtHgmC90Z2z7yevEPa5rw3/XAMiNyf/covmUzwxSub9T8Rr5hI+zly/1c8VUD+vSnRi0U4Rt2U42ki6nyBq83knbJ8PrwQCTbu0RQNperZgQlGNdN/8PeBZlgFriX5Ww2ggNriAG9WG8Hmq2dZtKhEIujZmV5XN8sQm29zNEZHHnRrmFS/CXRZZDUh28hypBk2cvA0S5Yvw6QQYk6QFYC4eVKOdFy93AQrXuH7SXfFGlmz68BSS5iSPqcyvPbPhcW0i8tKCMVQDMmsRtiCpvo4MlZwgiMUFbgGb8c3eHpwNvwLlmllTIeUongbj50L4wc/PlO5FJ8xvKPzFlitBEMEcdPYEf6eODOxnJsLINGDhkwY1xvVPoWS69yBuWQ3gX4diPuGAnHw1xc25jFfAb+CempBL2B04FRZIZMdJQqNPwlFnhV7txiUHBi+bTB5s/p9E7B2oQNQtn7keOGrYOdOR5MnIFeBW82aTvdXOIg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(199003)(24454002)(189002)(42882006)(2900100001)(36756003)(2950100002)(7736002)(68736007)(122556002)(92566002)(189998001)(99286003)(4326007)(8656002)(25786008)(38730400002)(3280700002)(3660700001)(2906002)(6436002)(102836003)(6116002)(229853002)(3846002)(6506006)(6512007)(6306002)(50986999)(54356999)(101416001)(54906002)(76176999)(6486002)(83506001)(77096006)(81166006)(81156014)(86362001)(53936002)(66066001)(8936002)(105586002)(106356001)(8676002)(74482002)(106116001)(97736004)(305945005)(4001350100001)(5660300001)(93886004)(53546003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: c22cc956-a16e-4a46-fb30-08d451e7f5c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1905; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; x-forefront-prvs: 0214EB3F68 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6FFCA153BE3F9A48827B06F167E1D928@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 19:06:46.7423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:06:52 -0000 SGksDQoNCk9uIDEwLzAyLzIwMTcgMTg6NTYsICJEYW5nLCBRdXluaCAoRmVkKSIgPHF1eW5oLmRh bmdAbmlzdC5nb3Y+IHdyb3RlOg0KDQo+RGVhciBLZW5ueSwgDQo+DQo+RnJvbTogIlBhdGVyc29u LCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+DQo+RGF0ZTogRnJpZGF5LCBGZWJy dWFyeSAxMCwgMjAxNyBhdCAxMjoyMiBQTQ0KPlRvOiAnUXV5bmgnIDxRdXluaC5EYW5nQG5pc3Qu Z292PiwgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPg0KPkNjOiBJUlRGIENGUkcgPGNmcmdA aXJ0Zi5vcmc+LCAiPHRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc+DQo+U3ViamVjdDogUmU6 IFtUTFNdIFtDZnJnXSBDbG9zaW5nIG91dCB0bHMxLjMgIkxpbWl0cyBvbiBrZXkgdXNhZ2UiIFBS cw0KPigjNzY1LyM3NjkpDQo+DQo+DQo+DQo+PkRlYXIgUXV5bmgsDQo+Pg0KPj4NCj4+T24gMTAv MDIvMjAxNyAxMjo0OCwgIkRhbmcsIFF1eW5oIChGZWQpIiA8cXV5bmguZGFuZ0BuaXN0Lmdvdj4g d3JvdGU6DQo+Pg0KPj4NCj4+PkhpIEtlbm55LCANCj4+Pg0KPj4+DQo+Pj4+SGksDQo+Pj4+DQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+TXkgcHJlZmVyZW5jZSBpcyB0byBnbyB3aXRoIHRoZSBleGlz dGluZyB0ZXh0LCBvcHRpb24gYSkuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+RnJvbSB0 aGUgZ2l0aHViIGRpc2N1c3Npb24sIEkgdGhpbmsgb3B0aW9uIGMpIGludm9sdmVzIGEgbGVzcw0K Pj4+PmNvbnNlcnZhdGl2ZQ0KPj4+PnNlY3VyaXR5IGJvdW5kIChzdWNjZXNzIHByb2JhYmlsaXR5 IGZvciBJTkQtQ1BBIGF0dGFja2VyIGJvdW5kZWQgYnkNCj4+Pj4yXnstMzJ9IGluc3RlYWQgb2Yg Ml57LTYwfSkuIEkgY2FuIGxpdmUgd2l0aCB0aGF0LCBidXQgdGhlIFdHIHNob3VsZCBiZQ0KPj4+ PmF3YXJlIG9mIHRoZSB3ZWFrZXIgc2VjdXJpdHkgZ3VhcmFudGVlcyBpdCBwcm92aWRlcy4NCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj5JIGRvIG5vdCB1bmRlcnN0YW5kIG9wdGlvbiBiKS4g SXQgc2VlbXMgdG8gcmVseSBvbiBhbiBhbmFseXNpcyBvZg0KPj4+PmNvbGxpc2lvbnMgb2YgY2lw aGVydGV4dCBibG9ja3MgcmF0aGVyIHRoYW4gdGhlIGVzdGFibGlzaGVkIHNlY3VyaXR5DQo+Pj4+ cHJvb2YNCj4+Pj5mb3IgQUVTLUdDTS4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+ DQo+Pj4NCj4+Pg0KPj4+TXkgc3VnZ2VzdGlvbiB3YXMgYmFzZWQgb24gY291bnRpbmcuICBJIGFu YWx5emVkIEFFUy1HQ00gaW4gVExTIDEuMyAgYXMNCj4+PmJlaW5nIGEgY291bnRlci1tb2RlIGVu Y3J5cHRpb24gYW5kIGVhY2ggY291bnRlciBpcyBhIDk2LWJpdCBub25jZSB8fA0KPj4+MzItYml0 IGNvdW50ZXIuIEkgZG9u4oCZdCBrbm93IGlmIHRoZXJlIGlzIGFub3RoZXIga2luZCBvZiBwcm9v ZiB0aGF0IGlzDQo+Pj5tb3JlIHByZWNpc2UgdGhhbiB0aGF0Lg0KPj4NCj4+DQo+PlRoYW5rcyBm b3IgZXhwbGFpbmluZy4gSSB0aGluaywgdGhlbiwgdGhhdCB3aGF0IHlvdSBhcmUgZG9pbmcgaXMg KGluDQo+PmVmZmVjdCkgYWNjb3VudGluZyBmb3IgdGhlIFBSUC9QUkYgc3dpdGNoaW5nIGxlbW1h IHRoYXQgaXMgdXNlZCAoaW4gYQ0KPj5zdGFuZGFyZCB3YXkpIGFzIHBhcnQgb2YgdGhlIElORC1D UEEgc2VjdXJpdHkgcHJvb2Ygb2YgQUVTLUdDTS4gT25lIGNhbg0KPj5vYnRhaW4gYSBncmVhdGVy IGRlZ3JlZSBvZiBwcmVjaXNpb24gYnkgdXNpbmcgdGhlIHByb3ZlbiBib3VuZHMgZm9yDQo+PklO RC1DUEEgc2VjdXJpdHkgb2YgQUVTLUdDTS4gVGhlc2UgaW5jb3Jwb3JhdGUgdGhlICJzZWN1cml0 eSBsb3NzIiBjb21pbmcNCj4+ZnJvbSB0aGUgUFJQL1BSRiBzd2l0Y2hpbmcgbGVtbWEuIFRoZSBj dXJyZW50IGJlc3QgZm9ybSBvZiB0aGVzZSBib3VuZHMNCj4+aXMNCj4+ZHVlIHRvIEl3YXRhIGV0 IGFsLi4gVGhpcyBpcyBwcmVjaXNlbHkgd2hhdCB3ZSBhbmFseXNlIGluIHRoZSBub3RlIGF0DQo+ Pmh0dHA6Ly93d3cuaXNnLnJodWwuYWMudWsvfmtwL1RMUy1BRWJvdW5kcy5wZGYgLSBzcGVjaWZp Y2FsbHksIHNlZQ0KPj5lcXVhdGlvbnMgKDUpIC0gKDcpIG9uIHBhZ2UgNiBvZiB0aGF0IG5vdGUu DQo+Pg0KPg0KPkkgcmV2aWV3ZWQgdGhlIHBhcGVyIG1vcmUgdGhhbiBvbmNlLiBJIGhpZ2hseSB2 YWx1ZSB0aGUgd29yay4gSSBzdWdnZXN0ZWQNCj50byByZWZlcmVuY2UgIHlvdXIgcGFwZXIgaW4g dGhlIHRleHQuICBJIHRoaW5rIHRoZSByZXN1bHQgaW4geW91ciBwYXBlcg0KPmlzIHRoZSBzYW1l IHdpdGggd2hhdCBpcyBiZWluZyBzdWdnZXN0ZWQgd2hlbiB0aGUgY29sbGlzaW9uIHByb2JhYmls aXR5DQo+YWxsb3dlZCBpcyAyXigtMzIpLg0KDQpUaGFua3MgZm9yIHRoaXMgZmVlZGJhY2suIEkg Z3Vlc3MgbXkgY29uZnVzaW9uIGFyaXNlcyBmcm9tIHdvbmRlcmluZyB3aGF0DQp5b3UgbWVhbiBi eSBjb2xsaXNpb24gcHJvYmFiaWxpdHkgYW5kIHdoeSB5b3UgY2FyZSBhYm91dCBpdC4gVGhlcmUg YXJlIG5vDQpjb2xsaXNpb25zIGluIHRoZSBibG9jayBjaXBoZXIncyBvdXRwdXRzIHBlciBzZSwg YmVjYXVzZSBBRVMgaXMgYQ0KcGVybXV0YXRpb24gZm9yIGVhY2ggY2hvaWNlIG9mIGtleS4gQW5k IGNvbGxpc2lvbnMgaW4gdGhlIGNpcGhlcnRleHQNCmJsb2NrcyBvdXRwdXQgYnkgQUVTLUdDTSBh cmUgaXJyZWxldmFudCB0byBpdHMgZm9ybWFsIHNlY3VyaXR5IGFuYWx5c2lzLg0KDQpPbiB0aGUg b3RoZXIgaGFuZCwgd2hlbiBpbiB0aGUgcHJvb2Ygb2YgSU5ELUNQQSBzZWN1cml0eSBvZiBBRVMt R0NNIG9uZQ0Kc3dpdGNoZXMgZnJvbSBhIHJhbmRvbSBwZXJtdXRhdGlvbiAod2hpY2ggaXMgaG93 IHdlIG1vZGVsIEFFUykgdG8gYSByYW5kb20NCmZ1bmN0aW9uICh3aGljaCBpcyB3aGF0IHdlIG5l ZWQgdG8gYXJndWUgaW4gdGhlIGVuZCB0aGF0IHRoZSBwbGFpbnRleHQgaXMNCm1hc2tlZCBieSBh IG9uZS10aW1lIHBhZCwgZ2l2aW5nIGluZGlzdGluZ3Vpc2hhYmlsaXR5KSwgdGhlbiBvbmUgbmVl ZHMgdG8NCmRlYWwgd2l0aCB0aGUgcHJvYmFiaWxpdHkgdGhhdCBjb2xsaXNpb25zIG9jY3VyIGlu IHRoZSBmdW5jdGlvbidzIG91dHB1dHMNCmJ1dCBub3QgaW4gdGhlIHBlcm11dGF0aW9uJ3MuIFRo aXMgZW5kcyB1cCBiZWluZyB0aGUgbWFpbiBjb250cmlidXRpb24gdG8NCnRoZSBzZWN1cml0eSBi b3VuZCBpbiB0aGUgcHJvb2YgZm9yIElORC1DUEEgc2VjdXJpdHkuDQoNCklzIHRoYXQgd2hhdCB5 b3UgYXJlIGdldHRpbmcgYXQ/DQoNCklmIHNvLCB0aGVuIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdl LCBhbmQgd2hhdCByZW1haW5zIGlzIHRvIGRlY2lkZSB3aGV0aGVyDQphIDJeey0zMn0gYm91bmQg aXMgYSBnb29kIGVub3VnaCBzZWN1cml0eSBtYXJnaW4uDQoNClJlZ2FyZHMsDQoNCktlbm55DQoN Cg0K From nobody Fri Feb 10 11:36: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 69F06129B26 for ; Fri, 10 Feb 2017 11:36:32 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=nistgov.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 MvlUxW6dXgcB for ; Fri, 10 Feb 2017 11:36:29 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0136.outbound.protection.outlook.com [23.103.201.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 5732C129B25 for ; Fri, 10 Feb 2017 11:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/RC4K1ufqEUjFKfO3hV6JxqyREy5B+X+4Ap5X2ylSOE=; b=tb0AR19uLfrFkx+ChxBNK7ffOPlFEiPO9rRKvw1oLlzShMWaS0lmf2f05XngUCQ8K5zG9+ucIKVzFJcN96/jWTDmCuquLMylpjGnjPy16CmrU/MSZzYb3CnoRIl47GptwKwqgTBhtaN1qjsbxe1tYr015a66kGBi0KyUsQPdDeQ= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 19:36:27 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 19:36:27 +0000 From: "Dang, Quynh (Fed)" To: Rene Struik , Sean Turner , "" Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg84y+88vw5exDE6fOqGEW6ep0KFimMQAgAAIvxk= Date: Fri, 10 Feb 2017 19:36:27 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> , <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com> In-Reply-To: <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: af8743ad-29f3-4eb2-9bad-08d451ec1b1a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:Tvmz1I9smEOm634E2dtS/81MKf6JD46qJvRc18qtWl4vLJGdx5K2mrUpOLTzRH+s8Y9AQZrBdRmovUFkIm7RBv/VybzvDclEDzGQC1FgRmUlSKw47BH89xakgL95d4hwrXHtV3aMDQOV0JCfLjA6nh55TgyHq/fcLHVjtoJ7KiPzTFSH0wxZR4c9VMPJYNQ41XAVILS/SjlqvyawGzCrJsGvlWoKJ40ybni1Io5ehLnCTLVfLAz1bVzMZFzMpvehOvX/WusZuzTU9ILUymhU+fMtXDTjHB2zK5j+GctlBPieX7/Kel+44hON2aC6SOzf5PDZ1NQS83jnUbWXyfo0SjlOZdYVJi/8H/MKmXVXIFiiDLRAj+7ExeAPCycWlHyFAF8j+t+akG0qfBcL609eEs+yM/7+HtK7QPJne7iqcSf81akTh8oZURrODJHjcpS9garZ6BvY4bHXrFsX4/ysdCL7YnQgc3uPDmmenVBGvHvxjfGNdJ1DOheBvj6nV3fpUeV+RX3N4yXhCRtjnIw4Gw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(166708455590820)(100405760836317)(131022147185803); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(199003)(24454002)(377454003)(189002)(86362001)(122556002)(575784001)(50986999)(66066001)(54356999)(3280700002)(76176999)(189998001)(3660700001)(4326007)(68736007)(2906002)(2900100001)(81166006)(81156014)(38730400002)(7906003)(8936002)(16297215004)(39060400001)(74316002)(8676002)(7736002)(106356001)(105586002)(6246003)(53546003)(106116001)(19627405001)(3846002)(7696004)(92566002)(77096006)(229853002)(6436002)(2950100002)(966004)(5660300001)(9686003)(99286003)(102836003)(93886004)(55016002)(325944008)(33656002)(97736004)(101416001)(236005)(606005)(54896002)(25786008)(6116002)(6506006)(6306002)(53936002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 19:36:27.3491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: IRTF CFRG Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:36:32 -0000 --_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Rene, I care about side channel attacks in general as much as you do. But my ques= tion was that how you carry out those attacks on GCM in TLS 1.3's servers a= nd clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 ? Quynh. ________________________________ From: Rene Struik Sent: Friday, February 10, 2017 2:02:14 PM To: Dang, Quynh (Fed); Sean Turner; Cc: IRTF CFRG Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Hi Quynh: Not sure where to start (there is vast literature on side channel attacks a= nd other implementation attacks). A good starting point would be the book [= 1], but one could also look at some NIST publications [2]. Side channel attacks differs from cryptanalytic attacks in that it does not= merely study I/O behavior of crypto contructs, but also looks into what in= formation can be obtained from what is going on "under the hood" of the com= putations (power consumption, radiation, timing, etc; or even invasive atta= cks). Most commonly one looks at crypto building blocks, but ultimately sid= e channels can comprise any system behavior ("Lucky13" does, e.g., exploit = this, if I remember correctly). >From the last page of [2]: Finally, the most important conclusion from this= paper is that it is not only a necessity but also a must, in the coming ve= rsion of FIPS 140-3 standard, to evaluate cryptographic modules for their r= esistivity against SCA attacks. Ref: [1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks = - Revealing the Secrets of Smart Cards", Springer, 2007. [2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/= physecpaper19.pdf [2] On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote: Hi Rene, From: TLS > on behalf of = Rene Struik > Date: Friday, February 10, 2017 at 10:51 AM To: Sean Turner >, ">" > Cc: IRTF CFRG > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Dear colleagues: I would suggest adding the following paragraph at the end of Section 5.5: [current text of Section 5.5] There are cryptographic limits on the amount of plaintext which can be safe= ly encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the = assumption that the underlying primitive (AES or ChaCha20) has no weaknesse= s. Implementations SHOULD do a key update Section 4.6.3 prior to reaching these limits. For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry= pted on a given connection while keeping a safety margin of approximately 2= ^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the= record sequence number would wrap before the safety limit is reached. [suggested additional text] The above upper limits do not take into account potential side channel atta= cks, which - in some implementations - have been shown to be successful at = recovering keying material with a relatively small number of messages encry= pted using the same key. While results are highly implementation-specific, = thereby making it hard to provide precise guidance, prudence suggests that = implementations should not reuse keys ad infinitum. Implementations SHALL t= herefore always implement the key update mechanism of Section 4.6.3. {editorial note: perhaps, one should impose the limit 2^20, just to make su= re people do not "forget" to implement key updates?} How do you do side channel attacks on TLS ? Do these side-channel attacks w= ork for AES-GCM only in TLS 1.3 ? See also my email of August 29, 2016: https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno On 2/10/2017 12:07 AM, Sean Turner wrote: All, We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1= 3 Section 5.5 =93Limits on Key Usage=94. As it relates to rekeying, these = limits have been discussed a couple of times and we need to resolve once an= d for all whether the TLS WG wants to: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] Please indicate you preference to the TLS mailing list before Feb 17. Note= that unless there=92s clear consensus to change the text will remain as is= (i.e., option a). J&S [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 [1] https://github.com/tlswg/tls13-spec/pull/765 [2] https://github.com/tlswg/tls13-spec/pull/769 _______________________________________________ Cfrg mailing list Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cf= rg -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Rene,


I care about side channel attacks in general as much as you do. But my q= uestion was that how you carry out those attacks on GCM in TLS 1.3's server= s and clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 = ?


Quynh. 

From: Rene Struik <rstru= ik.ext@gmail.com>
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner; <tls@ietf.org>
Cc: IRTF CFRG
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usa= ge" PRs (#765/#769)
 
Hi Quynh:

Not sure where to start (there is vast literature on side channel attacks a= nd other implementation attacks). A good starting point would be the book [= 1], but one could also look at some NIST publications [2].

Side channel attacks differs from cryptanalytic attacks in that it does not= merely study I/O behavior of crypto contructs, but also looks into what in= formation can be obtained from what is going on "under the hood" = of the computations (power consumption, radiation, timing, etc; or even invasive attacks). Most commonly one looks at crypto = building blocks, but ultimately side channels can comprise any system behav= ior ("Lucky13" does, e.g., exploit this, if I remember correctly)= .

>From the last page of [2]: Finally, the most important conclusion from this= paper is that it is not only a necessity but also a must, in the coming ve= rsion of FIPS 140-3 standard, to evaluate cryptographic modules for their r= esistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Att= acks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/phys= ecpaper19.pdf
[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
Hi Rene, 

From: TLS <tls-bounces@ietf.org> on= behalf of Rene Struik <rstruik.ext@gmail.com>
Date: Friday, February 10, 2017 at = 10:51 AM
To: Sean Turner <sean@sn3rd.com>, "&= lt;tls@ietf.org>" <tl= s@ietf.org>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:
[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be safe= ly encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primi= tive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key u= pdate Section 4.6.3 prior to reach= ing these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry= pted on a given connection while keeping a safety margin of approximately 2= ^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the= record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel atta= cks, which - in some implementations - have been shown to be successful at = recovering keying material with a relatively small number of messages encry= pted using the same key. While results are highly implementation-specific, thereby making it hard to provide prec= ise guidance, prudence suggests that implementations should not reuse keys = ad infinitum. Implementations SHALL therefore always implement the key upda= te mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make su= re people do not "forget" to implement key updates?}  

How do you do side channel attacks on TLS ? Do these side-channel atta= cks work for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://ma= ilarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:
All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/t=
ls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-s=
pec/pull/765
[2] https://github.com/tlswg/tls13-s=
pec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghtt=
ps://www.irtf.org/mailman/listinfo/cfrg


--=20
email: rstruik.ext@gmail.com | Skype: rstrui=
k
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_-- From nobody Fri Feb 10 11:46: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 0D1E9129B4F for ; Fri, 10 Feb 2017 11:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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_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 Tfmef1LqytNl for ; Fri, 10 Feb 2017 11:46:15 -0800 (PST) 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 0548D1295A2 for ; Fri, 10 Feb 2017 11:46:02 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id u63so8822240wmu.2 for ; Fri, 10 Feb 2017 11:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-transfer-encoding; bh=noDM03/wEekilj90zT74tC8Q65xf4s1+0C//2aP4PjM=; b=P2jN0Sc9SQUxcLvOtdVFgkl4Km4WSDPyXO4BBpTiFcwWysqAhmjNV++g9BMO78+w7f xNSto+DINkqVM5me0Fn6dncTFHGBmnrw2MRaKD8SPBK5Hfie7MNVgZifXOFECx3NWBH+ YbppTRUDD04mwwFTRSHBSb5TKdqeKvuKN/tXFCVCt6dH/ybCNtNwXZifLPjShGMBnnp0 SOdRlSjhI61y9TQw37rRGSWIOvB8hZjc6FuBdr9eJjtPfe7Vyovdjlt9jUbUMFHj8zxK 9N9r8pJpH/lSCdPMONFrCgsbkb2/8JE9w9zcE4rlPntK6ho/q/CxTFHz2BgGJva0X23q llUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=noDM03/wEekilj90zT74tC8Q65xf4s1+0C//2aP4PjM=; b=J9qldFmIunMAXl8C9ZnCjo/fXDnC7GdmAC/RvxtKscRKmXG5N3HlIRsKD2Ielt/QBf 1JrdXkqcltvYMdIDyTl3uZoPI+La6kUXTulLXE6SpM5mhISt7KCRjsnCKIx+mK2/0aUJ /C9IEcxTdb8thHd55oSbtTDFjQ7fEeBlQpKC4K2PZLAU4RIe7u37MXTn6XzwBT1bsuXM jZrugTogimmpYKcsRdZSHZetnxiUYG/TXxU5teScZ4SNEHNERraIrB4V4RNOHrZ5c8Fh g0b3eSGqEbuVXoiDokmkidOkPffL1Qpsy4Dh1TB8VjtePkmdgl3zJgynSk/XOsvbux9i 1oPg== X-Gm-Message-State: AMke39nsZi24nm+fd0tmRcDbayXm8ZD8fYK6vSJsmabD7oWiA5aNC0ePI7bi5qD69k5+pg== X-Received: by 10.28.38.2 with SMTP id m2mr27410639wmm.44.1486755960285; Fri, 10 Feb 2017 11:46:00 -0800 (PST) Received: from ?IPv6:2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149? ([2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149]) by smtp.gmail.com with ESMTPSA id u184sm909201wmb.29.2017.02.10.11.45.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 11:45:59 -0800 (PST) To: Ilari Liusvaara References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Sam Scott Message-ID: Date: Fri, 10 Feb 2017 19:45:58 +0000 MIME-Version: 1.0 In-Reply-To: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:46:23 -0000 Hi Ilari, Thanks for the comments. Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues. In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake. However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message). The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys. This can be strengthened if the client's updated write key is computed using the authentication messages. We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this. Thanks, Sam From nobody Fri Feb 10 11: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 ABD45129B52 for ; Fri, 10 Feb 2017 11:54:34 -0800 (PST) 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_H4=-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 6nRFbzsdiY2r for ; Fri, 10 Feb 2017 11:54:32 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0101.outbound.protection.outlook.com [104.47.37.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 972FD129B39 for ; Fri, 10 Feb 2017 11:54:32 -0800 (PST) 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=o7yrln82KSQITuVECL8uRkuwFq/vXWb7vrN5gfhW7PU=; b=MySpjJvvgJBft1hcL1TD+2L2xcX99vANHL7JB2OxzWd3nNlYV4eljOGiOPze+0pduV5ACTuxyOUubHItzyEljCDmM5ZabEt1lZ8QwXYY9UUVL1IitAML36KQSFOqMsuduN966K09fMUY07j7yftXw6oj8MQ/GKhWdZtO08+amFs= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 19:54:30 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 19:54:30 +0000 From: Andrei Popov To: Sam Scott , Ilari Liusvaara Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 Thread-Index: AQHSg5t3h43MYmEytkO14a3ComoThqFifUUAgAAoHQCAAAGI0A== Date: Fri, 10 Feb 2017 19:54:30 +0000 Message-ID: References: <20170210172224.GA22473@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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 69e6dd79-defa-4316-e9d1-08d451eea0bf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:JdOJJVdTxyzgdegRUakq/ZCbSovaugOW8P3SsRSZ5M7mtwd4CBnoTAK8QjwZ8IEgaUG91LTnK4xZjlXQEBpzjqjg17lzc5z4QlxXNVlGy270WVTrqPxQ3xuB7OnFx+qw2Y5S1FgvrDXgLnCCDlOAL+p0Q0nQ5tNME3nHemeCylVldE7SbkL2dY8vrM4+uEFock1xQnl/bSSy7wUP2j0/K03wcrkTowM/OmHbWd0igFc/wpTfgpUf58RGzsvyTkna97GJt8cYrF37FoP2Wh6caE2LWfYKUKLUx0hkH1s5WgO6K84i7X89PdnD4tHg6CJuChcN7k17vrIZmpxekeLVGvq667OMtil6YsasCP2jPKJsmRmjxEuawRbTPXfPpnn9SUiIEa2w5VSMXuZQIMdznkspPZNmq7+NbHrTZhh5TfRvHagGqDo726T77GwVE5yBZ/2giVpFfpUlqN6WH55aQqiYP+xffbOkerrzOBnTZwTh16ZHb+nC0Uw1/Hh3bISIwSrKZBuqmDWMWUhUCHv4d3IljB4pnQ7ceAGWA/uBivs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(6042181); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(13464003)(51914003)(4326007)(229853002)(106116001)(105586002)(106356001)(76176999)(54356999)(122556002)(74316002)(6116002)(86362001)(2950100002)(2906002)(7736002)(50986999)(189998001)(53936002)(7696004)(97736004)(305945005)(102836003)(81156014)(86612001)(101416001)(33656002)(5005710100001)(10090500001)(8990500004)(10290500002)(5660300001)(6436002)(81166006)(8936002)(3280700002)(55016002)(6506006)(3660700001)(39060400001)(77096006)(38730400002)(6306002)(6246003)(8676002)(9686003)(25786008)(2900100001)(68736007)(99286003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 10 Feb 2017 19:54:30.4478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:54:35 -0000 Hi Sam, This part is not clear to me: > ...while in the post-handshake client auth, an attacker can decide this (= by dropping the message). How does the attacker drop a TLS-protected message without terminating the = connection? Thanks, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sam Scott Sent: Friday, February 10, 2017 11:46 AM To: Ilari Liusvaara Cc: tls@ietf.org Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server vi= ew on client authentication in post-handshake mode in Revision 18 Hi Ilari, Thanks for the comments. Assuming the client sends a valid certificate that the server accepts, then= the server cannot finish the handshake or begin processing incoming applic= ation data until authenticating the client. This *almost* gives us property= (A). In practice, the client is aware that the server has successfully aut= henticated since the protocol continues. In the case that the server has implemented the reject option (rejecting a = certificate but still continuing), and indeed rejects the certificate, then= the server should send an alert message (or NAK of some form) for the prop= erty to hold in the initial handshake. However, even if we take the certificate reject + continue scenario into ac= count for the initial handshake, then it is clear that this decision can on= ly be made by the server in the initial handshake, while in the post-handsh= ake client auth, an attacker can decide this (by dropping the message). The reason we don't believe an explicit ACK is needed is because upgrading = to a new pair of keys explicitly provides this. Specifically, the client wi= ll send all subsequent data to the server under a new key.=20 The server will not be able to decrypt this data until they receive the cli= ent authentication messages and upgrade the keys. This can be strengthened if the client's updated write key is computed usin= g the authentication messages. We agree that TLS enforcing ordering of messages provides similar guarantee= s. However, we are analysing the specification as it is presented, which do= es not guarantee this. Thanks, Sam _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 10 12:31: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 BB06612959C for ; Fri, 10 Feb 2017 12:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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_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 6eI9xMLLvi5c for ; Fri, 10 Feb 2017 12:31:12 -0800 (PST) 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 C4E9F12943A for ; Fri, 10 Feb 2017 12:31:11 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id c85so8967364wmi.1 for ; Fri, 10 Feb 2017 12:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-transfer-encoding; bh=VQRevXcxeFCkM2ckGy431aGI5umZrZrpJHl0q3uml4I=; b=On7AyRNOpqIBxJcAyDy9UtINzVyLDM+fAyo1dlDyHHoCAltvba7sLtfOwbuKL1Cjnq 2sf9a+21XKX3jfh2u51na4ZvUi25DECd/EYb00g00P9BuZX2vK/ubI+dHv48vswWJVF6 59v/8rf8brOfjNM28UPit8OzG30kXZib4ymYexgU5izrGOzCmYY+e8LM8KGTM9YVqgv2 O4c6qiLaOIfWEU0eGvMkpUTuwB1SiiAOAn60z2JnA2e0U0Hfnq2zZtvFp0kLCGAjZ3b8 wGm74X4TKmQI/fhbzvUK9Bb1Q3vB4/5dhiwmwKVgrSZEn+o+FS5qXhbbVrCPCAeZAvS5 jkvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=VQRevXcxeFCkM2ckGy431aGI5umZrZrpJHl0q3uml4I=; b=ZzLFK2sGiHLSTZUWg4VBUVseEZoIZjbUvitWNhM9pyiCceHMHRoaPnKhcXGjpZwLFg Rg1+CX0PcnUurbuHytze85qD2E97HSsEHNoddcAm/ZwmdZcYP0JcujbP4p+6c3FluNwW p4o5ZbuW5MazWgaBFX/GyAs2KkvtQVySI19Adk7oSMcMZYcfgZ+2dlfqAilCCvir2KLh qjrE1E+fX0ve3PWTyXjIz4TggcXxhKYlW5LU1VUSDOUo6nRpVFlghMI/scbbeGV7MiVr q0oUA0QFwazWDGI0nkPVad60KZ+Gkquv0OvgsS3o8am/YD866Bf13cstyJbwC6Ele0AV 9c4A== X-Gm-Message-State: AMke39mNZ0lIAvm78grEhpzTTSLK8/r7vzIHSdqEUhJp2/WGx7u8andeJS5d9Q3EYCRabQ== X-Received: by 10.28.98.2 with SMTP id w2mr9664054wmb.66.1486758669847; Fri, 10 Feb 2017 12:31:09 -0800 (PST) Received: from ?IPv6:2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149? ([2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149]) by smtp.gmail.com with ESMTPSA id o2sm1019308wmb.28.2017.02.10.12.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 12:31:09 -0800 (PST) To: Andrei Popov , Ilari Liusvaara References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Sam Scott Message-ID: Date: Fri, 10 Feb 2017 20:31:08 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:31:13 -0000 Hi all, Thanks Ilari and Andrei for pointing towards the fact that TLS guarantees ordering of messages. On closer inspection, this has a similar effect as our partial fix to ensure the server must process the authentication message before continuing. We still consider the lack of a strict binding by not including the client certificate in the transcript to be a slight problem, but this is less of an issue than what we first discovered. Our model assumes messages can arrive out of order, so perhaps we are instead considering a weaker variant, similar to DTLS. The core observation remains that the context does not change when going from unilateral to mutual, which seems counter to the intuition of the context. We would prefer the context to also contain the client cert in mutual authentication. Indeed, we first encountered this issue when considering whether the client/server would agree on the authentication status after a session resumption. In this case, the client auth and NewSessionTicket messages may cross over which would result in a similar mismatch. Thanks, Sam On 10/02/17 19:54, Andrei Popov wrote: > Hi Sam, > > This part is not clear to me: >> ...while in the post-handshake client auth, an attacker can decide this (by dropping the message). > How does the attacker drop a TLS-protected message without terminating the connection? > > Thanks, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sam Scott > Sent: Friday, February 10, 2017 11:46 AM > To: Ilari Liusvaara > Cc: tls@ietf.org > Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 > > Hi Ilari, > > Thanks for the comments. > > Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues. > > In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake. > > However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message). > > The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. > The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys. > > This can be strengthened if the client's updated write key is computed using the authentication messages. > > We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this. > > Thanks, > > Sam > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 10 12:39: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 86C1F129BB0 for ; Fri, 10 Feb 2017 12:39:46 -0800 (PST) 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 rLDu1FS8ffUL for ; Fri, 10 Feb 2017 12:39:45 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 02245129BC3 for ; Fri, 10 Feb 2017 12:39:45 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id w194so15006048ybe.0 for ; Fri, 10 Feb 2017 12:39:44 -0800 (PST) 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=9rCSQbmXTVYjoEiylrCEYzOM3yn7eySJaysH+m3LkHI=; b=cBKrQdUrFJ1iUqp/8LZnjJRXkiHEsm3Qfq6XIU9yUT+rzIiYoSkxPg9cBryOJ9WOVo KWWUtttDF3NPNvRVAZBOXgqa4Nw/lHeHcchV4lpTfCAyG8yrfe4excOIRHRwOaFXyvC9 DPul9JcE/DSEOzjK3UrKklbX0EZXj2RgD6cDvJRRFEB3AhpbLEDRIAN/tyseBtIIE/6H x9AKVQR21ubUGJGUmzO+mQm+Vt1tvOstqFkzubaVzAMUXh0EdfpWjk7i9Mjjt+a+BuX9 LY+L2lXbN9pWlrZDy7fo5PGLd8i+iKF+IgKiClx9J5MgGucC9ZctTElgG+l4+gcspCV6 kaRg== 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=9rCSQbmXTVYjoEiylrCEYzOM3yn7eySJaysH+m3LkHI=; b=uOyLCmtz0aYmcfbfkS4eUB+xlqqqKWhZ6O8DpvbbsnpRrlbMDLFiBbGv01eQPvJvJe SRnfLu7OLbwALrR6I/lRwAUkrFiMbVVQTYoH478kgGt9qMMrVGdda2l2YJE12B+xuCDt y+nSlapPvWjVvrBCQWutgdGMm+0u0mgOlRly8WGEFuNWo9U9oEO+DIAhm4awtloq0m84 0rPQXTK1JfzpyN9LCgk7ido3BJC6Xk3oYr/1SOyqz0wFCgut0QOACgnRnF31kUxXaS4Y 6FzssuRZ5KmlTgklORQS23FyQ0RI6CzYDAVMuia7gsDtkpM/WFXzQKT9MBwOYgEf9z01 z3ug== X-Gm-Message-State: AMke39kZmbLxXipyopFyvs49Le6IPmlluowVGsTFi+wqVzN06m8KVFZ5VdexPvsXCERXIFCer+hKu67W8trNpw== X-Received: by 10.37.69.70 with SMTP id s67mr7629103yba.65.1486759184035; Fri, 10 Feb 2017 12:39:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 10 Feb 2017 12:39:03 -0800 (PST) In-Reply-To: References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 10 Feb 2017 12:39:03 -0800 Message-ID: To: Sam Scott Content-Type: multipart/alternative; boundary=001a1135326e0832830548331993 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:39:46 -0000 --001a1135326e0832830548331993 Content-Type: text/plain; charset=UTF-8 Cas, Sam, I thought I understood your concern here but maybe I don't. Say we have the following sequence of messages 1. C->S: ClientHello 2. S->C: ServerHello...ServerFinished 3. C->S: ClientFinished 4. C->S: App message 5. S->C: App message 6. S->C: CertificateRequest 7: C->S: Certificate...Finished 8: C->S: App message 9: S->C: App message As you indicate, there's some ambiguity from the client's perspective (property B) about whether messages 5 and 9 were sent by the server prior to or after receiving message 7, and also message 8. This ambiguity exists even without an attacker and may or may not be resolved at the application layer. An attacker can exploit this ambiguity by holding messages 7 and 8 and (as long as application semantics permit this). Where I get confused is about property A. As I understand your claim, an attacker can hold message 7 but deliver message 8 and therefore, even if the client knows that 9 was in response to 8, he doesn't know that the server received 7. As Ilari says, I don't believe that this is correct because TLS enforces message ordering. I agree that the specification doesn't explicitly say this, but it's implicit in the processing rules via the following: 1. The encryption for each TLS record depends on the record sequence number (RSN). 2. Records do not carry their RSN, so when you decrypt a message, you must use the last RSN + 1 3. When you fail to decrypt a message (which is what happens if you have the wrong RSN) you are required to tear down the connection (https://tlswg.github.io/tls13-spec/#record-payload-protection). For this reason, if the attacker removes message 7, then 8 will not be decryptable, and so ordering is preserved. As Ilari says, this isn't true in DTLS 1.3 which we'll presumably have to deal with one way or the other before standardization (my plan would be just to forbid post-handshake auth). Do you disagree with this? If so, perhaps you could explain. -Ekr P.S. I am not sure that the regular TLS handshake guarantees these properties either. The reason is that the server is permitted to send data prior to receiving the client's second flight (0.5 RTT data). See: https://tlswg.github.io/tls13-spec/#protocol-overview On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott wrote: > Hi Ilari, > > Thanks for the comments. > > Assuming the client sends a valid certificate that the server accepts, > then the server cannot finish the handshake or begin processing incoming > application data until authenticating the client. This *almost* gives us > property (A). In practice, the client is aware that the server has > successfully authenticated since the protocol continues. > > In the case that the server has implemented the reject option (rejecting a > certificate but still continuing), and indeed rejects the certificate, then > the server should send an alert message (or NAK of some form) for the > property to hold in the initial handshake. > > However, even if we take the certificate reject + continue scenario into > account for the initial handshake, then it is clear that this decision can > only be made by the server in the initial handshake, while in the > post-handshake client auth, an attacker can decide this (by dropping the > message). > > The reason we don't believe an explicit ACK is needed is because upgrading > to a new pair of keys explicitly provides this. Specifically, the client > will send all subsequent data to the server under a new key. The server > will not be able to decrypt this data until they receive the client > authentication messages and upgrade the keys. > > This can be strengthened if the client's updated write key is computed > using the authentication messages. > > We agree that TLS enforcing ordering of messages provides similar > guarantees. However, we are analysing the specification as it is presented, > which does not guarantee this. > > Thanks, > > Sam > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1135326e0832830548331993 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cas, Sam,

I thought I unders= tood your concern here but maybe I don't.

Say = we have the following sequence of messages

=C2=A0 = 1. C->S: ClientHello=C2=A0
=C2=A0 2. S->C: ServerHello...Se= rverFinished
=C2=A0 3. C->S: ClientFinished
=C2=A0 4= . C->S: App message
=C2=A0 5. S->C: App message
= =C2=A0 6. S->C: CertificateRequest
=C2=A0 7: C->S: Certific= ate...Finished
=C2=A0 8: C->S: App message
=C2=A0 9:= S->C: App message
=C2=A0=C2=A0
As you indicate, the= re's some ambiguity from the client's perspective
(proper= ty B) about whether messages 5 and 9 were sent by the server
prio= r to or after receiving message 7, and also message 8. This
ambig= uity exists even without an attacker and may or may not be
resolv= ed at the application layer. An attacker can exploit this
ambigui= ty by holding messages 7 and 8 and (as long as application
semant= ics permit this).

Where I get confused is about pr= operty A. As I understand your
claim, an attacker can hold messag= e 7 but deliver message 8 and
therefore, even if the client knows= that 9 was in response to 8,
he doesn't know that the server= received 7. As Ilari says, I don't
believe that this is corr= ect because TLS enforces message ordering.
I agree that the speci= fication doesn't explicitly say this, but
it's implicit i= n the processing rules via the following:

1. The e= ncryption for each TLS record depends on the record sequence
=C2= =A0 =C2=A0number (RSN).
2. Records do not carry their RSN, so whe= n you decrypt a message, you
=C2=A0 =C2=A0must use the last RSN += 1
3. When you fail to decrypt a message (which is what happens i= f you have
=C2=A0 =C2=A0the wrong RSN) you are required to tear d= own the connection
For this reason, if the attacker removes message 7, then 8 wil= l not
be decryptable, and so ordering is preserved. As Ilari says= , this isn't
true in DTLS 1.3 which we'll presumably have= to deal with one way
or the other before standardization (my pla= n would be just to forbid
post-handshake auth). Do you disagree w= ith this? If so, perhaps you
could explain.

<= div>-Ekr

P.S. I am not sure that the regular TLS h= andshake guarantees these
properties either. The reason is that t= he server is permitted to
send data prior to receiving the client= 's second flight (0.5 RTT
data). See:





On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott= <sam.scott89@gmail.com> wrote:
Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then= the server cannot finish the handshake or begin processing incoming applic= ation data until authenticating the client. This *almost* gives us property= (A). In practice, the client is aware that the server has successfully aut= henticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting a = certificate but still continuing), and indeed rejects the certificate, then= the server should send an alert message (or NAK of some form) for the prop= erty to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into ac= count for the initial handshake, then it is clear that this decision can on= ly be made by the server in the initial handshake, while in the post-handsh= ake client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrad= ing to a new pair of keys explicitly provides this. Specifically, the clien= t will send all subsequent data to the server under a new key. The server w= ill not be able to decrypt this data until they receive the client authenti= cation messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed = using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar guarantee= s. However, we are analysing the specification as it is presented, which do= es not guarantee this.

Thanks,

Sam


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

--001a1135326e0832830548331993-- From nobody Fri Feb 10 12:44: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 770DC129BDD for ; Fri, 10 Feb 2017 12:44:38 -0800 (PST) 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 X8rpeaT2dLI5 for ; Fri, 10 Feb 2017 12:44:37 -0800 (PST) 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 21785129BE7 for ; Fri, 10 Feb 2017 12:44:37 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id k15so46352116qtg.3 for ; Fri, 10 Feb 2017 12:44:37 -0800 (PST) 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=8K4eaa5dRb850Y9td6vg17Bxwggp1kAJLKKs2oOs6lg=; b=WmQabKNrqgx/7Pfk7HHaiNLpJVaNyN8QYUGl71BYtjvWdskJ3KM9yYg+LzbsCvbI9c WutKxTgVVU68v6f9d5D3Jop/zoDQMrcZ/CdGjjW7LeYyVR05hwmNL9Cyo2zHrVHO8IkS lfKTvBUZ6mUBNYrIqseA1SE64Jayt2XNxA5ZiIJX3c5BOcoB2jz72iHZ8LZcriH7IVJZ dzQYsJZ0dzZk4OgW/b6edtwDo0nz0+AUNaZCZN/RiYxFwqI0WwCjO3THpHfYBzJeInzg cJeTm/tGQARvWQfN377rNM1m3A88m0eylXfas/QVDEbmot7o4AhV3aXUyzrodQldHxTE IU/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=8K4eaa5dRb850Y9td6vg17Bxwggp1kAJLKKs2oOs6lg=; b=Ij28WIOdTJByXvBFcj3V9xBxhWb9K/aXice9RwezE1Xc/8mHnI/6JTrmcf28iWMzdC lg6xl7KmU6Ib4+sznuJI4mv08tmhSANzjjc8BKkTeXiRLg0sb+zymtxxd+PuQuzouTbA U5Caxb/ctlODOx3b1maPA7kGdxPrOqySjWcdYNC6WyKI5/rY+MSGGhwUYryB+dpnNg+r NJNsQGvIvDOO3Vwa2jE6DsbwwJvAeskR5eXdaBSmsJtgeTeO0LPDj4Dmkjemql+523+q FA9ldZGpxPBKDMgquqpKX9oilIVgf8Bx2ttaG37nwsMJmKRiTeXbaUkG5GiZCcC//aD8 x5Pw== X-Gm-Message-State: AMke39lCOu11YlcTY5c1NY8k08Rpav562Dm31exgM6HE1ftsYZq+J86AWA4WtiZoQOwiB6gOKuyGV1SxkMxedYv4 X-Received: by 10.200.40.38 with SMTP id 35mr9665383qtq.216.1486759476025; Fri, 10 Feb 2017 12:44:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.47.4 with HTTP; Fri, 10 Feb 2017 12:44:35 -0800 (PST) In-Reply-To: References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Victor Vasiliev Date: Fri, 10 Feb 2017 15:44:35 -0500 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114136da6fe14b0548332a6f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:44:38 -0000 --001a114136da6fe14b0548332a6f Content-Type: text/plain; charset=UTF-8 On Fri, Feb 10, 2017 at 3:39 PM, Eric Rescorla wrote: > I agree that the specification doesn't explicitly say this, but > it's implicit in the processing rules via the following: > We do at least explicitly promise those properties in Section E.2: Order protection/non-replayability : An attacker should not be able to cause the receiver to accept a record which it has already accepted or cause the receiver to accept record N+1 without having first processed record N. -- Victor. --001a114136da6fe14b0548332a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 10, 2017 at 3:39 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
= I agree that the specification doesn't explicitly say this, but
it's implicit in the processing rules via the following:

We do at least explicitly promise thos= e properties in Section E.2:
Order protection/non-replayability
: An attacker should not be able to cause the receiver to accept a
record which it has already accepted or cause the receiver to accept
record N+1 without having first processed record N.
  -- Victor.
--001a114136da6fe14b0548332a6f-- From nobody Fri Feb 10 12:51: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 9526A1293F4 for ; Fri, 10 Feb 2017 12:51:51 -0800 (PST) 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 rxA9RRfcUDmY for ; Fri, 10 Feb 2017 12:51:50 -0800 (PST) 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 73592129BCC for ; Fri, 10 Feb 2017 12:51:50 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id o65so15088525ybo.2 for ; Fri, 10 Feb 2017 12:51:50 -0800 (PST) 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=Ppk/+KlVzd9k3K3hpim9QUN2VUFp0JxNYEhYsEfr14A=; b=so61G0bhl98xnwkqDLkbvBFuWu/k7RYU9yhfyBb739Bie9Sy4g+GNb0BFF4rSy80/b jGUNkbLB6peQlevntMItqzRMs2jySsfPQLVgapfNV7XMimbP2h0j4Ki4Nb54VRy4ZyXP LvDJ8udzGlL3fOtiiexq+zZCS1/jtsJTK2swbFb9R4hlcCYU2MvvfzZww0hWOwLn5Cbg Z+3tPICiAJfX2zsIhnPb5swciP5qIBfA1BcJdF1qTh2ij7Zr7pif/DjAjKrgG3RDqZkw kNnoYYPkQAeYWP6KoaJb9dy0zaCyq/HFERHsCO+zjjazN8/wN2DYsN5ILZ9mdpVJg+6H iomg== 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=Ppk/+KlVzd9k3K3hpim9QUN2VUFp0JxNYEhYsEfr14A=; b=B/65Z3b21LiENxRDxGX0TvzC2oYsiSap4pCVTpj4ySgOAb9fOURgw5kjtXjkGGtfm7 qEwEW8lbe5YMVwXuJXEOhwuM75juc7Hq55hxdRldBt+8ZoUd0FT89gzhbDucKfLcx9wL +WYu6dP3LCvIvzWWB1MKHE7e0q13V07OaC6pbhsKltnh8WPnsGJO36wWXuyTzo8vQGFj 7X4dK7hr6/eYBZE/PPLKZhCo9F/8anvU4L1pG6zta+5TQZtqDVVAuFAX0y/p2fwRoLcO w4p9RYsck/h/kgjdGyGW2rQjzdslK8LU7/bBgIHMwDtu3sVyjnH1lcOgpsuZed6BlQc1 PcFA== X-Gm-Message-State: AMke39l0K7x2bcKaNHnjmpWPu+FqMcGVYMndyU5JpSGqF6Uwk5yKsYO/sb9nfqcN+fd7wtnxqXK0h+LoDGZD2Q== X-Received: by 10.37.14.69 with SMTP id 66mr8067095ybo.64.1486759909664; Fri, 10 Feb 2017 12:51:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 10 Feb 2017 12:51:08 -0800 (PST) In-Reply-To: References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 10 Feb 2017 12:51:08 -0800 Message-ID: To: Victor Vasiliev Content-Type: multipart/alternative; boundary=001a113e930c48755e05483344b1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:51:51 -0000 --001a113e930c48755e05483344b1 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 10, 2017 at 12:44 PM, Victor Vasiliev wrote: > On Fri, Feb 10, 2017 at 3:39 PM, Eric Rescorla wrote: > >> I agree that the specification doesn't explicitly say this, but >> it's implicit in the processing rules via the following: >> > > We do at least explicitly promise those properties in Section E.2: > > Order protection/non-replayability > : An attacker should not be able to cause the receiver to accept a > record which it has already accepted or cause the receiver to accept > record N+1 without having first processed record N. > > Good point, so if the processing rules don't in fact enforce that, we should make them do so (I think they do for the reasons I indicated earlier) -Ekr > -- Victor. > > --001a113e930c48755e05483344b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 10, 2017 at 12:44 PM, Victor Vasiliev <vasilvv@google.com>= wrote:
On Fri, Feb 1= 0, 2017 at 3:39 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I agree t= hat the specification doesn't explicitly say this, but
it= 's implicit in the processing rules via the following:

We do at least explicitly promise those = properties in Section E.2:
Order protection/non-replayability
: An attacker should not be able to cause the receiver to accept a
record which it has already accepted or cause the receiver to accept
record N+1 without having first processed record N.

Good point, so if the processing rules don't in fact enforce that= , we should make them
do so (I think they do for the reasons I in= dicated earlier)

-Ekr
=C2=A0
-- Victor.

--001a113e930c48755e05483344b1-- From nobody Fri Feb 10 12:52: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 0EF9E129BE8 for ; Fri, 10 Feb 2017 12:52:58 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 YWZGgkO_NrjZ for ; Fri, 10 Feb 2017 12:52:56 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 22102129BCC for ; Fri, 10 Feb 2017 12:52:56 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id k90so116361947wrc.3 for ; Fri, 10 Feb 2017 12:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to; bh=hq1mgwI1ftfOB9zpnnFX4VIS0Sj53iAvGbtDBiuG5+g=; b=a5+Gd0R/anRlz2vea4OBlbKG3SDZ5JewZe3ix8vDLNlc0W8lW6dfoo5h570iz9cB5+ zNTOnz6zW34ZrXaPMg6SGUUDOLX6xbj+9ixnhYPnTTHUEsSXVyzLsec2KF/xmoELeeGa hPHhy+VYdV6xTqfT79iqiBU0lYWqiIjZqOEti+RVLXB4aUr0ycLUHS5wr0DuXPP1iLOE qJApPhpQhKJkZi4NrHSbOs9iYuAQGDS4h0mr2suo9mVWFfc7Qd7Vv+3iPrfIoYSbIJ4J o+CGpU9WwRDzNthap9tXkvZMErWZFF1AC84IDhFyYjsjUqP0ND1xuKLGKBMiEowwtkQt cJPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to; bh=hq1mgwI1ftfOB9zpnnFX4VIS0Sj53iAvGbtDBiuG5+g=; b=hXJZyyhle6RF8/Jfm0cOFaPAVv7PSK+xi/hgfBL6jAJIZTa27JMeVS/75YdOL3EWCR yCGdEwDMxhtCnGERx3ZQZ3xhBtxLUuN3Pj0PnKI1QwS+1cXkOvaGhffR1szYDPIhSFE0 RRWe2Ezzvfd1Ib42tQAQKkNBQLX8eoHUtUkjqAh8L9jxWFh3WzUaaH5yypb/vF39hTWN Sy6xHBMzKr3dM9m4bRStneYQ/CABs734l6bkgloThfyhtLbqEknvj8qeHz1ILzNPwjWB ikePV3VbmdS0EOLbdX8dWf9xAjRcOfTPBW4ftrBRraWQ30L3YTRoTVdQ3wzkST192unP TqeQ== X-Gm-Message-State: AMke39kkXhplEu1H6QXmnDOdrNTfga4HTZZ1dGwFNV39dpbG7NRoH5YLfS5ul5pYgaAQww== X-Received: by 10.223.148.35 with SMTP id 32mr10379543wrq.18.1486759974591; Fri, 10 Feb 2017 12:52:54 -0800 (PST) Received: from ?IPv6:2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149? ([2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149]) by smtp.gmail.com with ESMTPSA id r19sm4065942wrr.44.2017.02.10.12.52.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 12:52:54 -0800 (PST) To: Eric Rescorla References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Sam Scott Message-ID: Date: Fri, 10 Feb 2017 20:52:53 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D37ED40030B6E9E9486E1651" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:52:58 -0000 This is a multi-part message in MIME format. --------------D37ED40030B6E9E9486E1651 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ekr, That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it does still seem to be an issue. As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel. Thanks, Sam On 10/02/17 20:39, Eric Rescorla wrote: > Cas, Sam, > > I thought I understood your concern here but maybe I don't. > > Say we have the following sequence of messages > > 1. C->S: ClientHello > 2. S->C: ServerHello...ServerFinished > 3. C->S: ClientFinished > 4. C->S: App message > 5. S->C: App message > 6. S->C: CertificateRequest > 7: C->S: Certificate...Finished > 8: C->S: App message > 9: S->C: App message > As you indicate, there's some ambiguity from the client's perspective > (property B) about whether messages 5 and 9 were sent by the server > prior to or after receiving message 7, and also message 8. This > ambiguity exists even without an attacker and may or may not be > resolved at the application layer. An attacker can exploit this > ambiguity by holding messages 7 and 8 and (as long as application > semantics permit this). > > Where I get confused is about property A. As I understand your > claim, an attacker can hold message 7 but deliver message 8 and > therefore, even if the client knows that 9 was in response to 8, > he doesn't know that the server received 7. As Ilari says, I don't > believe that this is correct because TLS enforces message ordering. > I agree that the specification doesn't explicitly say this, but > it's implicit in the processing rules via the following: > > 1. The encryption for each TLS record depends on the record sequence > number (RSN). > 2. Records do not carry their RSN, so when you decrypt a message, you > must use the last RSN + 1 > 3. When you fail to decrypt a message (which is what happens if you have > the wrong RSN) you are required to tear down the connection > (https://tlswg.github.io/tls13-spec/#record-payload-protection > ). > > For this reason, if the attacker removes message 7, then 8 will not > be decryptable, and so ordering is preserved. As Ilari says, this isn't > true in DTLS 1.3 which we'll presumably have to deal with one way > or the other before standardization (my plan would be just to forbid > post-handshake auth). Do you disagree with this? If so, perhaps you > could explain. > > -Ekr > > P.S. I am not sure that the regular TLS handshake guarantees these > properties either. The reason is that the server is permitted to > send data prior to receiving the client's second flight (0.5 RTT > data). See: > https://tlswg.github.io/tls13-spec/#protocol-overview > > > > > > > On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott > wrote: > > Hi Ilari, > > Thanks for the comments. > > Assuming the client sends a valid certificate that the server > accepts, then the server cannot finish the handshake or begin > processing incoming application data until authenticating the > client. This *almost* gives us property (A). In practice, the > client is aware that the server has successfully authenticated > since the protocol continues. > > In the case that the server has implemented the reject option > (rejecting a certificate but still continuing), and indeed rejects > the certificate, then the server should send an alert message (or > NAK of some form) for the property to hold in the initial handshake. > > However, even if we take the certificate reject + continue > scenario into account for the initial handshake, then it is clear > that this decision can only be made by the server in the initial > handshake, while in the post-handshake client auth, an attacker > can decide this (by dropping the message). > > The reason we don't believe an explicit ACK is needed is because > upgrading to a new pair of keys explicitly provides this. > Specifically, the client will send all subsequent data to the > server under a new key. The server will not be able to decrypt > this data until they receive the client authentication messages > and upgrade the keys. > > This can be strengthened if the client's updated write key is > computed using the authentication messages. > > We agree that TLS enforcing ordering of messages provides similar > guarantees. However, we are analysing the specification as it is > presented, which does not guarantee this. > > Thanks, > > Sam > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --------------D37ED40030B6E9E9486E1651 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Ekr,

That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it does still seem to be an issue.

As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel.

Thanks,

Sam

On 10/02/17 20:39, Eric Rescorla wrote:
Cas, Sam,

I thought I understood your concern here but maybe I don't.

Say we have the following sequence of messages

  1. C->S: ClientHello 
  2. S->C: ServerHello...ServerFinished
  3. C->S: ClientFinished
  4. C->S: App message
  5. S->C: App message
  6. S->C: CertificateRequest
  7: C->S: Certificate...Finished
  8: C->S: App message
  9: S->C: App message
  
As you indicate, there's some ambiguity from the client's perspective
(property B) about whether messages 5 and 9 were sent by the server
prior to or after receiving message 7, and also message 8. This
ambiguity exists even without an attacker and may or may not be
resolved at the application layer. An attacker can exploit this
ambiguity by holding messages 7 and 8 and (as long as application
semantics permit this).

Where I get confused is about property A. As I understand your
claim, an attacker can hold message 7 but deliver message 8 and
therefore, even if the client knows that 9 was in response to 8,
he doesn't know that the server received 7. As Ilari says, I don't
believe that this is correct because TLS enforces message ordering.
I agree that the specification doesn't explicitly say this, but
it's implicit in the processing rules via the following:

1. The encryption for each TLS record depends on the record sequence
   number (RSN).
2. Records do not carry their RSN, so when you decrypt a message, you
   must use the last RSN + 1
3. When you fail to decrypt a message (which is what happens if you have
   the wrong RSN) you are required to tear down the connection

For this reason, if the attacker removes message 7, then 8 will not
be decryptable, and so ordering is preserved. As Ilari says, this isn't
true in DTLS 1.3 which we'll presumably have to deal with one way
or the other before standardization (my plan would be just to forbid
post-handshake auth). Do you disagree with this? If so, perhaps you
could explain.

-Ekr

P.S. I am not sure that the regular TLS handshake guarantees these
properties either. The reason is that the server is permitted to
send data prior to receiving the client's second flight (0.5 RTT
data). See:





On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <sam.scott89@gmail.com> wrote:
Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this.

Thanks,

Sam


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


--------------D37ED40030B6E9E9486E1651-- From nobody Fri Feb 10 12:56: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 722E9129BEE for ; Fri, 10 Feb 2017 12:56:42 -0800 (PST) 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 jVRW589OQMbO for ; Fri, 10 Feb 2017 12:56:40 -0800 (PST) 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 0DF711294A3 for ; Fri, 10 Feb 2017 12:56:40 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id w75so28224304ywg.1 for ; Fri, 10 Feb 2017 12:56:40 -0800 (PST) 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=oYzbv7KoYvJ75zUzhx6pTVYEPivpjpMM2SFVH3czNKo=; b=k7TLF63p5xeQM5qXXxcsy9Dzl+JkCfjHjs9wDZTo4EXj/X+tLWNc+imobzw6KLnUGR +dEGrY4J+KeeigFoIw389PZqPhXBkqZG58A5tkaZMZunQHRbPYACZqMtYxauQSdWhR6y KCbetwZwwHP1oZh876aB1dto7ELu7T7dK73LrBuEkryucKQO1zyZ3sIbXOcws45qyweW i7jMrc0nuW6IMgxIUcXd1Ude3olv8n/Lh0kGJaGjf/oUsNtZZf4v+f5lfAf6b6d07Zu3 r1k2Yg85OV/HPPWqYQqZSX0zHjvBMk7CaqXTJxImYlYAye0NAcPOfS8BfCCaTlIV61Zy vlTg== 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=oYzbv7KoYvJ75zUzhx6pTVYEPivpjpMM2SFVH3czNKo=; b=DWjftTR+xO0FMhY1IiObrPmGjNVjRHH7Hc8gkLTDzGQon/hppGlhFGm24ZPllVWb4b Kcc/5xtaHumrruQWGlSvuHKOM/U+G9Oqd8joZXwWaqnMnvzVnYxxbWlzOwhDOUR7gxBJ ij+TZm+c+B8jRBbvZ/7wIB3kko4VinAwB+xTk6R+lzI+oJi8/uxGot1h95bQbPOUM4q4 SbhJ8K/3n61fDRuy3Tf5w0jL1cxpEvv2Abm2DWgr+WmqiDH9TTGGMCQfWZgSnAkuuNLx /skZiqUKgLiyyF7aymT/e8OLfSza49tDaGanY93l4/hYLr8KOBxWmcbcWOJgX5joPinc fmig== X-Gm-Message-State: AMke39kS4315NHUXZ+66F3s58Z7iSBSk3Qlgew2H0UesQsAMvH2qinAdD5sOOb6hH1LK8JwuDZsZuMiiNbVUIw== X-Received: by 10.129.108.131 with SMTP id h125mr7928952ywc.71.1486760199257; Fri, 10 Feb 2017 12:56:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 10 Feb 2017 12:55:58 -0800 (PST) In-Reply-To: References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 10 Feb 2017 12:55:58 -0800 Message-ID: To: Sam Scott Content-Type: multipart/alternative; boundary=001a114dcf788b5e1d05483355d0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:56:42 -0000 --001a114dcf788b5e1d05483355d0 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 10, 2017 at 12:52 PM, Sam Scott wrote: > Hi Ekr, > > That's a good summary of the situation. Indeed we weren't previously > considering TLS as able to enforce the ordering of messages which does seem > to mitigate our scenario for property A. We haven't really had a chance to > take that into consideration for property B, but at a glance it does still > seem to be an issue. > I agree. It doesn't mitigate B at all unless there are application semantics that do so (which is the same as it doesn't mitigate it, I guess). > As mentioned in my other email, one scenario we encountered this was if > (using your message numbering as reference) messages 5 or 9 happened to be > a NewSessionTicket. In this case, the client might be under the impression > that they have a session ticket for a mutually authenticated channel. > Yes, I agree with this. -Ekr > Thanks, > > Sam > On 10/02/17 20:39, Eric Rescorla wrote: > > Cas, Sam, > > I thought I understood your concern here but maybe I don't. > > Say we have the following sequence of messages > > 1. C->S: ClientHello > 2. S->C: ServerHello...ServerFinished > 3. C->S: ClientFinished > 4. C->S: App message > 5. S->C: App message > 6. S->C: CertificateRequest > 7: C->S: Certificate...Finished > 8: C->S: App message > 9: S->C: App message > > As you indicate, there's some ambiguity from the client's perspective > (property B) about whether messages 5 and 9 were sent by the server > prior to or after receiving message 7, and also message 8. This > ambiguity exists even without an attacker and may or may not be > resolved at the application layer. An attacker can exploit this > ambiguity by holding messages 7 and 8 and (as long as application > semantics permit this). > > Where I get confused is about property A. As I understand your > claim, an attacker can hold message 7 but deliver message 8 and > therefore, even if the client knows that 9 was in response to 8, > he doesn't know that the server received 7. As Ilari says, I don't > believe that this is correct because TLS enforces message ordering. > I agree that the specification doesn't explicitly say this, but > it's implicit in the processing rules via the following: > > 1. The encryption for each TLS record depends on the record sequence > number (RSN). > 2. Records do not carry their RSN, so when you decrypt a message, you > must use the last RSN + 1 > 3. When you fail to decrypt a message (which is what happens if you have > the wrong RSN) you are required to tear down the connection > (https://tlswg.github.io/tls13-spec/#record-payload-protection). > > For this reason, if the attacker removes message 7, then 8 will not > be decryptable, and so ordering is preserved. As Ilari says, this isn't > true in DTLS 1.3 which we'll presumably have to deal with one way > or the other before standardization (my plan would be just to forbid > post-handshake auth). Do you disagree with this? If so, perhaps you > could explain. > > -Ekr > > P.S. I am not sure that the regular TLS handshake guarantees these > properties either. The reason is that the server is permitted to > send data prior to receiving the client's second flight (0.5 RTT > data). See: > https://tlswg.github.io/tls13-spec/#protocol-overview > > > > > > On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott wrote: > >> Hi Ilari, >> >> Thanks for the comments. >> >> Assuming the client sends a valid certificate that the server accepts, >> then the server cannot finish the handshake or begin processing incoming >> application data until authenticating the client. This *almost* gives us >> property (A). In practice, the client is aware that the server has >> successfully authenticated since the protocol continues. >> >> In the case that the server has implemented the reject option (rejecting >> a certificate but still continuing), and indeed rejects the certificate, >> then the server should send an alert message (or NAK of some form) for the >> property to hold in the initial handshake. >> >> However, even if we take the certificate reject + continue scenario into >> account for the initial handshake, then it is clear that this decision can >> only be made by the server in the initial handshake, while in the >> post-handshake client auth, an attacker can decide this (by dropping the >> message). >> >> The reason we don't believe an explicit ACK is needed is because >> upgrading to a new pair of keys explicitly provides this. Specifically, the >> client will send all subsequent data to the server under a new key. The >> server will not be able to decrypt this data until they receive the client >> authentication messages and upgrade the keys. >> >> This can be strengthened if the client's updated write key is computed >> using the authentication messages. >> >> We agree that TLS enforcing ordering of messages provides similar >> guarantees. However, we are analysing the specification as it is presented, >> which does not guarantee this. >> >> Thanks, >> >> Sam >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > --001a114dcf788b5e1d05483355d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 10, 2017 at 12:52 PM, Sam Scott <sam.scott89@gmail.com= > wrote:
=20 =20 =20

Hi Ekr,

That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration fo= r property B, but at a glance it does still seem to be an issue.


I agree. It doesn't mitigate B at a= ll unless there are application semantics that do so (which is the same
as it doesn't mitigate it, I guess).
=C2=A0

As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel.


Yes, I agree with this.

-Ekr
= =C2=A0

Thanks,

Sam

On 10/02/17 20:39,= Eric Rescorla wrote:
Cas, Sam,

I thought I understood your concern here but maybe I don't= .

Say we have the following sequence of messages

=C2=A0 1. C->S: ClientHello=C2=A0
=C2=A0 2. S->C: ServerHello...ServerFinished
=C2=A0 3. C->S: ClientFinished
=C2=A0 4. C->S: App message
=C2=A0 5. S->C: App message
=C2=A0 6. S->C: CertificateRequest
=C2=A0 7: C->S: Certificate...Finished
=C2=A0 8: C->S: App message
=C2=A0 9: S->C: App message
=C2=A0=C2=A0
As you indicate, there's some ambiguity from the client= 9;s perspective
(property B) about whether messages 5 and 9 were sent by the server
prior to or after receiving message 7, and also message 8. This
ambiguity exists even without an attacker and may or may not be
resolved at the application layer. An attacker can exploit this
ambiguity by holding messages 7 and 8 and (as long as application
semantics permit this).

Where I get confused is about property A. As I understand your
claim, an attacker can hold message 7 but deliver message 8 and
therefore, even if the client knows that 9 was in response to 8,
he doesn't know that the server received 7. As Ilari says, I don't
believe that this is correct because TLS enforces message ordering.
I agree that the specification doesn't explicitly say this= , but
it's implicit in the processing rules via the following:

1. The encryption for each TLS record depends on the record sequence
=C2=A0 =C2=A0number (RSN).
2. Records do not carry their RSN, so when you decrypt a message, you
=C2=A0 =C2=A0must use the last RSN + 1
3. When you fail to decrypt a message (which is what happens if you have
=C2=A0 =C2=A0the wrong RSN) you are required to tear down the connection

For this reason, if the attacker removes message 7, then 8 will not
be decryptable, and so ordering is preserved. As Ilari says, this isn't
true in DTLS 1.3 which we'll presumably have to deal with one way
or the other before standardization (my plan would be just to forbid
post-handshake auth). Do you disagree with this? If so, perhaps you
could explain.

-Ekr

P.S. I am not sure that the regular TLS handshake guarantees these
properties either. The reason is that the server is permitted to
send data prior to receiving the client's second flight (0.5 RTT
data). See:





On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <sam.scott89@gmail.com> wrote:
Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write ke= y is computed using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this.

Thanks,

Sam


_______________________________________________
TLS mailing list
TLS@iet= f.org
https://www.ietf.org/mailman/listinf= o/tls



--001a114dcf788b5e1d05483355d0-- From nobody Fri Feb 10 17:49: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 BF2B2128874 for ; Fri, 10 Feb 2017 17:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, 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 (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 shG6fZyInOhu for ; Fri, 10 Feb 2017 17:49:19 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0094.outbound.protection.outlook.com [104.47.37.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3321295E8 for ; Fri, 10 Feb 2017 17:49:19 -0800 (PST) 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=Q4Ms0cJfEYJdB4UeJmNVSvgS1YMHSvwg24A4h981Pzc=; b=kJzxt2AvtyfeRt6dWADnhE+CiHrHZ7bBxP9xx2o/MdzMnyn9J/rsNqyWIOaiXimBfHz/Kg+W2kXC4iI4jmhqRzMZOhBuPv8y21RnTDGzX+PQlbx+z/GiKLyXpKWsHToOxJOQEKqsmg9ycV7DOEMcSAJMpNpk2htUFh2Osd8Mvs0= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Sat, 11 Feb 2017 01:49:16 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Sat, 11 Feb 2017 01:49:17 +0000 From: Andrei Popov To: Sam Scott , Eric Rescorla Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 Thread-Index: AQHSg5t3h43MYmEytkO14a3ComoThqFifUUAgAAoHQCAAA7VgIAAA92AgABRxbA= Date: Sat, 11 Feb 2017 01:49:17 +0000 Message-ID: References: <20170210172224.GA22473@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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 94c03b14-044b-49ee-22fd-08d45220307d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:Qpu408U6i5+JPr6oySGlQ3Q782kbgzuzbVJyJO0NWxOvZWqhW4Rt46HWtJ4894bF+ziWuahkDzSLrWdtaoiKa6pvScrxsmYdaZH3lcgUYfUg6nLWmo03rmBIxVjM5Lg/URmAcBNiuueLkRq7HLyBEvMCq0U/PP6hRQK804vxfPOx9vb3Fqz5YZ9Kx9fFGjimrTzW7UxA3UJKLzHDH/l9r8HFW9Z4ADo17N8EiWb+Opu3BrUVDxq4Bjp2D1MbC8TWHNhD5JJpk5EjLJ6n1NKBjO+jEvi/9vd+/A7oS0nzPfrLk52Z6MTnar+qOwu/OUT1jmlSnIWZlndTuG9aT3SYSLYW8nJJqJ32AKP5FjDLibNRF9YhoVMwKHnh4O4FBBYF1QfcDOKrpGII2kpn99w1aDcVjN8CwJqMCHYWiXQRZrg9+rPk53R4dILifxnLKjR3vE5/6F5LMBeEFdnhrg1XYAhI6bO0AEg3JIeSDfuFPVGbKJkkdLrrgLNJRRnyUya6ol6xMXliWzpNPX7mg0CkbvK4zWG8BwiTUkn8PvkxnGw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148)(6042181); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 0215D7173F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(24454002)(51914003)(5005710100001)(10290500002)(10090500001)(97736004)(122556002)(50986999)(76176999)(54356999)(92566002)(8990500004)(101416001)(2900100001)(6306002)(6246003)(55016002)(99286003)(38730400002)(53546003)(25786008)(54896002)(6436002)(606005)(5660300001)(7696004)(2950100002)(53936002)(9686003)(236005)(229853002)(189998001)(33656002)(106356001)(6506006)(106116001)(105586002)(39060400001)(77096006)(86612001)(81156014)(2906002)(8676002)(81166006)(102836003)(6116002)(790700001)(8936002)(86362001)(4326007)(3280700002)(7906003)(74316002)(3660700001)(93886004)(68736007)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842B2E974E5E5AF94EF706A8C470CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2017 01:49:17.0940 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 01:49:23 -0000 --_000_CY1PR0301MB0842B2E974E5E5AF94EF706A8C470CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBhYm91dCBFcmlj4oCZcyBvdGhlciBwb2ludDoNCg0Kw5ggIEkgYW0gbm90IHN1cmUgdGhh dCB0aGUgcmVndWxhciBUTFMgaGFuZHNoYWtlIGd1YXJhbnRlZXMgdGhlc2UNCg0Kw5ggIHByb3Bl cnRpZXMgZWl0aGVyLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhlIHNlcnZlciBpcyBwZXJtaXR0ZWQg dG8NCg0Kw5ggIHNlbmQgZGF0YSBwcmlvciB0byByZWNlaXZpbmcgdGhlIGNsaWVudCdzIHNlY29u ZCBmbGlnaHQgKDAuNSBSVFQNCg0Kw5ggIGRhdGEpLg0KDQpXaXRoIHRoZSBzZXJ2ZXIgc2VuZGlu ZyBkYXRhIHByaW9yIHRvIHJlY2VpdmluZyB0aGUgY2xpZW504oCZcyBzZWNvbmQgZmxpZ2h0LCBp dCBzZWVtcyB0aGF0IHByb3BlcnR5IEIgaXMgbm90IHRoZXJlIHdoZW4gdXNpbmcgaW4taGFuZHNo YWtlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhcyB3ZWxsPw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0K DQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNh bSBTY290dA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxMCwgMjAxNyAxMjo1MyBQTQ0KVG86IEVy aWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbVExTXSBBd2t3YXJkIEhhbmRzaGFrZTogUG9zc2libGUgbWlzbWF0Y2ggb2YgY2xpZW50L3Nl cnZlciB2aWV3IG9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBwb3N0LWhhbmRzaGFrZSBtb2Rl IGluIFJldmlzaW9uIDE4DQoNCg0KSGkgRWtyLA0KDQpUaGF0J3MgYSBnb29kIHN1bW1hcnkgb2Yg dGhlIHNpdHVhdGlvbi4gSW5kZWVkIHdlIHdlcmVuJ3QgcHJldmlvdXNseSBjb25zaWRlcmluZyBU TFMgYXMgYWJsZSB0byBlbmZvcmNlIHRoZSBvcmRlcmluZyBvZiBtZXNzYWdlcyB3aGljaCBkb2Vz IHNlZW0gdG8gbWl0aWdhdGUgb3VyIHNjZW5hcmlvIGZvciBwcm9wZXJ0eSBBLiBXZSBoYXZlbid0 IHJlYWxseSBoYWQgYSBjaGFuY2UgdG8gdGFrZSB0aGF0IGludG8gY29uc2lkZXJhdGlvbiBmb3Ig cHJvcGVydHkgQiwgYnV0IGF0IGEgZ2xhbmNlIGl0IGRvZXMgc3RpbGwgc2VlbSB0byBiZSBhbiBp c3N1ZS4NCg0KQXMgbWVudGlvbmVkIGluIG15IG90aGVyIGVtYWlsLCBvbmUgc2NlbmFyaW8gd2Ug ZW5jb3VudGVyZWQgdGhpcyB3YXMgaWYgKHVzaW5nIHlvdXIgbWVzc2FnZSBudW1iZXJpbmcgYXMg cmVmZXJlbmNlKSBtZXNzYWdlcyA1IG9yIDkgaGFwcGVuZWQgdG8gYmUgYSBOZXdTZXNzaW9uVGlj a2V0LiBJbiB0aGlzIGNhc2UsIHRoZSBjbGllbnQgbWlnaHQgYmUgdW5kZXIgdGhlIGltcHJlc3Np b24gdGhhdCB0aGV5IGhhdmUgYSBzZXNzaW9uIHRpY2tldCBmb3IgYSBtdXR1YWxseSBhdXRoZW50 aWNhdGVkIGNoYW5uZWwuDQoNClRoYW5rcywNCg0KU2FtDQpPbiAxMC8wMi8xNyAyMDozOSwgRXJp YyBSZXNjb3JsYSB3cm90ZToNCkNhcywgU2FtLA0KDQpJIHRob3VnaHQgSSB1bmRlcnN0b29kIHlv dXIgY29uY2VybiBoZXJlIGJ1dCBtYXliZSBJIGRvbid0Lg0KDQpTYXkgd2UgaGF2ZSB0aGUgZm9s bG93aW5nIHNlcXVlbmNlIG9mIG1lc3NhZ2VzDQoNCiAgMS4gQy0+UzogQ2xpZW50SGVsbG8NCiAg Mi4gUy0+QzogU2VydmVySGVsbG8uLi5TZXJ2ZXJGaW5pc2hlZA0KICAzLiBDLT5TOiBDbGllbnRG aW5pc2hlZA0KICA0LiBDLT5TOiBBcHAgbWVzc2FnZQ0KICA1LiBTLT5DOiBBcHAgbWVzc2FnZQ0K ICA2LiBTLT5DOiBDZXJ0aWZpY2F0ZVJlcXVlc3QNCiAgNzogQy0+UzogQ2VydGlmaWNhdGUuLi5G aW5pc2hlZA0KICA4OiBDLT5TOiBBcHAgbWVzc2FnZQ0KICA5OiBTLT5DOiBBcHAgbWVzc2FnZQ0K DQpBcyB5b3UgaW5kaWNhdGUsIHRoZXJlJ3Mgc29tZSBhbWJpZ3VpdHkgZnJvbSB0aGUgY2xpZW50 J3MgcGVyc3BlY3RpdmUNCihwcm9wZXJ0eSBCKSBhYm91dCB3aGV0aGVyIG1lc3NhZ2VzIDUgYW5k IDkgd2VyZSBzZW50IGJ5IHRoZSBzZXJ2ZXINCnByaW9yIHRvIG9yIGFmdGVyIHJlY2VpdmluZyBt ZXNzYWdlIDcsIGFuZCBhbHNvIG1lc3NhZ2UgOC4gVGhpcw0KYW1iaWd1aXR5IGV4aXN0cyBldmVu IHdpdGhvdXQgYW4gYXR0YWNrZXIgYW5kIG1heSBvciBtYXkgbm90IGJlDQpyZXNvbHZlZCBhdCB0 aGUgYXBwbGljYXRpb24gbGF5ZXIuIEFuIGF0dGFja2VyIGNhbiBleHBsb2l0IHRoaXMNCmFtYmln dWl0eSBieSBob2xkaW5nIG1lc3NhZ2VzIDcgYW5kIDggYW5kIChhcyBsb25nIGFzIGFwcGxpY2F0 aW9uDQpzZW1hbnRpY3MgcGVybWl0IHRoaXMpLg0KDQpXaGVyZSBJIGdldCBjb25mdXNlZCBpcyBh Ym91dCBwcm9wZXJ0eSBBLiBBcyBJIHVuZGVyc3RhbmQgeW91cg0KY2xhaW0sIGFuIGF0dGFja2Vy IGNhbiBob2xkIG1lc3NhZ2UgNyBidXQgZGVsaXZlciBtZXNzYWdlIDggYW5kDQp0aGVyZWZvcmUs IGV2ZW4gaWYgdGhlIGNsaWVudCBrbm93cyB0aGF0IDkgd2FzIGluIHJlc3BvbnNlIHRvIDgsDQpo ZSBkb2Vzbid0IGtub3cgdGhhdCB0aGUgc2VydmVyIHJlY2VpdmVkIDcuIEFzIElsYXJpIHNheXMs IEkgZG9uJ3QNCmJlbGlldmUgdGhhdCB0aGlzIGlzIGNvcnJlY3QgYmVjYXVzZSBUTFMgZW5mb3Jj ZXMgbWVzc2FnZSBvcmRlcmluZy4NCkkgYWdyZWUgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBkb2Vz bid0IGV4cGxpY2l0bHkgc2F5IHRoaXMsIGJ1dA0KaXQncyBpbXBsaWNpdCBpbiB0aGUgcHJvY2Vz c2luZyBydWxlcyB2aWEgdGhlIGZvbGxvd2luZzoNCg0KMS4gVGhlIGVuY3J5cHRpb24gZm9yIGVh Y2ggVExTIHJlY29yZCBkZXBlbmRzIG9uIHRoZSByZWNvcmQgc2VxdWVuY2UNCiAgIG51bWJlciAo UlNOKS4NCjIuIFJlY29yZHMgZG8gbm90IGNhcnJ5IHRoZWlyIFJTTiwgc28gd2hlbiB5b3UgZGVj cnlwdCBhIG1lc3NhZ2UsIHlvdQ0KICAgbXVzdCB1c2UgdGhlIGxhc3QgUlNOICsgMQ0KMy4gV2hl biB5b3UgZmFpbCB0byBkZWNyeXB0IGEgbWVzc2FnZSAod2hpY2ggaXMgd2hhdCBoYXBwZW5zIGlm IHlvdSBoYXZlDQogICB0aGUgd3JvbmcgUlNOKSB5b3UgYXJlIHJlcXVpcmVkIHRvIHRlYXIgZG93 biB0aGUgY29ubmVjdGlvbg0KICAgKGh0dHBzOi8vdGxzd2cuZ2l0aHViLmlvL3RsczEzLXNwZWMv I3JlY29yZC1wYXlsb2FkLXByb3RlY3Rpb24pLg0KDQpGb3IgdGhpcyByZWFzb24sIGlmIHRoZSBh dHRhY2tlciByZW1vdmVzIG1lc3NhZ2UgNywgdGhlbiA4IHdpbGwgbm90DQpiZSBkZWNyeXB0YWJs ZSwgYW5kIHNvIG9yZGVyaW5nIGlzIHByZXNlcnZlZC4gQXMgSWxhcmkgc2F5cywgdGhpcyBpc24n dA0KdHJ1ZSBpbiBEVExTIDEuMyB3aGljaCB3ZSdsbCBwcmVzdW1hYmx5IGhhdmUgdG8gZGVhbCB3 aXRoIG9uZSB3YXkNCm9yIHRoZSBvdGhlciBiZWZvcmUgc3RhbmRhcmRpemF0aW9uIChteSBwbGFu IHdvdWxkIGJlIGp1c3QgdG8gZm9yYmlkDQpwb3N0LWhhbmRzaGFrZSBhdXRoKS4gRG8geW91IGRp c2FncmVlIHdpdGggdGhpcz8gSWYgc28sIHBlcmhhcHMgeW91DQpjb3VsZCBleHBsYWluLg0KDQot RWtyDQoNClAuUy4gSSBhbSBub3Qgc3VyZSB0aGF0IHRoZSByZWd1bGFyIFRMUyBoYW5kc2hha2Ug Z3VhcmFudGVlcyB0aGVzZQ0KcHJvcGVydGllcyBlaXRoZXIuIFRoZSByZWFzb24gaXMgdGhhdCB0 aGUgc2VydmVyIGlzIHBlcm1pdHRlZCB0bw0Kc2VuZCBkYXRhIHByaW9yIHRvIHJlY2VpdmluZyB0 aGUgY2xpZW50J3Mgc2Vjb25kIGZsaWdodCAoMC41IFJUVA0KZGF0YSkuIFNlZToNCmh0dHBzOi8v dGxzd2cuZ2l0aHViLmlvL3RsczEzLXNwZWMvI3Byb3RvY29sLW92ZXJ2aWV3DQoNCg0KDQoNCg0K T24gRnJpLCBGZWIgMTAsIDIwMTcgYXQgMTE6NDUgQU0sIFNhbSBTY290dCA8c2FtLnNjb3R0ODlA Z21haWwuY29tPG1haWx0bzpzYW0uc2NvdHQ4OUBnbWFpbC5jb20+PiB3cm90ZToNCkhpIElsYXJp LA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NCg0KQXNzdW1pbmcgdGhlIGNsaWVudCBzZW5k cyBhIHZhbGlkIGNlcnRpZmljYXRlIHRoYXQgdGhlIHNlcnZlciBhY2NlcHRzLCB0aGVuIHRoZSBz ZXJ2ZXIgY2Fubm90IGZpbmlzaCB0aGUgaGFuZHNoYWtlIG9yIGJlZ2luIHByb2Nlc3NpbmcgaW5j b21pbmcgYXBwbGljYXRpb24gZGF0YSB1bnRpbCBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LiBU aGlzICphbG1vc3QqIGdpdmVzIHVzIHByb3BlcnR5IChBKS4gSW4gcHJhY3RpY2UsIHRoZSBjbGll bnQgaXMgYXdhcmUgdGhhdCB0aGUgc2VydmVyIGhhcyBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRl ZCBzaW5jZSB0aGUgcHJvdG9jb2wgY29udGludWVzLg0KDQpJbiB0aGUgY2FzZSB0aGF0IHRoZSBz ZXJ2ZXIgaGFzIGltcGxlbWVudGVkIHRoZSByZWplY3Qgb3B0aW9uIChyZWplY3RpbmcgYSBjZXJ0 aWZpY2F0ZSBidXQgc3RpbGwgY29udGludWluZyksIGFuZCBpbmRlZWQgcmVqZWN0cyB0aGUgY2Vy dGlmaWNhdGUsIHRoZW4gdGhlIHNlcnZlciBzaG91bGQgc2VuZCBhbiBhbGVydCBtZXNzYWdlIChv ciBOQUsgb2Ygc29tZSBmb3JtKSBmb3IgdGhlIHByb3BlcnR5IHRvIGhvbGQgaW4gdGhlIGluaXRp YWwgaGFuZHNoYWtlLg0KDQpIb3dldmVyLCBldmVuIGlmIHdlIHRha2UgdGhlIGNlcnRpZmljYXRl IHJlamVjdCArIGNvbnRpbnVlIHNjZW5hcmlvIGludG8gYWNjb3VudCBmb3IgdGhlIGluaXRpYWwg aGFuZHNoYWtlLCB0aGVuIGl0IGlzIGNsZWFyIHRoYXQgdGhpcyBkZWNpc2lvbiBjYW4gb25seSBi ZSBtYWRlIGJ5IHRoZSBzZXJ2ZXIgaW4gdGhlIGluaXRpYWwgaGFuZHNoYWtlLCB3aGlsZSBpbiB0 aGUgcG9zdC1oYW5kc2hha2UgY2xpZW50IGF1dGgsIGFuIGF0dGFja2VyIGNhbiBkZWNpZGUgdGhp cyAoYnkgZHJvcHBpbmcgdGhlIG1lc3NhZ2UpLg0KDQpUaGUgcmVhc29uIHdlIGRvbid0IGJlbGll dmUgYW4gZXhwbGljaXQgQUNLIGlzIG5lZWRlZCBpcyBiZWNhdXNlIHVwZ3JhZGluZyB0byBhIG5l dyBwYWlyIG9mIGtleXMgZXhwbGljaXRseSBwcm92aWRlcyB0aGlzLiBTcGVjaWZpY2FsbHksIHRo ZSBjbGllbnQgd2lsbCBzZW5kIGFsbCBzdWJzZXF1ZW50IGRhdGEgdG8gdGhlIHNlcnZlciB1bmRl ciBhIG5ldyBrZXkuIFRoZSBzZXJ2ZXIgd2lsbCBub3QgYmUgYWJsZSB0byBkZWNyeXB0IHRoaXMg ZGF0YSB1bnRpbCB0aGV5IHJlY2VpdmUgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXNzYWdl cyBhbmQgdXBncmFkZSB0aGUga2V5cy4NCg0KVGhpcyBjYW4gYmUgc3RyZW5ndGhlbmVkIGlmIHRo ZSBjbGllbnQncyB1cGRhdGVkIHdyaXRlIGtleSBpcyBjb21wdXRlZCB1c2luZyB0aGUgYXV0aGVu dGljYXRpb24gbWVzc2FnZXMuDQoNCldlIGFncmVlIHRoYXQgVExTIGVuZm9yY2luZyBvcmRlcmlu ZyBvZiBtZXNzYWdlcyBwcm92aWRlcyBzaW1pbGFyIGd1YXJhbnRlZXMuIEhvd2V2ZXIsIHdlIGFy ZSBhbmFseXNpbmcgdGhlIHNwZWNpZmljYXRpb24gYXMgaXQgaXMgcHJlc2VudGVkLCB3aGljaCBk b2VzIG5vdCBndWFyYW50ZWUgdGhpcy4NCg0KVGhhbmtzLA0KDQpTYW0NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0K VExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscw0KDQoNCg== --_000_CY1PR0301MB0842B2E974E5E5AF94EF706A8C470CY1PR0301MB0842_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNTc5MTEzMTU7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MDMyMDYzMDggLTI5 MDU3OTg1OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjM7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyMjg5NTEwMjY7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NDM5NDI5NTYgMTI1MzEwMTI2NiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5XaGF0IGFib3V0IEVyaWPigJlzIG90aGVy IHBvaW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkkgYW0gbm90IHN1cmUgdGhh dCB0aGUgcmVndWxhciBUTFMgaGFuZHNoYWtlIGd1YXJhbnRlZXMgdGhlc2U8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4 dCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPnByb3BlcnRpZXMgZWl0aGVyLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhlIHNl cnZlciBpcyBwZXJtaXR0ZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPnNlbmQgZGF0YSBw cmlvciB0byByZWNlaXZpbmcgdGhlIGNsaWVudCdzIHNlY29uZCBmbGlnaHQgKDAuNSBSVFQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6 d2luZG93dGV4dCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRhdGEpLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPldp dGggdGhlIHNlcnZlciBzZW5kaW5nIGRhdGEgcHJpb3IgdG8gcmVjZWl2aW5nIHRoZSBjbGllbnTi gJlzIHNlY29uZCBmbGlnaHQsIGl0IHNlZW1zIHRoYXQgcHJvcGVydHkgQiBpcyBub3QgdGhlcmUg d2hlbiB1c2luZyBpbi1oYW5kc2hha2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQogYXMgd2VsbD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkNoZWVycyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkFuZHJlaTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5TYW0gU2NvdHQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBG ZWJydWFyeSAxMCwgMjAxNyAxMjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gRXJpYyBSZXNjb3JsYSAm bHQ7ZWtyQHJ0Zm0uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVExTXSBBd2t3YXJkIEhhbmRzaGFrZTogUG9zc2libGUgbWlzbWF0 Y2ggb2YgY2xpZW50L3NlcnZlciB2aWV3IG9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBwb3N0 LWhhbmRzaGFrZSBtb2RlIGluIFJldmlzaW9uIDE4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHA+SGkgRWtyLDxvOnA+PC9vOnA+PC9wPg0KPHA+VGhhdCdzIGEgZ29vZCBzdW1tYXJ5IG9mIHRo ZSBzaXR1YXRpb24uIEluZGVlZCB3ZSB3ZXJlbid0IHByZXZpb3VzbHkgY29uc2lkZXJpbmcgVExT IGFzIGFibGUgdG8gZW5mb3JjZSB0aGUgb3JkZXJpbmcgb2YgbWVzc2FnZXMgd2hpY2ggZG9lcyBz ZWVtIHRvIG1pdGlnYXRlIG91ciBzY2VuYXJpbyBmb3IgcHJvcGVydHkgQS4gV2UgaGF2ZW4ndCBy ZWFsbHkgaGFkIGEgY2hhbmNlIHRvIHRha2UgdGhhdCBpbnRvIGNvbnNpZGVyYXRpb24gZm9yIHBy b3BlcnR5DQogQiwgYnV0IGF0IGEgZ2xhbmNlIGl0IGRvZXMgc3RpbGwgc2VlbSB0byBiZSBhbiBp c3N1ZS48bzpwPjwvbzpwPjwvcD4NCjxwPkFzIG1lbnRpb25lZCBpbiBteSBvdGhlciBlbWFpbCwg b25lIHNjZW5hcmlvIHdlIGVuY291bnRlcmVkIHRoaXMgd2FzIGlmICh1c2luZyB5b3VyIG1lc3Nh Z2UgbnVtYmVyaW5nIGFzIHJlZmVyZW5jZSkgbWVzc2FnZXMgNSBvciA5IGhhcHBlbmVkIHRvIGJl IGEgTmV3U2Vzc2lvblRpY2tldC4gSW4gdGhpcyBjYXNlLCB0aGUgY2xpZW50IG1pZ2h0IGJlIHVu ZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhleSBoYXZlIGEgc2Vzc2lvbiB0aWNrZXQNCiBmb3Ig YSBtdXR1YWxseSBhdXRoZW50aWNhdGVkIGNoYW5uZWwuPG86cD48L286cD48L3A+DQo8cD5UaGFu a3MsIDxvOnA+PC9vOnA+PC9wPg0KPHA+U2FtPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMTAvMDIvMTcgMjA6MzksIEVyaWMgUmVzY29ybGEgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DYXMsIFNhbSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB0aG91Z2h0IEkgdW5kZXJzdG9vZCB5b3VyIGNvbmNlcm4gaGVyZSBidXQgbWF5 YmUgSSBkb24ndC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2F5IHdlIGhhdmUgdGhlIGZvbGxvd2luZyBzZXF1ZW5jZSBvZiBtZXNzYWdlczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgMS4gQy0mZ3Q7UzogQ2xpZW50SGVsbG8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAyLiBTLSZndDtDOiBTZXJ2ZXJIZWxs by4uLlNlcnZlckZpbmlzaGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgMy4gQy0mZ3Q7UzogQ2xpZW50RmluaXNoZWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyA0LiBDLSZn dDtTOiBBcHAgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IDUuIFMtJmd0O0M6IEFwcCBtZXNzYWdlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgNi4gUy0mZ3Q7Qzog Q2VydGlmaWNhdGVSZXF1ZXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgNzogQy0mZ3Q7UzogQ2VydGlmaWNhdGUuLi5GaW5pc2hlZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IDg6IEMtJmd0O1M6IEFwcCBtZXNzYWdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgOTogUy0mZ3Q7QzogQXBwIG1lc3NhZ2U8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg eW91IGluZGljYXRlLCB0aGVyZSdzIHNvbWUgYW1iaWd1aXR5IGZyb20gdGhlIGNsaWVudCdzIHBl cnNwZWN0aXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4ocHJvcGVydHkgQikgYWJvdXQgd2hldGhlciBtZXNzYWdlcyA1IGFuZCA5IHdlcmUgc2Vu dCBieSB0aGUgc2VydmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5wcmlvciB0byBvciBhZnRlciByZWNlaXZpbmcgbWVzc2FnZSA3LCBhbmQgYWxz byBtZXNzYWdlIDguIFRoaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmFtYmlndWl0eSBleGlzdHMgZXZlbiB3aXRob3V0IGFuIGF0dGFja2VyIGFu ZCBtYXkgb3IgbWF5IG5vdCBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+cmVzb2x2ZWQgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiBBbiBhdHRh Y2tlciBjYW4gZXhwbG9pdCB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hbWJpZ3VpdHkgYnkgaG9sZGluZyBtZXNzYWdlcyA3IGFuZCA4IGFu ZCAoYXMgbG9uZyBhcyBhcHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VtYW50aWNzIHBlcm1pdCB0aGlzKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlcmUgSSBnZXQgY29u ZnVzZWQgaXMgYWJvdXQgcHJvcGVydHkgQS4gQXMgSSB1bmRlcnN0YW5kIHlvdXI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNsYWltLCBhbiBhdHRh Y2tlciBjYW4gaG9sZCBtZXNzYWdlIDcgYnV0IGRlbGl2ZXIgbWVzc2FnZSA4IGFuZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlcmVmb3JlLCBl dmVuIGlmIHRoZSBjbGllbnQga25vd3MgdGhhdCA5IHdhcyBpbiByZXNwb25zZSB0byA4LDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGUgZG9lc24n dCBrbm93IHRoYXQgdGhlIHNlcnZlciByZWNlaXZlZCA3LiBBcyBJbGFyaSBzYXlzLCBJIGRvbid0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iZWxp ZXZlIHRoYXQgdGhpcyBpcyBjb3JyZWN0IGJlY2F1c2UgVExTIGVuZm9yY2VzIG1lc3NhZ2Ugb3Jk ZXJpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFncmVlIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gZG9lc24ndCBleHBsaWNpdGx5IHNheSB0 aGlzLCBidXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPml0J3MgaW1wbGljaXQgaW4gdGhlIHByb2Nlc3NpbmcgcnVsZXMgdmlhIHRoZSBmb2xsb3dp bmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjEuIFRoZSBlbmNyeXB0aW9uIGZvciBlYWNoIFRMUyByZWNvcmQgZGVwZW5kcyBvbiB0aGUgcmVj b3JkIHNlcXVlbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7bnVtYmVyIChSU04pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gUmVjb3JkcyBkbyBub3QgY2FycnkgdGhl aXIgUlNOLCBzbyB3aGVuIHlvdSBkZWNyeXB0IGEgbWVzc2FnZSwgeW91PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7bXVzdCB1 c2UgdGhlIGxhc3QgUlNOICYjNDM7IDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjMuIFdoZW4geW91IGZhaWwgdG8gZGVjcnlwdCBhIG1lc3NhZ2Ug KHdoaWNoIGlzIHdoYXQgaGFwcGVucyBpZiB5b3UgaGF2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3RoZSB3cm9uZyBSU04p IHlvdSBhcmUgcmVxdWlyZWQgdG8gdGVhciBkb3duIHRoZSBjb25uZWN0aW9uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7KDxh IGhyZWY9Imh0dHBzOi8vdGxzd2cuZ2l0aHViLmlvL3RsczEzLXNwZWMvI3JlY29yZC1wYXlsb2Fk LXByb3RlY3Rpb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rsc3dnLmdpdGh1Yi5pby90bHMx My1zcGVjLyNyZWNvcmQtcGF5bG9hZC1wcm90ZWN0aW9uPC9hPikuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aGlzIHJlYXNvbiwgaWYg dGhlIGF0dGFja2VyIHJlbW92ZXMgbWVzc2FnZSA3LCB0aGVuIDggd2lsbCBub3Q8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlIGRlY3J5cHRhYmxl LCBhbmQgc28gb3JkZXJpbmcgaXMgcHJlc2VydmVkLiBBcyBJbGFyaSBzYXlzLCB0aGlzIGlzbid0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cnVl IGluIERUTFMgMS4zIHdoaWNoIHdlJ2xsIHByZXN1bWFibHkgaGF2ZSB0byBkZWFsIHdpdGggb25l IHdheTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ b3IgdGhlIG90aGVyIGJlZm9yZSBzdGFuZGFyZGl6YXRpb24gKG15IHBsYW4gd291bGQgYmUganVz dCB0byBmb3JiaWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnBvc3QtaGFuZHNoYWtlIGF1dGgpLiBEbyB5b3UgZGlzYWdyZWUgd2l0aCB0aGlzPyBJ ZiBzbywgcGVyaGFwcyB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmNvdWxkIGV4cGxhaW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UC5TLiBJIGFtIG5vdCBzdXJlIHRoYXQgdGhlIHJl Z3VsYXIgVExTIGhhbmRzaGFrZSBndWFyYW50ZWVzIHRoZXNlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9wZXJ0aWVzIGVpdGhlci4gVGhlIHJl YXNvbiBpcyB0aGF0IHRoZSBzZXJ2ZXIgaXMgcGVybWl0dGVkIHRvPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZW5kIGRhdGEgcHJpb3IgdG8gcmVj ZWl2aW5nIHRoZSBjbGllbnQncyBzZWNvbmQgZmxpZ2h0ICgwLjUgUlRUPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kYXRhKS4gU2VlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly90bHN3Zy5naXRodWIuaW8vdGxzMTMtc3BlYy8jcHJvdG9jb2wtb3ZlcnZpZXciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rsc3dnLmdpdGh1Yi5pby90bHMxMy1zcGVjLyNwcm90b2NvbC1v dmVydmlldzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gRnJpLCBGZWIgMTAsIDIwMTcgYXQgMTE6NDUgQU0sIFNhbSBTY290dCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNhbS5zY290dDg5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNh bS5zY290dDg5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIElsYXJpLDxicj4NCjxicj4NClRoYW5rcyBm b3IgdGhlIGNvbW1lbnRzLjxicj4NCjxicj4NCkFzc3VtaW5nIHRoZSBjbGllbnQgc2VuZHMgYSB2 YWxpZCBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBzZXJ2ZXIgYWNjZXB0cywgdGhlbiB0aGUgc2VydmVy IGNhbm5vdCBmaW5pc2ggdGhlIGhhbmRzaGFrZSBvciBiZWdpbiBwcm9jZXNzaW5nIGluY29taW5n IGFwcGxpY2F0aW9uIGRhdGEgdW50aWwgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudC4gVGhpcyAq YWxtb3N0KiBnaXZlcyB1cyBwcm9wZXJ0eSAoQSkuIEluIHByYWN0aWNlLCB0aGUgY2xpZW50IGlz DQogYXdhcmUgdGhhdCB0aGUgc2VydmVyIGhhcyBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRlZCBz aW5jZSB0aGUgcHJvdG9jb2wgY29udGludWVzLjxicj4NCjxicj4NCkluIHRoZSBjYXNlIHRoYXQg dGhlIHNlcnZlciBoYXMgaW1wbGVtZW50ZWQgdGhlIHJlamVjdCBvcHRpb24gKHJlamVjdGluZyBh IGNlcnRpZmljYXRlIGJ1dCBzdGlsbCBjb250aW51aW5nKSwgYW5kIGluZGVlZCByZWplY3RzIHRo ZSBjZXJ0aWZpY2F0ZSwgdGhlbiB0aGUgc2VydmVyIHNob3VsZCBzZW5kIGFuIGFsZXJ0IG1lc3Nh Z2UgKG9yIE5BSyBvZiBzb21lIGZvcm0pIGZvciB0aGUgcHJvcGVydHkgdG8gaG9sZCBpbiB0aGUg aW5pdGlhbCBoYW5kc2hha2UuPGJyPg0KPGJyPg0KSG93ZXZlciwgZXZlbiBpZiB3ZSB0YWtlIHRo ZSBjZXJ0aWZpY2F0ZSByZWplY3QgJiM0MzsgY29udGludWUgc2NlbmFyaW8gaW50byBhY2NvdW50 IGZvciB0aGUgaW5pdGlhbCBoYW5kc2hha2UsIHRoZW4gaXQgaXMgY2xlYXIgdGhhdCB0aGlzIGRl Y2lzaW9uIGNhbiBvbmx5IGJlIG1hZGUgYnkgdGhlIHNlcnZlciBpbiB0aGUgaW5pdGlhbCBoYW5k c2hha2UsIHdoaWxlIGluIHRoZSBwb3N0LWhhbmRzaGFrZSBjbGllbnQgYXV0aCwgYW4gYXR0YWNr ZXIgY2FuDQogZGVjaWRlIHRoaXMgKGJ5IGRyb3BwaW5nIHRoZSBtZXNzYWdlKS48YnI+DQo8YnI+ DQpUaGUgcmVhc29uIHdlIGRvbid0IGJlbGlldmUgYW4gZXhwbGljaXQgQUNLIGlzIG5lZWRlZCBp cyBiZWNhdXNlIHVwZ3JhZGluZyB0byBhIG5ldyBwYWlyIG9mIGtleXMgZXhwbGljaXRseSBwcm92 aWRlcyB0aGlzLiBTcGVjaWZpY2FsbHksIHRoZSBjbGllbnQgd2lsbCBzZW5kIGFsbCBzdWJzZXF1 ZW50IGRhdGEgdG8gdGhlIHNlcnZlciB1bmRlciBhIG5ldyBrZXkuIFRoZSBzZXJ2ZXIgd2lsbCBu b3QgYmUgYWJsZSB0byBkZWNyeXB0IHRoaXMgZGF0YQ0KIHVudGlsIHRoZXkgcmVjZWl2ZSB0aGUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lc3NhZ2VzIGFuZCB1cGdyYWRlIHRoZSBrZXlzLjxicj4N Cjxicj4NClRoaXMgY2FuIGJlIHN0cmVuZ3RoZW5lZCBpZiB0aGUgY2xpZW50J3MgdXBkYXRlZCB3 cml0ZSBrZXkgaXMgY29tcHV0ZWQgdXNpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIG1lc3NhZ2VzLjxi cj4NCjxicj4NCldlIGFncmVlIHRoYXQgVExTIGVuZm9yY2luZyBvcmRlcmluZyBvZiBtZXNzYWdl cyBwcm92aWRlcyBzaW1pbGFyIGd1YXJhbnRlZXMuIEhvd2V2ZXIsIHdlIGFyZSBhbmFseXNpbmcg dGhlIHNwZWNpZmljYXRpb24gYXMgaXQgaXMgcHJlc2VudGVkLCB3aGljaCBkb2VzIG5vdCBndWFy YW50ZWUgdGhpcy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KU2FtIDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB0842B2E974E5E5AF94EF706A8C470CY1PR0301MB0842_-- From nobody Sat Feb 11 03:46: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 77A5A12943F for ; Sat, 11 Feb 2017 03:45:56 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 WUSlzf0pZnvN for ; Sat, 11 Feb 2017 03:45:52 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0101.outbound.protection.outlook.com [23.103.200.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 C96DA128E18 for ; Sat, 11 Feb 2017 03:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ffKQBAdY2pe2Gi4drtZbYY1DPdt5/4PYae54pkL7CJc=; b=uwFuU7ToqwBL5956rT/6x+u8ejae4BPp629RG/Fe60tWJk4uONLg8hkUSmxiAe47XUhSI/lVHDnEjzz2w0UYkFQYanwP6fQaf3ODY1WwjkE5k6MguSGB30wt7b2B2x2TGN/vnvb8Up+QKqA2YjsTklfCBNh8ifWHeag9OAt1k4o= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Sat, 11 Feb 2017 11:45:51 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.029; Sat, 11 Feb 2017 11:45:51 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , Sean Turner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlqFifU4A///GdACAAFarAIAACkUT Date: Sat, 11 Feb 2017 11:45:50 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.220.15] x-ms-office365-filtering-correlation-id: 010cf658-4236-4851-505c-08d452738747 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:77HJ+r0k39QXT6OJNTDLScniEDewV25aRVteVWKPP9iGc5tUWJMv9H0yZt/9PkWptGKLo50pl94w+cJ7LD7EKE86drDJXOP77C0OOhszfcgsH1WeuQSwpItCgqQ9BIolm0z16NqP86iH/xDacTORK86/Y+glnW9/Dy6vO/9AiAt3noTXzQTUZJ8fQbeejRwiO1pys/xlapYG2IvBJKzwtAnBQTkINcl/mMLhGUQtIHtQfKT4OJHEc0buG9eo/hdsGBCPIcEcmAnCiZXVpEwA12srJ4XtzkDkgO5kqHo7deooA0REAYC/6Le7npra1b3DOo2VIAhVkKkLpRnfRtKtpbkQ/nnRz1pkdyqDnyFm6qdzKfqdHNmREZnM4GsPnLWmUYnXL7zzG29JHy/NngO8KcQgck191x6WByRuyHX3+OaknAi6weSJ7FdYmfpzaOZfcfmaAzAzczQDBoX0n3CO3dF5Q6Z1T+rUQOw1Vly8ulnohJ5RlzH9f+4N4l6q4Cl6gtpNR5xPWHVXZaHG9/9Vyg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; x-forefront-prvs: 0215D7173F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39860400002)(39410400002)(39450400003)(39840400002)(24454002)(199003)(377454003)(189002)(6246003)(53546003)(66066001)(6606003)(38730400002)(74316002)(3660700001)(93886004)(3846002)(6116002)(102836003)(2950100002)(189998001)(97736004)(68736007)(101416001)(122556002)(3280700002)(7736002)(4326007)(7906003)(2906002)(76176999)(7696004)(54356999)(50986999)(5660300001)(8656002)(54906002)(25786008)(54896002)(6306002)(92566002)(99286003)(55016002)(2900100001)(33656002)(105586002)(53936002)(86362001)(106356001)(106116001)(15974865002)(236005)(8936002)(229853002)(9686003)(77096006)(81166006)(8676002)(19627405001)(606005)(6436002)(81156014)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2017 11:45:50.6413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 11:45:56 -0000 --_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kenny, AES-permutation is a permutation. But, AES-GCM (AES in counter mode) is a = PRF as long as the 128-bit IVs are unique under the encryption key. The am= ount of plaintext is the same with the amount of ciphertext. I originally talked about plaintext in my discussion, but several people as= ked me to talk about ciphertext instead (I thought maybe measuring cipherte= xt was easier than measuring plaintext in practice and that was why they as= ked me that). The number of 128-bit blocks of plaintext is the same with the number of 12= 8-bit "one-time pad" keys produced by the AES key and the unique 128-bit IV= s. These 128-bit "one-time pad" keys and the corresponding 128-bit cipherte= xt blocks are the same in the sense that they are both sets of pseudo-rando= m 128-bit blocks. But, the 128-bit "one-time pad" keys are not stored, the= y have to either measure the amount of plaintext or ciphertext. Regards, Quynh. ________________________________ From: Paterson, Kenny Sent: Friday, February 10, 2017 2:06:46 PM To: Dang, Quynh (Fed); Sean Turner Cc: IRTF CFRG; Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Hi, On 10/02/2017 18:56, "Dang, Quynh (Fed)" wrote: >Dear Kenny, > >From: "Paterson, Kenny" >Date: Friday, February 10, 2017 at 12:22 PM >To: 'Quynh' , Sean Turner >Cc: IRTF CFRG , "" >Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs >(#765/#769) > > > >>Dear Quynh, >> >> >>On 10/02/2017 12:48, "Dang, Quynh (Fed)" wrote: >> >> >>>Hi Kenny, >>> >>> >>>>Hi, >>>> >>>> >>>> >>>> >>>>My preference is to go with the existing text, option a). >>>> >>>> >>>> >>>> >>>>From the github discussion, I think option c) involves a less >>>>conservative >>>>security bound (success probability for IND-CPA attacker bounded by >>>>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be >>>>aware of the weaker security guarantees it provides. >>>> >>>> >>>> >>>> >>>>I do not understand option b). It seems to rely on an analysis of >>>>collisions of ciphertext blocks rather than the established security >>>>proof >>>>for AES-GCM. >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>My suggestion was based on counting. I analyzed AES-GCM in TLS 1.3 as >>>being a counter-mode encryption and each counter is a 96-bit nonce || >>>32-bit counter. I don=92t know if there is another kind of proof that is >>>more precise than that. >> >> >>Thanks for explaining. I think, then, that what you are doing is (in >>effect) accounting for the PRP/PRF switching lemma that is used (in a >>standard way) as part of the IND-CPA security proof of AES-GCM. One can >>obtain a greater degree of precision by using the proven bounds for >>IND-CPA security of AES-GCM. These incorporate the "security loss" coming >>from the PRP/PRF switching lemma. The current best form of these bounds >>is >>due to Iwata et al.. This is precisely what we analyse in the note at >>http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see Limits on Authenticated Encryption Use in TLS - isg.rhul.ac.uk www.isg.rhul.ac.uk Limits on Authenticated Encryption Use in TLS Atul Luykx and Kenneth G. Pat= erson March 8, 2016 Abstract Thistechnicalnotepresentslimitsonthesecurity(a= safunctionofthe >>equations (5) - (7) on page 6 of that note. >> > >I reviewed the paper more than once. I highly value the work. I suggested >to reference your paper in the text. I think the result in your paper >is the same with what is being suggested when the collision probability >allowed is 2^(-32). Thanks for this feedback. I guess my confusion arises from wondering what you mean by collision probability and why you care about it. There are no collisions in the block cipher's outputs per se, because AES is a permutation for each choice of key. And collisions in the ciphertext blocks output by AES-GCM are irrelevant to its formal security analysis. On the other hand, when in the proof of IND-CPA security of AES-GCM one switches from a random permutation (which is how we model AES) to a random function (which is what we need to argue in the end that the plaintext is masked by a one-time pad, giving indistinguishability), then one needs to deal with the probability that collisions occur in the function's outputs but not in the permutation's. This ends up being the main contribution to the security bound in the proof for IND-CPA security. Is that what you are getting at? If so, then we are on the same page, and what remains is to decide whether a 2^{-32} bound is a good enough security margin. Regards, Kenny --_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi Kenny,


AES-permutation is a permutation.  But, AES-GCM (AES in counter mod= e) is a PRF as long as the 128-bit IVs are unique under the encryption key.=  The amount of plaintext is the same with the amount of ciphertext.


I originally talked about plaintext in my discussion, but several people= asked me to talk about ciphertext instead (I thought maybe measuring ciphe= rtext was easier than measuring plaintext in practice and that was why they= asked me that). 


The number of 128-bit blocks of plaintext is the same with the number of= 128-bit "one-time pad" keys produced by the AES key and the uniq= ue 128-bit IVs. These 128-bit "one-time pad" keys and the co= rresponding 128-bit ciphertext blocks are the same in the sense that they are both sets of pseudo-random 128-bit blocks.  But, = the 128-bit "one-time pad" keys are not stored, they have to eith= er measure the amount of plaintext or ciphertext. 


Regards,

Quynh. 



From: Paterson, Kenny <= ;Kenny.Paterson@rhul.ac.uk>
Sent: Friday, February 10, 2017 2:06:46 PM
To: Dang, Quynh (Fed); Sean Turner
Cc: IRTF CFRG; <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usa= ge" PRs (#765/#769)
 
Hi,

On 10/02/2017 18:56, "Dang, Quynh (Fed)" <quynh.dang@nist.gov&= gt; wrote:

>Dear Kenny,
>
>From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
>Date: Friday, February 10, 2017 at 12:22 PM
>To: 'Quynh' <Quynh.Dang@nist.gov>, Sean Turner <sean@sn3rd.com= >
>Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" &= lt;tls@ietf.org>
>Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage&= quot; PRs
>(#765/#769)
>
>
>
>>Dear Quynh,
>>
>>
>>On 10/02/2017 12:48, "Dang, Quynh (Fed)" <quynh.dang@n= ist.gov> wrote:
>>
>>
>>>Hi Kenny,
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>
>>>>My preference is to go with the existing text, option a). >>>>
>>>>
>>>>
>>>>
>>>>From the github discussion, I think option c) involves a le= ss
>>>>conservative
>>>>security bound (success probability for IND-CPA attacker bo= unded by
>>>>2^{-32} instead of 2^{-60}). I can live with that, but the = WG should be
>>>>aware of the weaker security guarantees it provides.
>>>>
>>>>
>>>>
>>>>
>>>>I do not understand option b). It seems to rely on an analy= sis of
>>>>collisions of ciphertext blocks rather than the established= security
>>>>proof
>>>>for AES-GCM.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>My suggestion was based on counting.  I analyzed AES-GCM i= n TLS 1.3  as
>>>being a counter-mode encryption and each counter is a 96-bit no= nce ||
>>>32-bit counter. I don=92t know if there is another kind of proo= f that is
>>>more precise than that.
>>
>>
>>Thanks for explaining. I think, then, that what you are doing is (i= n
>>effect) accounting for the PRP/PRF switching lemma that is used (in= a
>>standard way) as part of the IND-CPA security proof of AES-GCM. One= can
>>obtain a greater degree of precision by using the proven bounds for=
>>IND-CPA security of AES-GCM. These incorporate the "security l= oss" coming
>>from the PRP/PRF switching lemma. The current best form of these bo= unds
>>is
>>due to Iwata et al.. This is precisely what we analyse in the note = at
>>http://www.isg.rhul.ac.uk/~kp/TLS-AEboun= ds.pdf - specifically, see

>>equations (5) - (7) on page 6 of that note.
>>
>
>I reviewed the paper more than once. I highly value the work. I suggest= ed
>to reference  your paper in the text.  I think the result in = your paper
>is the same with what is being suggested when the collision probability=
>allowed is 2^(-32).

Thanks for this feedback. I guess my confusion arises from wondering what you mean by collision probability and why you care about it. There are no collisions in the block cipher's outputs per se, because AES is a
permutation for each choice of key. And collisions in the ciphertext
blocks output by AES-GCM are irrelevant to its formal security analysis.
On the other hand, when in the proof of IND-CPA security of AES-GCM one
switches from a random permutation (which is how we model AES) to a random<= br> function (which is what we need to argue in the end that the plaintext is masked by a one-time pad, giving indistinguishability), then one needs to deal with the probability that collisions occur in the function's outputs but not in the permutation's. This ends up being the main contribution to the security bound in the proof for IND-CPA security.

Is that what you are getting at?

If so, then we are on the same page, and what remains is to decide whether<= br> a 2^{-32} bound is a good enough security margin.

Regards,

Kenny


--_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_-- From nobody Sat Feb 11 06:53: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 ADF4312960E for ; Sat, 11 Feb 2017 06:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 o5KR9vFDxNwm for ; Sat, 11 Feb 2017 06:52:57 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 0AECB12953B for ; Sat, 11 Feb 2017 06:52:57 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id k90so125998367wrc.3 for ; Sat, 11 Feb 2017 06:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to; bh=l8MivqEfQy85UCYTPerSCLT2QSFYOEeJ8Gb5Al9b1ug=; b=SVQsXF3XsOc2yGWy0x9nrA7yF6EQERe9LTBElG+RbKzrp6gekmu/Fdkt23N5gCxcsn 3QHfAK5egyqZj6FbMGpYkDmbcCEj5vkuTIDPIB8Px2C/qzk0jlf5DtZ4S9fPAiEUkGn1 BrE3N50x71U0H8wHfWe/P9MHRkGmdaWygWZ2BxfBD3OQjetyDrgRrqP9IPMaDEX3sDTz rrdtb3lmKQZpHWN2xDVPTvuBA3hlRhUoYKgO+8mhhxyW3JVvU+zWz+EZh5k8AdKv0ibK gazupGcXJYPH4epnaHrDrQKQwD+incA5unAOus1+r0GLpczNoL4YEhuR70KAlwOS7pf3 2ecg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to; bh=l8MivqEfQy85UCYTPerSCLT2QSFYOEeJ8Gb5Al9b1ug=; b=T0UYbNHibUTRTbsYI40xERC2BgViWkBvy7XGq45ktvXOtLNz0bPVQ43VWQdUkhJ1aS ISQlyEoSqvYUQyP6/0RyRHQHgt/FjM6uVTkg8kbUXqP0HPC697WYEpQHQ7S05JoZydrb 8JHEbvWWK22VyPQk+fxQFEc7xNMVBMJubQNi0Kz0kG7qGxue7RVk9Swl0By1XBT569HH bm/6EbsRy1pXfbabS0WPvtswAGEW6JdAE8y7zcVfAxBBqez1fu8/vIdIbX1IgCxOPwcT EUid2UykIa62eoCvks9KmAIpfDbiZQK9XopQhYoSW2upTWO5WiFkVpQIALCfMauHq+2/ T0Ig== X-Gm-Message-State: AMke39mPELBL13XeDfz+/EKryXO9oyYSM5tIj1OM7UBKyikOiKZjeoI0jao02bqOUzPFBQ== X-Received: by 10.223.149.39 with SMTP id 36mr12148308wrs.125.1486824775484; Sat, 11 Feb 2017 06:52:55 -0800 (PST) Received: from ?IPv6:2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149? ([2a02:c7d:c804:7d00:7e7a:91ff:fe9e:8149]) by smtp.gmail.com with ESMTPSA id o143sm5462113wmd.3.2017.02.11.06.52.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Feb 2017 06:52:54 -0800 (PST) To: Andrei Popov , Eric Rescorla References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> From: Sam Scott Message-ID: <304937cb-ca58-d4aa-a731-fd1498848637@gmail.com> Date: Sat, 11 Feb 2017 14:52:53 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF7E5870FD3AB5A7C14D3E2A" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 14:52:59 -0000 This is a multi-part message in MIME format. --------------DF7E5870FD3AB5A7C14D3E2A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Is it common that 0.5 RTT data will be sent by the server in a fresh session? I.e. not after a resumption and therefore without the client previously sending early data? Even so, it does also seem like a slightly troubling scenario, since the client has no (in-band) mechanism to determine the authentication was successful (or even at what point it arrived). Again, this could be rectified by forcing the client/server to update their keys, and even better if they include the client's authentication messages. However, NewSessionTicket messages do not have this problem since the server wont send these before processing the client Finished, but it could still be an issue in the post-hs scenario. Just want to reiterate: thanks all for helping to clarify this behaviour we've encountered. Hopefully it proves a useful insight into the guarantees (or lack thereof) provided by client authentication. Also it is really useful in helping us to refine our model :) Sam On 11/02/17 01:49, Andrei Popov wrote: > > What about Eric’s other point: > > ØI am not sure that the regular TLS handshake guarantees these > > Øproperties either. The reason is that the server is permitted to > > Øsend data prior to receiving the client's second flight (0.5 RTT > > Ødata). > > With the server sending data prior to receiving the client’s second > flight, it seems that property B is not there when using in-handshake > client authentication as well? > > Cheers, > > Andrei > > *From:*TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Sam Scott > *Sent:* Friday, February 10, 2017 12:53 PM > *To:* Eric Rescorla > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Awkward Handshake: Possible mismatch of > client/server view on client authentication in post-handshake mode in > Revision 18 > > Hi Ekr, > > That's a good summary of the situation. Indeed we weren't previously > considering TLS as able to enforce the ordering of messages which does > seem to mitigate our scenario for property A. We haven't really had a > chance to take that into consideration for property B, but at a glance > it does still seem to be an issue. > > As mentioned in my other email, one scenario we encountered this was > if (using your message numbering as reference) messages 5 or 9 > happened to be a NewSessionTicket. In this case, the client might be > under the impression that they have a session ticket for a mutually > authenticated channel. > > Thanks, > > Sam > > On 10/02/17 20:39, Eric Rescorla wrote: > > Cas, Sam, > > I thought I understood your concern here but maybe I don't. > > Say we have the following sequence of messages > > 1. C->S: ClientHello > > 2. S->C: ServerHello...ServerFinished > > 3. C->S: ClientFinished > > 4. C->S: App message > > 5. S->C: App message > > 6. S->C: CertificateRequest > > 7: C->S: Certificate...Finished > > 8: C->S: App message > > 9: S->C: App message > > As you indicate, there's some ambiguity from the client's perspective > > (property B) about whether messages 5 and 9 were sent by the server > > prior to or after receiving message 7, and also message 8. This > > ambiguity exists even without an attacker and may or may not be > > resolved at the application layer. An attacker can exploit this > > ambiguity by holding messages 7 and 8 and (as long as application > > semantics permit this). > > Where I get confused is about property A. As I understand your > > claim, an attacker can hold message 7 but deliver message 8 and > > therefore, even if the client knows that 9 was in response to 8, > > he doesn't know that the server received 7. As Ilari says, I don't > > believe that this is correct because TLS enforces message ordering. > > I agree that the specification doesn't explicitly say this, but > > it's implicit in the processing rules via the following: > > 1. The encryption for each TLS record depends on the record sequence > > number (RSN). > > 2. Records do not carry their RSN, so when you decrypt a message, you > > must use the last RSN + 1 > > 3. When you fail to decrypt a message (which is what happens if > you have > > the wrong RSN) you are required to tear down the connection > > (https://tlswg.github.io/tls13-spec/#record-payload-protection). > > For this reason, if the attacker removes message 7, then 8 will not > > be decryptable, and so ordering is preserved. As Ilari says, this > isn't > > true in DTLS 1.3 which we'll presumably have to deal with one way > > or the other before standardization (my plan would be just to forbid > > post-handshake auth). Do you disagree with this? If so, perhaps you > > could explain. > > -Ekr > > P.S. I am not sure that the regular TLS handshake guarantees these > > properties either. The reason is that the server is permitted to > > send data prior to receiving the client's second flight (0.5 RTT > > data). See: > > https://tlswg.github.io/tls13-spec/#protocol-overview > > On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott > wrote: > > Hi Ilari, > > Thanks for the comments. > > Assuming the client sends a valid certificate that the server > accepts, then the server cannot finish the handshake or begin > processing incoming application data until authenticating the > client. This *almost* gives us property (A). In practice, the > client is aware that the server has successfully authenticated > since the protocol continues. > > In the case that the server has implemented the reject option > (rejecting a certificate but still continuing), and indeed > rejects the certificate, then the server should send an alert > message (or NAK of some form) for the property to hold in the > initial handshake. > > However, even if we take the certificate reject + continue > scenario into account for the initial handshake, then it is > clear that this decision can only be made by the server in the > initial handshake, while in the post-handshake client auth, an > attacker can decide this (by dropping the message). > > The reason we don't believe an explicit ACK is needed is > because upgrading to a new pair of keys explicitly provides > this. Specifically, the client will send all subsequent data > to the server under a new key. The server will not be able to > decrypt this data until they receive the client authentication > messages and upgrade the keys. > > This can be strengthened if the client's updated write key is > computed using the authentication messages. > > We agree that TLS enforcing ordering of messages provides > similar guarantees. However, we are analysing the > specification as it is presented, which does not guarantee this. > > Thanks, > > Sam > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------DF7E5870FD3AB5A7C14D3E2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Is it common that 0.5 RTT data will be sent by the server in a fresh session? I.e. not after a resumption and therefore without the client previously sending early data?

Even so, it does also seem like a slightly troubling scenario, since the client has no (in-band) mechanism to determine the authentication was successful (or even at what point it arrived). Again, this could be rectified by forcing the client/server to update their keys, and even better if they include the client's authentication messages.

However, NewSessionTicket messages do not have this problem since the server wont send these before processing the client Finished, but it could still be an issue in the post-hs scenario.

Just want to reiterate: thanks all for helping to clarify this behaviour we've encountered. Hopefully it proves a useful insight into the guarantees (or lack thereof) provided  by client authentication. Also it is really useful in helping us to refine our model :)

Sam

On 11/02/17 01:49, Andrei Popov wrote:

What about Eric’s other point:

Ø  I am not sure that the regular TLS handshake guarantees these

Ø  properties either. The reason is that the server is permitted to

Ø  send data prior to receiving the client's second flight (0.5 RTT

Ø  data).

 

With the server sending data prior to receiving the client’s second flight, it seems that property B is not there when using in-handshake client authentication as well?

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sam Scott
Sent: Friday, February 10, 2017 12:53 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

 

Hi Ekr,

That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it does still seem to be an issue.

As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel.

Thanks,

Sam

On 10/02/17 20:39, Eric Rescorla wrote:

Cas, Sam,

 

I thought I understood your concern here but maybe I don't.

 

Say we have the following sequence of messages

 

  1. C->S: ClientHello 

  2. S->C: ServerHello...ServerFinished

  3. C->S: ClientFinished

  4. C->S: App message

  5. S->C: App message

  6. S->C: CertificateRequest

  7: C->S: Certificate...Finished

  8: C->S: App message

  9: S->C: App message

  

As you indicate, there's some ambiguity from the client's perspective

(property B) about whether messages 5 and 9 were sent by the server

prior to or after receiving message 7, and also message 8. This

ambiguity exists even without an attacker and may or may not be

resolved at the application layer. An attacker can exploit this

ambiguity by holding messages 7 and 8 and (as long as application

semantics permit this).

 

Where I get confused is about property A. As I understand your

claim, an attacker can hold message 7 but deliver message 8 and

therefore, even if the client knows that 9 was in response to 8,

he doesn't know that the server received 7. As Ilari says, I don't

believe that this is correct because TLS enforces message ordering.

I agree that the specification doesn't explicitly say this, but

it's implicit in the processing rules via the following:

 

1. The encryption for each TLS record depends on the record sequence

   number (RSN).

2. Records do not carry their RSN, so when you decrypt a message, you

   must use the last RSN + 1

3. When you fail to decrypt a message (which is what happens if you have

   the wrong RSN) you are required to tear down the connection

 

For this reason, if the attacker removes message 7, then 8 will not

be decryptable, and so ordering is preserved. As Ilari says, this isn't

true in DTLS 1.3 which we'll presumably have to deal with one way

or the other before standardization (my plan would be just to forbid

post-handshake auth). Do you disagree with this? If so, perhaps you

could explain.

 

-Ekr

 

P.S. I am not sure that the regular TLS handshake guarantees these

properties either. The reason is that the server is permitted to

send data prior to receiving the client's second flight (0.5 RTT

data). See:

 

 

 

 

 

On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <sam.scott89@gmail.com> wrote:

Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this.

Thanks,

Sam



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

 

 


--------------DF7E5870FD3AB5A7C14D3E2A-- From nobody Sat Feb 11 11:20: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 0ECB9129457 for ; Sat, 11 Feb 2017 11:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 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, 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=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 5vmMAZxJhjfR for ; Sat, 11 Feb 2017 11:20:43 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 D0E7812941A for ; Sat, 11 Feb 2017 11:20:42 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u68so36023316ywg.0 for ; Sat, 11 Feb 2017 11:20:42 -0800 (PST) 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=2ICBtsRQV6ASjNSzzBFx9NTvdYZKAwYgiWSSCYUulaM=; b=IN9ev8yZxgfsNHcFfYpqUToaoY82BNi6DC8qXAumhi188lz4SJHWuSacToK4fgbbqo RqPzm/pPiXJYkYTq169NJ4Tg8yv2X+EqyfM4NqJ8bSNVePgPTCe2bZznDLjYwDXk35Or xNPOX/QBprom9hvPGMJ5w6ud4exKGFdQp9y9Eq1GnYC+N1OH4EBH29yDvnviQXopxSTt BcegFr/FC1sZEtCzbE3kNWaoUF8aSjjJMug0PjDEaN1xTUd30TVDtK4gQULI2bEJ1fkW koj73rWXD8i5iRJbFQ2An5+p/MFlF1EeCe513s911ykw82TpUdMsns0RL+AajUDFiDa+ tIJg== 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=2ICBtsRQV6ASjNSzzBFx9NTvdYZKAwYgiWSSCYUulaM=; b=avgEbkIOvYM6Dt9dXNPYWL4nuf8wF9NH9ic8wi9Tz54KzfY78kvsOfRg4rBIeW0AwP RiA+ED4JIPglTvdLorafvi/NosPmJFD+ayP7wPt/+E5Vt33O1MiS3xkZi/7zjD/H8Ztq Ox7w4T2hmwYrTGTW96n6yRqP66gOwjFKb5p5CL5W82DadmIp9Z4K9/saSzE/qZEEnV2W +c4mwjZVoRLFhF3kbqd6CRfgLmG6ZRTPRgtv8mA9dPfqN3bltFwWqnGzfkToSKTC/nJP HzELTDBaIIzYCnEWLh+aG4KcTqNQ1iGLi0sk32CUsBB5k2DgjdRBgrWHdX4u7p7Y0KYG NvPw== X-Gm-Message-State: AMke39nlChhWy5XclP/dcluLlLQJ5ahm7ey93G2Y25fO3ooN/qFmbP+G1Z8LMxfG7SM4n2YYDm7O/DLXFof36Q== X-Received: by 10.129.162.130 with SMTP id z124mr12003806ywg.276.1486840842003; Sat, 11 Feb 2017 11:20:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sat, 11 Feb 2017 11:20:01 -0800 (PST) In-Reply-To: <304937cb-ca58-d4aa-a731-fd1498848637@gmail.com> References: <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> <304937cb-ca58-d4aa-a731-fd1498848637@gmail.com> From: Eric Rescorla Date: Sat, 11 Feb 2017 11:20:01 -0800 Message-ID: To: Sam Scott Content-Type: multipart/alternative; boundary=94eb2c12929239d4c60548461c3c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 19:20:46 -0000 --94eb2c12929239d4c60548461c3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 11, 2017 at 6:52 AM, Sam Scott wrote: > Is it common that 0.5 RTT data will be sent by the server in a fresh > session? I.e. not after a resumption and therefore without the client > previously sending early data? > Yes, I think it will be, especially in cases where the server says the same thing to every client (e.g., HTTP settings frames). Probably a less often in cases where the initial handshake will demand client auth. Even so, it does also seem like a slightly troubling scenario, since the > client has no (in-band) mechanism to determine the authentication was > successful (or even at what point it arrived). Again, this could be > rectified by forcing the client/server to update their keys, and even > better if they include the client's authentication messages. > > However, NewSessionTicket messages do not have this problem since the > server wont send these before processing the client Finished, > Specifically: the EMS is derived from the client's entire transcript through the client's Finished, so you can't compute it until then. but it could still be an issue in the post-hs scenario. > Yes, NST is asynchronous wrt post-handshake auth, just like app data messages. -Ekr > Just want to reiterate: thanks all for helping to clarify this behaviour > we've encountered. Hopefully it proves a useful insight into the guarante= es > (or lack thereof) provided by client authentication. Also it is really > useful in helping us to refine our model :) > > Sam > > > On 11/02/17 01:49, Andrei Popov wrote: > > What about Eric=E2=80=99s other point: > > =C3=98 I am not sure that the regular TLS handshake guarantees these > > =C3=98 properties either. The reason is that the server is permitted to > > =C3=98 send data prior to receiving the client's second flight (0.5 RTT > > =C3=98 data). > > > > With the server sending data prior to receiving the client=E2=80=99s seco= nd > flight, it seems that property B is not there when using in-handshake > client authentication as well? > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org ] *On > Behalf Of *Sam Scott > *Sent:* Friday, February 10, 2017 12:53 PM > *To:* Eric Rescorla > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Awkward Handshake: Possible mismatch of > client/server view on client authentication in post-handshake mode in > Revision 18 > > > > Hi Ekr, > > That's a good summary of the situation. Indeed we weren't previously > considering TLS as able to enforce the ordering of messages which does se= em > to mitigate our scenario for property A. We haven't really had a chance t= o > take that into consideration for property B, but at a glance it does stil= l > seem to be an issue. > > As mentioned in my other email, one scenario we encountered this was if > (using your message numbering as reference) messages 5 or 9 happened to b= e > a NewSessionTicket. In this case, the client might be under the impressio= n > that they have a session ticket for a mutually authenticated channel. > > Thanks, > > Sam > > On 10/02/17 20:39, Eric Rescorla wrote: > > Cas, Sam, > > > > I thought I understood your concern here but maybe I don't. > > > > Say we have the following sequence of messages > > > > 1. C->S: ClientHello > > 2. S->C: ServerHello...ServerFinished > > 3. C->S: ClientFinished > > 4. C->S: App message > > 5. S->C: App message > > 6. S->C: CertificateRequest > > 7: C->S: Certificate...Finished > > 8: C->S: App message > > 9: S->C: App message > > > > As you indicate, there's some ambiguity from the client's perspective > > (property B) about whether messages 5 and 9 were sent by the server > > prior to or after receiving message 7, and also message 8. This > > ambiguity exists even without an attacker and may or may not be > > resolved at the application layer. An attacker can exploit this > > ambiguity by holding messages 7 and 8 and (as long as application > > semantics permit this). > > > > Where I get confused is about property A. As I understand your > > claim, an attacker can hold message 7 but deliver message 8 and > > therefore, even if the client knows that 9 was in response to 8, > > he doesn't know that the server received 7. As Ilari says, I don't > > believe that this is correct because TLS enforces message ordering. > > I agree that the specification doesn't explicitly say this, but > > it's implicit in the processing rules via the following: > > > > 1. The encryption for each TLS record depends on the record sequence > > number (RSN). > > 2. Records do not carry their RSN, so when you decrypt a message, you > > must use the last RSN + 1 > > 3. When you fail to decrypt a message (which is what happens if you have > > the wrong RSN) you are required to tear down the connection > > (https://tlswg.github.io/tls13-spec/#record-payload-protection). > > > > For this reason, if the attacker removes message 7, then 8 will not > > be decryptable, and so ordering is preserved. As Ilari says, this isn't > > true in DTLS 1.3 which we'll presumably have to deal with one way > > or the other before standardization (my plan would be just to forbid > > post-handshake auth). Do you disagree with this? If so, perhaps you > > could explain. > > > > -Ekr > > > > P.S. I am not sure that the regular TLS handshake guarantees these > > properties either. The reason is that the server is permitted to > > send data prior to receiving the client's second flight (0.5 RTT > > data). See: > > https://tlswg.github.io/tls13-spec/#protocol-overview > > > > > > > > > > > > On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott wrote= : > > Hi Ilari, > > Thanks for the comments. > > Assuming the client sends a valid certificate that the server accepts, > then the server cannot finish the handshake or begin processing incoming > application data until authenticating the client. This *almost* gives us > property (A). In practice, the client is aware that the server has > successfully authenticated since the protocol continues. > > In the case that the server has implemented the reject option (rejecting = a > certificate but still continuing), and indeed rejects the certificate, th= en > the server should send an alert message (or NAK of some form) for the > property to hold in the initial handshake. > > However, even if we take the certificate reject + continue scenario into > account for the initial handshake, then it is clear that this decision ca= n > only be made by the server in the initial handshake, while in the > post-handshake client auth, an attacker can decide this (by dropping the > message). > > The reason we don't believe an explicit ACK is needed is because upgradin= g > to a new pair of keys explicitly provides this. Specifically, the client > will send all subsequent data to the server under a new key. The server > will not be able to decrypt this data until they receive the client > authentication messages and upgrade the keys. > > This can be strengthened if the client's updated write key is computed > using the authentication messages. > > We agree that TLS enforcing ordering of messages provides similar > guarantees. However, we are analysing the specification as it is presente= d, > which does not guarantee this. > > Thanks, > > Sam > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > > > --94eb2c12929239d4c60548461c3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 11, 2017 at 6:52 AM, Sam Scott <sam.scott89@gmail.com<= /a>> wrote:
=20 =20 =20
Is it common that 0.5 RTT data will be sent by the server in a fresh session? I.e. not after a resumption and therefore without the client previously sending early data?

<= /div>
Yes, I think it will be, especially in cases where the server say= s the same thing to every client (e.g., HTTP settings frames).
Pr= obably a less often in cases where the initial handshake will demand client= auth.


Even so, it does also seem like a slightly troubling scenario, since the client has no (in-band) mechanism to determine the authentication was successful (or even at what point it arrived). Again, this could be rectified by forcing the client/server to update their keys, and even better if they include the client's authentication messages.

However, NewSessionTicket messages do not have this problem since the server wont send these before processing the client Finished,

Specifically: the EMS is derived fro= m the client's entire transcript through the client's Finished, so = you can't compute it until then.


b= ut it could still be an issue in the post-hs scenario.

Yes, NST is asynchronous wrt post-handshake auth, jus= t like app data messages.

-Ekr


Just want to reiterate: thanks all for helping to clarify this behaviour we've encountered. Hopefully it proves a useful insight into the guarantees (or lack thereof) provided=C2=A0 by client authentication. Also it is really useful in helping us to refine our model :)

Sam


On 11/02/17 01:49, Andrei Popov wrote:
=20 =20 =20

What about Eric=E2=80=99s other point:

=C3=98=C2= =A0 I am not sure that the regular TLS handshake guarantees these

=C3=98=C2= =A0 properties either. The reason is that the server is permitted to

=C3=98=C2= =A0 send data prior to receiving the client's second flight (0.5 RTT

=C3=98=C2= =A0 data).

=C2=A0

With the server sending data prior to receiving the client=E2=80=99s second flight, it seems that property B is not there when using in-handshake client authentication as well?=

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sam Scott
Sent: Friday, February 10, 2017 12:53 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18<= /p>

=C2=A0

Hi Ekr,

That's a good summary of the situation. Indeed we weren'= t previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it does still seem to be an issue.

As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel.<= /u>

Thanks,

Sam

On 10/02/17 20:39, Eric Rescorla wrote:=

Cas, Sam,

=C2=A0

I thought I understood your concern here but maybe I don't.

=C2=A0

Say we have the following sequence of messages

=C2=A0

=C2=A0 1. C->S: ClientHello=C2=A0

=C2=A0 2. S->C: ServerHello...ServerFinished

=C2=A0 3. C->S: ClientFinished

=C2=A0 4. C->S: App message<= u>

=C2=A0 5. S->C: App message<= u>

=C2=A0 6. S->C: CertificateRequest<= u>

=C2=A0 7: C->S: Certificate...Finis= hed

=C2=A0 8: C->S: App message<= u>

=C2=A0 9: S->C: App message<= u>

=C2=A0=C2=A0

As you indicate, there's some ambiguity from the client's perspective

(property B) about whether messages 5 and 9 were sent by the server

prior to or after receiving message 7, and also message 8. This

ambiguity exists even without an attacker and may or may not be

resolved at the application layer. An attacker can exploit this

ambiguity by holding messages 7 and 8 and (as long as application

semantics permit this).<= /p>

=C2=A0

Where I get confused is about property A. As I understand your

claim, an attacker can hold message 7 but deliver message 8 and

therefore, even if the client knows that 9 was in response to 8,

he doesn't know that the server received 7. As Ilari says, I don't

believe that this is correct because TLS enforces message ordering.

I agree that the specification doesn't explicitly say this, but

it's implicit in the processing ru= les via the following:

=C2=A0

1. The encryption for each TLS record depends on the record sequence

=C2=A0 =C2=A0number (RSN).

2. Records do not carry their RSN, so when you decrypt a message, you

=C2=A0 =C2=A0must use the last RSN + 1=

3. When you fail to decrypt a message (which is what happens if you have

=C2=A0 =C2=A0the wrong RSN) you are re= quired to tear down the connection

=C2=A0

For this reason, if the attacker removes message 7, then 8 will not

be decryptable, and so ordering is preserved. As Ilari says, this isn't

true in DTLS 1.3 which we'll presumably have to deal with one way

or the other before standardization (my plan would be just to forbid

post-handshake auth). Do you disagree with this? If so, perhaps you

could explain.

=C2=A0

-Ekr

=C2=A0

P.S. I am not sure that the regular TLS handshake guarantees these

properties either. The reason is that the server is permitted to

send data prior to receiving the client's second flight (0.5 RTT

data). See:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <sam.scott89@gmail.com> wrote:

Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this.

Thanks,

Sam



______________________________________________= _
TLS mailing list
T= LS@ietf.org
https://www.ietf.org/mailman/listinfo/tls<= /u>

=C2=A0

=C2=A0



--94eb2c12929239d4c60548461c3c-- From nobody Mon Feb 13 04:33: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 DB104129621 for ; Mon, 13 Feb 2017 04:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 cQqBlYl3nYw4 for ; Mon, 13 Feb 2017 04:33:16 -0800 (PST) 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 DE3F3129628 for ; Mon, 13 Feb 2017 04:33:15 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id z134so49355648lff.3 for ; Mon, 13 Feb 2017 04:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=B+KwyAzUTcpyqJVAk4fQtEnPo36UFfLzOOS/+rZBPxc=; b=FSWawvmO/6RLXs5QZMHBE8HlzQYqgBfwTBeS6D/YrTQsr7DFBzhmyWpsJUHICEncty nALYH+atLepiXNnod3issSq3b9zZ/Wj3wm11Qen/BAFVVOpF5mCKDQ14u50rx6Cg6u+h ej7rTx+3g5eCbC3XD66UAmBAdSWRELOeMcbFP0/Z4ObEOp+b/wevdvojMM30ecRddsRd cidvPCGWk3LGWJoOnZLvrf7ferMpF4BDun5f21XbvuyUDeko5LH1A0gy1klHkL5KmTY7 Cr3WzHDmQHz2YKsiQ6RxwrQGkF1VFCC3hEKbQT0RJPUUR8ShGdH2EWHbydRkkqplWxM4 /Thg== 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:from:date:message-id:subject :to:cc; bh=B+KwyAzUTcpyqJVAk4fQtEnPo36UFfLzOOS/+rZBPxc=; b=mA3A2pgbO+t72bLuVPojikTzxIIl3oYIenDPKcMTzdDXmbJdSrQ5PnrnSi/r7TvJdH F8DkJRDQp8uHR0+RPWT+VLRgP0EkMKtGfxyOKNnxUN28Ob11SKbStkTbKQx5WNIZQNeM t8ty1yUtQu//sToUYPxilSQPPn/4KzT+6Mrwhx9phfKrgkCDSD6hbUNXQoGXViHgi1oq jCLLGI7GQqA7sBxFcwxH2LoePCATCKMrOVRm8O6/X4onWs/3qaY310pXe5IHFW5iCrzR kgWSxV/6a8ytIyNUXi3QFuS5R3eQSV0rkMiN7JYqfiDAva2dCvB0wSaUgrawKq4UMX04 xCUw== X-Gm-Message-State: AMke39mnEtZLuxCLxbMTPElE+mqbW0MxTkIDYsyhxzO87zc5NEd9e9J+aAVaX21A6DfMpHYoNL0iUz94aiQdIg== X-Received: by 10.25.87.5 with SMTP id l5mr6200171lfb.87.1486989194068; Mon, 13 Feb 2017 04:33:14 -0800 (PST) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.46.0.164 with HTTP; Mon, 13 Feb 2017 04:32:53 -0800 (PST) From: Cas Cremers Date: Mon, 13 Feb 2017 12:32:53 +0000 X-Google-Sender-Auth: FVD7uBrCKksg0sMJcYx09sBXjBs Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11425058b28c6b054868a617 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 12:33:18 -0000 --001a11425058b28c6b054868a617 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks everyone, we will try to wrap up the situation and remaining issues. TL;DR: The problem that we identified applies to fewer situations in the real protocol than we thought, because of our previously coarse modelling of the AEAD. However, the main issue remains: the client never receives an in-band confirmation that the client authentication has succeeded. From a formal perspective this means there can be a mismatch between the view of the client and the server. We suggest this is made explicit in the security guarantees section. Furthermore, supposing the client has a way to determine whether authentication was successful, there still exists the possibility that the client receives messages whose context is ambiguous. In more detail: 1. Ordering of messages, which is enforced by the AEAD, means that property (A) we discussed is not an issue. The client knows that any message sent after the certificate will arrive (be processed) at the server after the certificate. 2. Property (B) is still an open issue for both the initial handshake and post-handshake. Application messages sent by the server can easily be delayed (by network or adversary) and the client cannot determine whether this message was sent before or after the authentication was received and therefore under the assumption that the client is an authenticated peer or not. 3. There is a small asymmetry between the initial handshake and post-handshake. If the client authenticates in the initial handshake, receiving post-handshake messages (such as a NewSessionTicket), must come after the client's certificate/finished is processed. This is enfor= ced cryptographically since the RMS is computed using the Finished messages.= In contrast, NST messages can arrive ambiguously before/after a post-handsh= ake client authentication. The main takeaway is that the client never really receives any acknowledgement of whether the verification provided was successful or rejected through an in-band mechanism. The context of the keys does not include the client=E2=80=99s authenticatio= n status (nor the client=E2=80=99s certificate), and is the same in both cases. From= a formal analysis point of view, this results in a mismatch where the client and server may not agree on the mutual authentication status, which is the main point we wanted to raise. Assuming now that the key context will not be changed, we suggest to explicitly mention in the security guarantees section that the client, after sending authentication messages, cannot be sure at any point that the server has received these messages and considers the connection to be mutually authenticated. If the client wishes to obtain such a guarantee, it has to be informed by the server=E2=80=99s application. Best, Cas Cremers, Marko Horvat, Jonathan Hoyland, Thyla van der Merwe, and Sam Scott --001a11425058b28c6b054868a617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks everyone, we will try to wrap up the situation and = remaining issues.
=C2=A0=C2=A0
TL;DR:
The problem = that we identified applies to fewer situations in the real protocol than we= thought, because of our previously coarse modelling of the A= EAD. However, the main issue remains: the client never receives an in-band = confirmation that the client authentication has succeeded. From a formal pe= rspective this means there can be a mismatch between the view of the client= and the server. We suggest this is made explicit in the security guarantee= s section.

Furthermore, supposing the client= has a way to determine whether authentication was successful, there still = exists the possibility that the client receives messages whose contex= t is ambiguous. In more detail:
  1. Ordering of messages, which is enforced by the AEAD,= means that property (A) we discussed is not an issue. The client knows that any message s= ent after the certificate will arrive (be processed) at the = server after the certificate.
  2. Pr= operty (B) is s= till an open issue for both the initial handshake and post-handshake. Applicatio= n messages sent by the server can easily be delayed by network or adversary) and the clie= nt cannot determine whether this message= was sent before or after the authentication was received and therefore under the assumption that the client is an = authenticated peer or not.
  3. There is a small asymmetry between= the initial handshake and post-handshake. If the client authenticates in t= he initial handshake, receiving post-handshake messages (such as a NewSessionTicket), must come afte= r the client's certificate/finished is processed. This is enforced cryp= tographically since the RMS is computed using the Finished messages. In con= trast, NST messages can arrive ambiguously before/after a post-handshake cl= ient authentication.
The main takeaway is that the clie= nt never really receives any acknowledgement of whether the verification pr= ovided was successful or rejected through an in-band mechanism.=C2=A0

The context of the keys does not incl= ude the client=E2=80=99s authentication status = (nor the client=E2=80=99s certificate), and is the same= in both cases. From a formal analysis point of view, this results in a mis= match where the client and server may not agree on the mutual authenticatio= n status, which is the main point we wanted to raise.

=
Assuming now that the key context will not be changed, we suggest= to explicitly mention in the security guarantees section that the client, = after sending authentication messages, cannot be sure at any point that the= server has received these messages and considers the connection to be mutu= ally authenticated. If the client wishes to obtain such a guarantee, it has= to be informed by the server=E2=80=99s application.

<= /div>
Best,

Cas Cremers,
= Marko Horvat,
Jonathan Hoyland,
Thyla van d= er Merwe, and
Sam Scott


--001a11425058b28c6b054868a617-- From nobody Mon Feb 13 07:34: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 9158812961D for ; Mon, 13 Feb 2017 07:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=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 rTjVCl5hgPzR for ; Mon, 13 Feb 2017 07:34:18 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40111.outbound.protection.outlook.com [40.107.4.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4552A1296D1 for ; Mon, 13 Feb 2017 07:34:18 -0800 (PST) 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=23HkHZCUTFwnOxgymY1McYFkhnuINf3RQvo2WVHN/Zw=; b=COtoIi2/ja2maY4SQrlTq4dvR3gbjRqmRqoEx8qh5ciZxfwu55kBBTiV8FDDeE3RRBLsNYLkbvwB+F9wL/gf0ohzc8QMgrLXGEj2xnHSBn87O8l6ygAzKFF5k/jZsgs+AVC4UMNJ4V+ru5+OjJRdiZomKZpyk39F5FvHkb2hg0Q= Received: from VI1PR8303MB0094.EURPRD83.prod.outlook.com (129.75.141.89) by VI1PR83MB0046.EURPRD83.prod.outlook.com (129.75.21.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.0; Mon, 13 Feb 2017 15:34:13 +0000 Received: from VI1PR8303MB0094.EURPRD83.prod.outlook.com ([129.75.141.89]) by VI1PR8303MB0094.EURPRD83.prod.outlook.com ([129.75.141.89]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 15:34:14 +0000 From: Markulf Kohlweiss To: "Paterson, Kenny" , Sean Turner Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHSg1ujogZD2gIXgUWLhmF3SGaRd6FhuukAgAA4M4CABSHOcA== Date: Mon, 13 Feb 2017 15:34:13 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=markulf@microsoft.com; x-originating-ip: [2a01:110:8012:1010::6b0] x-ms-office365-filtering-correlation-id: b3f80bdb-6e7d-4284-eb95-08d45425c3b4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR83MB0046; x-microsoft-exchange-diagnostics: 1; VI1PR83MB0046; 7:F/lm1bTOHd04jyv8txdnKsrVy8KnMEw1YtKA67W4uB/x/8rX1XQXw1hGadK5+XsSf4fh9E7X1XRMwFkxTv/pHgUs5TL7B+LWOBqoJ2Y2aHVN2AgFthTV9KHh2uSfZdj3fV58MHx44XQa3PKX6fGAsD5CFha4iFJqeQJI+GCkYlsnTsh/8s7H2hOfhhzWicdvJ5BMBV90UJLqg+Xuxir2bcuuYcUyH16Gd6/R++tQ3t3pRlFsjC0t8GZeHn1bKTGUI9MEsbBKDl7gTyephEWQVFRIhRBRmjRxvsa3s+SiNe8u8PGd1nhJ1NXRLYW28P+s2kEfOkHEq7v7prKe0W3L5PRlei6xN6ISKa872nAqoAtU/bGJo6AU0eyoZ9DDstx8Tscvm2XAvhqYDj3gtP4qtZc/EaKBYAwRRRcrufVNso2+qnHdgTm8kCVE2tRMDtLSBG0lJUSuk4TBa+K7ptH37JlwDFcFFqh9Rt/PPZa+JcJgmip1zY3cj8d14CvzffiTlz+B3pRBgT2nEoYXcfi5zkqt4d2ikKj2F76zHOThXVw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:VI1PR83MB0046; BCL:0; PCL:0; RULEID:; SRVR:VI1PR83MB0046; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(189002)(24454002)(199003)(8936002)(4326007)(53936002)(55016002)(9686003)(105586002)(25786008)(99286003)(8656002)(6306002)(81166006)(2906002)(54906002)(6436002)(81156014)(6246003)(92566002)(5005710100001)(33656002)(2900100001)(107886003)(10090500001)(38730400002)(189998001)(10290500002)(86612001)(86362001)(97736004)(305945005)(76176999)(3280700002)(229853002)(68736007)(101416001)(106116001)(106356001)(54356999)(8990500004)(74316002)(6116002)(102836003)(2950100002)(7696004)(7736002)(3660700001)(8676002)(122556002)(6506006)(5660300001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR83MB0046; H:VI1PR8303MB0094.EURPRD83.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 13 Feb 2017 15:34:13.4004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR83MB0046 Archived-At: Cc: Antoine Delignat-Lavaud , IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:34:20 -0000 Hello, Our analysis of miTLS also supports option a) A security level of 2^-32 seems too low from a provable security point of v= iew, especially for a confidentiality bound. We verified an implementation of the TLS 1.3 record (https://eprint.iacr.or= g/2016/1178, to appear at Security & Privacy 2017) where we arrive at a com= bined bound for authenticity and confidentiality that is compatible with th= e Iwata et al. bound. Regards, Markulf (for the miTLS team) >Hi, > >My preference is to go with the existing text, option a). > >From the github discussion, I think option c) involves a less conservative >security bound (success probability for IND-CPA attacker bounded by >2^{-32} instead of 2^{-60}). I can live with that, but the WG should be >aware of the weaker security guarantees it provides. > >I do not understand option b). It seems to rely on an analysis of >collisions of ciphertext blocks rather than the established security proof >for AES-GCM. > >Regards, > >Kenny > >On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson" > wrote: > >>On 10 February 2017 at 16:07, Sean Turner wrote: >>> a) Close these two PRs and go with the existing text [0] >>> b) Adopt PR#765 [1] >>> c) Adopt PR#769 [2] >> >> >>a) I'm happy enough with the current text (I've implemented that any >>it's relatively easy). >> >>I could live with c, but I'm opposed to b. It just doesn't make sense. >>It's not obviously wrong any more, but the way it is written it is >>very confusing and easily open to misinterpretation. >> >>_______________________________________________ >>Cfrg mailing list >>Cfrg at irtf.org >>https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Feb 13 07:45: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 365F91296D0 for ; Mon, 13 Feb 2017 07:45:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.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 9lQSb4DfTG0Y for ; Mon, 13 Feb 2017 07:45:38 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9892B129454 for ; Mon, 13 Feb 2017 07:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PEgXnkS6fbjEzVpHjWRT5rK4sG/KCMbb7/b6CYh4uFE=; b=yDa3F2D6SIeGIpLT1vTr0C/B4omejZZrVnt3HPhunTIq24zQIZEdlDDACabTbzPOUgMuiRXItWJ+6gCjNUTPWtVlbR85rynOFv+nxMzXMBSnXb8SP817kKn/vVjauwu0N5PsxkEtoUkmEYrhNOEXRBFDwcuUlZe/Ti8FXHiViYo= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 15:45:36 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 15:45:36 +0000 From: "Dang, Quynh (Fed)" To: Markulf Kohlweiss , "Paterson, Kenny" , Sean Turner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbA== Date: Mon, 13 Feb 2017 15:45:36 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: f7b0ab25-26bf-46e1-53b3-08d454275ab3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:8T+8msbGNuDrd10T6Ky1UDdKdh8Y0kNlYdOTx3Wqh/B494AqmlmvDdzltkSRf06tcKMt1Wsf0jafjQqPLlmXAL4Yd0hvhwhfBcWwsLduwpyjCzVEsEla3ltvAQfeJv1tbZKTQrUUJIG0e5tsjIwcehysu6gmms+FHwQXfMLUt7I4hpyiT+dh8sOuGnxN3HgTioN989O1wjDPNAER8w1Gb0CUDw8QplVecsMNrBw+FlSzkAFWhd08iSbuF+cTykRq2O5VXbybej+sus3Phw6IJjwGW1NSxTIl8HS2ktRHVyMnHl1z/hyTK1lg9u/IAIEcy+3X1wyhRtOPrY01I2vxdiPPLB4ZPOmoKmy0Sg47haQ2/e9sZ+SKR07e3HqklHWRylriiNJOIU0dpZI4lxRHH2IIwvYi/VPrvS1xCkZ1qMDNk4ywhR6JblHUq9bDFmzP5i+sRw8I8lROModUKNX7zJUQhAR2CC4blo0QaR/9a6uFk9tSsTVP2CX885pJq0lnjBcdsCfpBXqaxZN/L305UA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(189002)(199003)(377454003)(24454002)(25786008)(2561002)(66066001)(97736004)(6306002)(8936002)(3660700001)(122556002)(54896002)(2421001)(236005)(6512007)(105586002)(4001350100001)(6246003)(5660300001)(606005)(2900100001)(8666007)(83506001)(8656002)(7906003)(53546003)(38730400002)(1511001)(77096006)(7736002)(6486002)(6436002)(6506006)(2950100002)(68736007)(93886004)(54356999)(189998001)(76176999)(50986999)(99286003)(229853002)(101416001)(54906002)(3280700002)(2906002)(92566002)(81166006)(81156014)(102836003)(106116001)(8676002)(106356001)(36756003)(53936002)(3846002)(6116002)(4326007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4C73D192FB4Bqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 15:45:36.6740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463 Archived-At: Cc: Antoine Delignat-Lavaud , IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:45:41 -0000 --_000_D4C73D192FB4Bqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Markulf, The probability of a bad thing to happen is actually below (or about) 2^(-3= 3). It practically won=92t happen when the chance is 1 in 2^32. And, to ach= ieve that chance, you must collect 2^48 128-bit blocks. Regards, Quynh. From: TLS > on behalf of = Markulf Kohlweiss > Date: Monday, February 13, 2017 at 10:34 AM To: "Paterson, Kenny" >, Sean Turner > Cc: Antoine Delignat-Lavaud >, IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Hello, Our analysis of miTLS also supports option a) A security level of 2^-32 seems too low from a provable security point of v= iew, especially for a confidentiality bound. We verified an implementation of the TLS 1.3 record (https://eprint.iacr.or= g/2016/1178, to appear at Security & Privacy 2017) where we arrive at a com= bined bound for authenticity and confidentiality that is compatible with th= e Iwata et al. bound. Regards, Markulf (for the miTLS team) Hi, My preference is to go with the existing text, option a). >From the github discussion, I think option c) involves a less conservative security bound (success probability for IND-CPA attacker bounded by 2^{-32} instead of 2^{-60}). I can live with that, but the WG should be aware of the weaker security guarantees it provides. I do not understand option b). It seems to rely on an analysis of collisions of ciphertext blocks rather than the established security proof for AES-GCM. Regards, Kenny On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson" wrote: On 10 February 2017 at 16:07, Sean Turner wrote: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] a) I'm happy enough with the current text (I've implemented that any it's relatively easy). I could live with c, but I'm opposed to b. It just doesn't make sense. It's not obviously wrong any more, but the way it is written it is very confusing and easily open to misinterpretation. _______________________________________________ Cfrg mailing list Cfrg at irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_D4C73D192FB4Bqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Markulf,

The probability of a bad thing to happen is actually below (or about) = 2^(-33). It practically won=92t happen when the chance is 1 in 2^32. And, t= o achieve that chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh. 

From: TLS <tls-bounces@ietf.org> on behalf of Markulf Kohlwe= iss <markulf@microsoft.com&= gt;
Date: Monday, February 13, 2017 at = 10:34 AM
To: "Paterson, Kenny" <= ;Kenny.Paterson@rhul.ac.uk= >, Sean Turner <sean@sn3rd.com&= gt;
Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG = <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point= of view, especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record (https://eprint.iacr.org/2016/1178, to appe= ar at Security & Privacy 2017) where we arrive at a combined bound for = authenticity and confidentiality that is compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

From the github discussion, I think option c) involves a less conserva= tive
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should b= e
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security p= roof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&= gt; wrote:

On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr= ote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.=
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

_______________________________________________
Cfrg mailing list
Cfrg at irtf.org

_______________________________________________
TLS mailing list

 --_000_D4C73D192FB4Bqdangnistgov_-- From nobody Mon Feb 13 08:05: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 9257C12961D for ; Mon, 13 Feb 2017 08:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 AsBjfxSCpSAf for ; Mon, 13 Feb 2017 08:05:15 -0800 (PST) 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 0391A12951B for ; Mon, 13 Feb 2017 08:05:14 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so86985170qtc.2 for ; Mon, 13 Feb 2017 08:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=bbBRXXLvn7vptD5y77NeZyGFlI4m/QoL7J6dX0gDAQQ=; b=Tc0yUT/VrnLHK9UN08mYOVwxXR1ZNjgnC2KuEqs/Ixo8tgmA4de6bzl/rjyEwXlMVX HshdztbrC+Z+b2WzjjIpAZq17mVRDw+DSqrRNq/FCqIwExH1ZHmnVcwG6sfVXVGv3+5b tH230cY5QjazxaPMo7rTyXoX/y7TxVprsPxzc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=bbBRXXLvn7vptD5y77NeZyGFlI4m/QoL7J6dX0gDAQQ=; b=GLGjy0ijH3/7SgFdDvWmg9aijvy076pCLQhTcAXNmfVqJR1y8ASOdUJGKmWESCeQiJ uuotlCp0S6b//Wiu6xFSBPR9AUx4K6UnBQg9/w3NdADKg+wSEq3/wAnYPYWLbTbfHb0l dpMScrjMlz4+C0R5cx6uMxQlnC+Jmf87vCoygQa5znNJQ9Pst7KTQTSJ+ibA2PSVKu+W nzdmNqVO4qu4c9cTv0GWP1fF3bR5mcsiCFgv/Vmr4Vo0XIXKgkorf1OML4YAAi9KQDEo QWaCJZDnl91zEXHWvbQvT4ovH1I9ydD4xHr/QeNkyvywKzj1KZBeGkwzdaF7Zq2wvbcB i3qw== X-Gm-Message-State: AMke39nz3c/KnIdWPaZKzFVp4FXo5r2UazJujRzMIu633d9lEu7C89hrMFIqsbCy8sTWpA== X-Received: by 10.200.45.5 with SMTP id n5mr21110589qta.174.1487001913776; Mon, 13 Feb 2017 08:05:13 -0800 (PST) Received: from [172.16.0.18] ([96.231.219.116]) by smtp.gmail.com with ESMTPSA id d191sm7780071qke.15.2017.02.13.08.05.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 08:05:12 -0800 (PST) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_D9FB1E04-76FF-4F2A-82ED-4AA4565B9952" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <86683505-B748-4496-BE5C-5177A3DF012C@sn3rd.com> Date: Mon, 13 Feb 2017 11:05:10 -0500 To: "" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [TLS] Closing out the final issue in 4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:05:16 -0000 --Apple-Mail=_D9FB1E04-76FF-4F2A-82ED-4AA4565B9952 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, The changes made to draft-ietf-tls-rfc4492bis-11 addressed the WGLC = comments, but we were waiting to hear from the CFRG wrt whether to use = contexts. It appears that the CFRG thread discussing the use of context = for TLS1.3 has wound down [0] and it appears that the consensus is: = =E2=80=9Cno to contexts in this instance=E2=80=9D; while the thread did = continue for bit nobody was demanding context MUST be used in TLS1.3. = Based on this, we=E2=80=99re going to close this final issue out. Yoav - please submit a -12 to address this. I believe the text you = suggest in mid-November for s2 would suffice: The context parameter for Ed448 MUST be set to the empty string. Please also note that the 3rd to last paragraph in the security = considerations needs to be expanded or removed. Cheers, J&S [0] = https://mailarchive.ietf.org/arch/msg/cfrg/LYK6Is9s6fRmniRhVoieYdzdXGw = = --Apple-Mail=_D9FB1E04-76FF-4F2A-82ED-4AA4565B9952 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

The changes made to = draft-ietf-tls-rfc4492bis-11 addressed=20 the WGLC comments, but we were waiting to hear from the CFRG wrt whether to use contexts.  It appears that the CFRG thread discussing the = use of context for TLS1.3 has wound down [0] and it appears that the consensus is: =E2=80=9Cno to contexts in this instance=E2=80=9D; while the thread = did continue for bit nobody was demanding context MUST be used in TLS1.3.=20=  Based on this, we=E2=80=99re going to close this final issue = out.

Yoav - = please submit a -12 to address this.  I believe the text you = suggest in mid-November for s2 would suffice:

 The context parameter for Ed448 MUST be set to the = empty string.

Please also note that the 3rd = to last paragraph in the security considerations needs to be expanded or = removed.

Cheers,

J&S

[0] https://mailarchive.ietf.org/arch/msg/cfrg/LYK6Is9s6fRmniRhVoieYdzdXGw
= --Apple-Mail=_D9FB1E04-76FF-4F2A-82ED-4AA4565B9952-- From nobody Mon Feb 13 15:21: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 0ABAF1294D6 for ; Mon, 13 Feb 2017 15:21:36 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 d2cglqxc6bNS for ; Mon, 13 Feb 2017 15:21:32 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 CA7AF129435 for ; Mon, 13 Feb 2017 15:21:31 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id k90so160498147wrc.3 for ; Mon, 13 Feb 2017 15:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=sgzii36livb6iTK/5DE352hM+CO4/o/o0eStg8Fklio=; b=hiczKypsXo2m1eBGbsb4bFcymLJBHF7ZjCUn0iTofKOYReYFNMQqfKjRYb7f0exlb9 vx1VlvEYhIMjb+LIJf+9yKle6B/YQhwA1/X18ODw0QIEyX/Pcl0Ltpubf0XlmPEjRs3d 5fg7SftVq1NYhHcahwzlu+NQAZ5ZBaaEGXdkA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=sgzii36livb6iTK/5DE352hM+CO4/o/o0eStg8Fklio=; b=Y7wPVqFAdmJYW7X51muTZui2wx2itVKiNS+W5hKkZSWowOILBADHSAE3VlaQabpEB9 vyIEWNLq8rvNpztrY8sYS3gjoKnqYsf6WPe3QfN3yEGaz4KAHuqG7Iyfb1pZlCtNoW3S SEJTvZgsXtkH684xJwXrrwjeFEVFFKtYCpLwR14TmP8rlZIRz9x8B202ZXQ4monOzlVg 1O6lX0Wju6Zt5jEtsl/DZimyZVJG4cb6h7Cky7CHnfKVhyXlacBkgXX42uq7HX3zcBb9 ZFRA9i+JwJj5pdGF+/v1kgfAhvNOVb//DFe/xlNfFiOVY1XmzM/aeVapM/yRE/oJCSKe klYg== X-Gm-Message-State: AMke39k1wjuxjKlikiZXIeyXZWmVRjPeYpvsxvfOaMnzApz8w5nt0q6ouSPxLJ5liDQY9Q== X-Received: by 10.223.135.80 with SMTP id 16mr20254402wrz.182.1487028090361; Mon, 13 Feb 2017 15:21:30 -0800 (PST) Received: from [192.168.1.130] ([156.218.144.154]) by smtp.gmail.com with ESMTPSA id h75sm15611003wrh.37.2017.02.13.15.21.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Feb 2017 15:21:29 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> Date: Tue, 14 Feb 2017 01:21:25 +0200 Message-Id: <95D221C7-40A6-4BDD-B8CD-5C4F9C405D3F@azet.org> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:21:36 -0000 --Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Feb 2017, at 07:07, Sean Turner wrote: >=20 > All, >=20 > We=E2=80=99ve got two outstanding PRs that propose changes to = draft-ietf-tls-tls13 Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D. = As it relates to rekeying, these limits have been discussed a couple of = times and we need to resolve once and for all whether the TLS WG wants = to: >=20 > a) Close these two PRs and go with the existing text [0] I thought the cited paper sorted this out like a year ago. In favor of option a Aaron --Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYoj92AAoJEOTbZJL9ubXV2xUQAO8feVVxeB+HU/LWxV/tRHwW bdyigIeRUOdjNkVBfk7KgKUvY7JIpV9LL+hfeuqrWGB51rccAwhcOgoe7RBGg4zE jQpdTtxk+02x+3NVdEj9eJklwYpenlLbIUolNrZ7J4rMhlZV+Yt6NWz+9K/S7PsV dkxufFyTcxjZXkh3U9Bim37Sm8+wlBe3ns9WPbhLNuUp7TZlvueBEmhNTc9j5+t4 Tne7Q3KWf0IIPNI009183QrH/SxVS1HXybD0+H2Y4ScQiMoXsbJbZCk9SZjLiFOb 7lHNKT0ZWUg25Z1MZNE5i0GquynvtbM6weJ/IzlI/Hu/zawOEulPo+j0H14PfL9r t3vz/XO+7YDibx0XffkIcc40dnZfnqCk90199h4tDX1zAM90mzisQj+FQtmQfnBV ykPav/4RhA4U528RZUAMSvbEcg1BDEfwZ63l3+JZr2TpxmlH4vs9zp632jwkXFsk Vw3lm6iFvWbKV7mupJP/IglBzx0+rklH13TaEHHrwnnt1EJ6+kifzQ6yf7sVLWSy Zxkpr+447ElY6eqNhPs4nY6JiMK1Sjje4EuGBx0CY7imNqiH3OOZWeD0ICCXjnmy KUGOshEEQp/rRT/Jx9sXEGP3bW8U5vJuCA9bnF8ToOixU+tAM/ddzPoBOcNpHQkI Mw4yA16juYJLN6Dvam9p =9lQP -----END PGP SIGNATURE----- --Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832-- From nobody Mon Feb 13 15:25: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 E22C312953B for ; Mon, 13 Feb 2017 15:25:28 -0800 (PST) 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 y9B5ULpRx9kp for ; Mon, 13 Feb 2017 15:25:27 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 96EAC129430 for ; Mon, 13 Feb 2017 15:25:27 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id x75so70629668vke.2 for ; Mon, 13 Feb 2017 15:25:27 -0800 (PST) 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=fJNE7OtKbDiV901D5n5md9yUJun4f+A02r7fHPg+AZE=; b=XV05Uzi9xuAsHj/GlD5UlaDKy0a4Kayg3DX56bClNb7lDA1x71Paa3RLSfvft2DxWT OUq/vJbbdYZ68NsDjqAis0RpPsQrZZ7+tyVkFXh6PVgUS+3FiCpMtYg8t57JVfjFtJ5T /M401TcGZfCNcqk8bfhbOh2Ofxx9lqTVrCTodubm2Kfs6BiCXrm9Jc6Fq+LNSGYX7gcu gKvG/CL4Djkw4hSsuBXzdlfI2ZMaIBqvnNO6Hsz0yNXWaxfvWE2C09RocRJOIehuYMIc p9nyk2XKfNDVIxHAXhQFrb/7xeeubnNt18FjAtDYyaiXkWiCKu/ZXcpYKpFSPk/vrBWP g5uQ== 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=fJNE7OtKbDiV901D5n5md9yUJun4f+A02r7fHPg+AZE=; b=IX41SK1Ly33y6k5p6pcE1sBlUpOAGZR2dO3RHAYACS2LeUwddwz1ThFJaKfh8qpp0K 9CvAeKsBocMOifMKqIrHVru1043ZgTGemgNM1l6LYjoQ+dWJaZJQWSAGdbIwzbU5nlb0 TXrfjcux1s4i7qiNBp4hpUPeOVYAN8TXWuPMFWrA9k6SEJ87O3ikFjai0oiT6FvBVi3l nn7JDDkNNchd0Td3nDemlpkwelfCUpAIy2OtAlMEF2zpdVgNX/UNJ1jouVlOWkhVvraz sKXTJCoo+kP1lH8kdatbEmtnun5FjgceZ0TY0c85sO2BL5lwkcVU+TxAGK8VksZSB3lL JQZg== X-Gm-Message-State: AMke39ld3vPK7+ljW4VfUX4VKvhZtXw4ZtpDfh9Laj3vnMTci/eHo8/N7S7Xas6DhQUDSKLrPeyNGuq74XvA3Q== X-Received: by 10.31.213.7 with SMTP id m7mr11134474vkg.48.1487028326752; Mon, 13 Feb 2017 15:25:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.70.130 with HTTP; Mon, 13 Feb 2017 15:25:06 -0800 (PST) In-Reply-To: <95D221C7-40A6-4BDD-B8CD-5C4F9C405D3F@azet.org> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <95D221C7-40A6-4BDD-B8CD-5C4F9C405D3F@azet.org> From: Tony Arcieri Date: Mon, 13 Feb 2017 15:25:06 -0800 Message-ID: To: Aaron Zauner Content-Type: multipart/alternative; boundary=94eb2c07aadc2ff35b054871c36b Archived-At: Cc: IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:25:29 -0000 --94eb2c07aadc2ff35b054871c36b Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 3:21 PM, Aaron Zauner wrote: > I thought the cited paper sorted this out like a year ago. > > In favor of option a I am also in favor of option A. The wording in option B is simultaneously much more unclear and much more verbose. I consider it a regression. Option C is more similar to option A, but not an improvement, IMO. -- Tony Arcieri --94eb2c07aadc2ff35b054871c36b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 13, 2017 at 3:21 PM, Aaron Zauner <azet@azet.org> wrote:=
I thought the cited paper sorted this ou= t like a year ago.

In favor of option a

I am also in favor of = option A.

The wording in option B is simultaneousl= y much more unclear and much more verbose. I consider it a regression.

Option C is more similar to option A, but not an impro= vement, IMO.

--
Tony Arcieri
--94eb2c07aadc2ff35b054871c36b-- From nobody Tue Feb 14 03: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 7B1BA1295CB for ; Tue, 14 Feb 2017 03:59:50 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 r3R8XsgRkIjH for ; Tue, 14 Feb 2017 03:59:47 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0120.outbound.protection.outlook.com [23.103.201.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759D41293E8 for ; Tue, 14 Feb 2017 03:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=alcX0Sue+kyVeLg++Kbn9+lHWiS7nMrDsfnFJqvGnWs=; b=VtcukwHUtShAEMLFvUWzsivKpISmyu9rt7sqUtDCNtEVmsVPYua796Tw0Oe8r71oY8gbyBtbyRst5BcIc6B74+BqjXAhZXTa9bFdtlOKnqDVL/99xwNW+yuQ51b4v1DCHqlA+LvvOFwyzP9c8oAz6fehu6GElYCeamGbS9qTvzc= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 11:59:44 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 11:59:44 +0000 From: "Dang, Quynh (Fed)" To: Markulf Kohlweiss Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QA Date: Tue, 14 Feb 2017 11:59:44 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.218.32] x-ms-office365-filtering-correlation-id: f39056d9-01a3-4057-155b-08d454d0f750 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:xBVGsHpvfGScMXbWYdBYDU2scucR4JPkNGHIGgsO9oFQjnEL8s5+B2LZ4YrA6o7DxwL5cotuWuSgEF6Vr+m819Bwl+WHQZdiG5VY9vkS+5UBvhcu20LdTDMc8+q1L6Fcze1XEU5xH06yJJu7rIU+w7AL9D0KOaNK2CnGsqNc4JapmcIIYloRW9XvJlZ7IZMsL94CAaNsh7gp6M/eui+lbH++dOFCNiuQtkcOiJaYuaqX7Y1qDZLZwLCtjpouZ+X2stZNjRrh1s1UUtK/Mjdh9Ycr5aMpv3GKN02rVNs/gEAAbDFgYiWaDh+8mb5MFCgCbFivCphoXzryJUaNdRy0tDHDyv5DsgjTaq7mtW7ADSmwJF7k+u/BHyuDcEeSkbQMW5/DAVgTgC60lEoHR2aIYNAJ07qfB4g+UdJk/YkvnI5NHRNIUVpOXuyZ63e5ZrdVQX73aZ6Endh99lVvqP88n12pZmLOeM5Z/tGUnjuS0P2gGBAeEre+6aJUBZzDg/6+pN9dYIdJRQPEOmGsdDRy7Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39410400002)(39450400003)(39860400002)(377454003)(24454002)(199003)(189002)(229853002)(50986999)(101416001)(99286003)(54906002)(54356999)(76176999)(189998001)(93886004)(53936002)(36756003)(86362001)(3846002)(6116002)(8676002)(106116001)(102836003)(2906002)(3280700002)(81156014)(81166006)(92566002)(106356001)(606005)(6246003)(54896002)(122556002)(8936002)(3660700001)(6306002)(236005)(2421001)(4001350100001)(105586002)(66066001)(6512007)(4326007)(25786008)(2561002)(77096006)(6486002)(6436002)(7736002)(1511001)(83506001)(68736007)(2950100002)(6506006)(6916009)(8666007)(2900100001)(81003)(38730400002)(53546003)(110136004)(5660300001)(7906003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4C850542FDA4qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 11:59:44.3692 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: Antoine Delignat-Lavaud , IRTF CFRG , "" Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 11:59:50 -0000 --_000_D4C850542FDA4qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Markulf and all, I provided more explanation below. From: 'Quynh' > Date: Monday, February 13, 2017 at 10:45 AM To: Markulf Kohlweiss >= , "Paterson, Kenny" >, Sean Turner > Cc: Antoine Delignat-Lavaud >, IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Hi Markulf, The probability of a bad thing to happen is actually below (or about) 2^(-3= 3). It practically won=92t happen when the chance is 1 in 2^32. And, to ach= ieve that chance, you must collect 2^48 128-bit blocks. Regards, Quynh. From: TLS > on behalf of = Markulf Kohlweiss > Date: Monday, February 13, 2017 at 10:34 AM To: "Paterson, Kenny" >, Sean Turner > Cc: Antoine Delignat-Lavaud >, IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769) Hello, Our analysis of miTLS also supports option a) A security level of 2^-32 seems too low from a provable security point of v= iew, especially for a confidentiality bound. When someone says AES-128 has 128 bits of security he or she means that 2^1= 28 AES operations will break the cipher with probability 100%: finding the = key and the plaintext. It does not mean that attackers have only 2^(-128) = chance of success. If an attacker could run 2^100 AES operations, his or he= r chance of success is way below 2^(-32): this does not mean that AES has a= security level of 2^(-32) or 2^(-28). The success probability 1/2^32 means that after 2^48 AES operations, the at= tacker has a success probability of 2^-32 which is practically zero. Also, many users don=92t know what =93confidentiality bound=94 means. The current text Eric wrote talks about a number 2^24.5 of full-size record= s. In many situations, the record sizes are not full size, but different si= zes. My latest suggestion text does not assume full size records, it covers= variable record sizes, it just counts AES-input blocks or AES operations. Regards, Quynh. We verified an implementation of the TLS 1.3 record (https://eprint.iacr.or= g/2016/1178, to appear at Security & Privacy 2017) where we arrive at a com= bined bound for authenticity and confidentiality that is compatible with th= e Iwata et al. bound. Regards, Markulf (for the miTLS team) Hi, My preference is to go with the existing text, option a). >From the github discussion, I think option c) involves a less conservative security bound (success probability for IND-CPA attacker bounded by 2^{-32} instead of 2^{-60}). I can live with that, but the WG should be aware of the weaker security guarantees it provides. I do not understand option b). It seems to rely on an analysis of collisions of ciphertext blocks rather than the established security proof for AES-GCM. Regards, Kenny On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson" wrote: On 10 February 2017 at 16:07, Sean Turner wrote: a) Close these two PRs and go with the existing text [0] b) Adopt PR#765 [1] c) Adopt PR#769 [2] a) I'm happy enough with the current text (I've implemented that any it's relatively easy). I could live with c, but I'm opposed to b. It just doesn't make sense. It's not obviously wrong any more, but the way it is written it is very confusing and easily open to misinterpretation. _______________________________________________ Cfrg mailing list Cfrg at irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_D4C850542FDA4qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <491F1A64945B714DB274CEFE6B5D208E@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Markulf and all,

I provided more explanation below. 

From: 'Quynh' <Quynh.Dang@nist.gov>
Date: Monday, February 13, 2017 at = 10:45 AM
To: Markulf Kohlweiss <markulf@microsoft.com>, "Pate= rson, Kenny" <Kenny.Pa= terson@rhul.ac.uk>, Sean Turner <sean@sn3rd.com>
Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG = <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Markulf,

The probability of a bad thing to happen is actually below (or about) = 2^(-33). It practically won=92t happen when the chance is 1 in 2^32. And, t= o achieve that chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh. 

From: TLS <tls-bounces@ietf.org> on behalf of Markulf Kohlwe= iss <markulf@microsoft.com&= gt;
Date: Monday, February 13, 2017 at = 10:34 AM
To: "Paterson, Kenny" <= ;Kenny.Paterson@rhul.ac.uk= >, Sean Turner <sean@sn3rd.com&= gt;
Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG = <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769)

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point= of view, especially for a confidentiality bound.

When someone says AES-128 has 128 bits of security he or she means tha= t 2^128 AES operations will break the cipher with probability 100%: finding= the key and the plaintext.  It does not mean that attackers have only= 2^(-128) chance of success. If an attacker could run 2^100 AES operations, his or her chance of success is way below = 2^(-32): this does not mean that AES has a security level of 2^(-32) or &nb= sp;2^(-28). 

The success probability 1/2^32 means that after 2^48 AES operations, t= he attacker has a success probability of 2^-32 which is practically zero. &= nbsp;

Also, many users don=92t know what =93confidentiality bound=94 means.<= /div>

The current text Eric wrote talks about a number 2^24.5 of full-size r= ecords. In many situations, the record sizes are not full size, but differe= nt sizes. My latest suggestion text does not assume full size records, it c= overs variable record sizes, it just counts AES-input blocks or AES operations. 

Regards,
Quynh. 

 




We verified an implementation of the TLS 1.3 record (https://eprint.iacr.org/2016/1178, to appe= ar at Security & Privacy 2017) where we arrive at a combined bound for = authenticity and confidentiality that is compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

From the github discussion, I think option c) involves a less conserva= tive
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should b= e
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security p= roof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&= gt; wrote:

On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr= ote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.=
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

_______________________________________________
Cfrg mailing list
Cfrg at irtf.org

_______________________________________________
TLS mailing list

 --_000_D4C850542FDA4qdangnistgov_-- From nobody Tue Feb 14 07: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 690691295F4 for ; Tue, 14 Feb 2017 07:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, 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 gEBSoVLXk8Pr for ; Tue, 14 Feb 2017 07:21:53 -0800 (PST) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 3392312956E for ; Tue, 14 Feb 2017 07:21:53 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id c4so2489623wrd.1 for ; Tue, 14 Feb 2017 07:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:from:to:cc:in-reply-to:references:subject:message-id :date:content-transfer-encoding:mime-version; bh=TL4mCsZrGsO23yMGcsfyfd1B4zj/mt7oVFlSbhN9wII=; b=cxEB/ABF0C4yWUB287QpsZe+IoFxfIINgF4u1uspaspoq1uFjEKqeYuhf1rukvGzW0 UjlXLgH5mAV/jApB4tk/2DbywHlnpeZsv42mja2PPOYTwJR0hoYpIsk0I6ppc3Zp/Ggd y+bpXlOHCZyHm197HulLDKWY6/3DoOrXp+OsiDH6YqJXWwQyyM6vSyIefxuTFPds8lx+ MfBw90o7ceS/fktTZJ09SaAKdDo4KFFp+9KdHzIJLtyUI8BDWk/zTzC4aO70VUvis/RN DOSyLqxFtCmgj3j/BTa+uKyl5txzKJN+aDfHEJlpncf0xBzCbX6zpld3PHJDH0+hx8L3 H+yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:cc:in-reply-to:references :subject:message-id:date:content-transfer-encoding:mime-version; bh=TL4mCsZrGsO23yMGcsfyfd1B4zj/mt7oVFlSbhN9wII=; b=ltx+oMe0c115k+VMnV7BrWMq3i6uPGgTvhCKpfreJn2BSIk3fyHrWGW7m+9LTsMPDA fd75f+r0wkAoJPWwz8VmAMp4i6bSJHSooKInfvP7JLmibHsTs8kvQaqhr+z/KAzb58G4 NnJew6qwQTRbC+4AlD8hspjUvys8I5179hVTXtfEh/ET1mFmFlr8WOBCzaHLmvCn00NP QYF1LPN2rTiFp6jWqm9SvOG017wZIwG6lmVk5dAqsFiNfRiUwzmUmAvLOtb7xkpUqF7Z wVca6M+B7IRUTxmV4va7NA70CQShbdrIfyZ/R9HoX6zFr4cJNBZwlKYds1X/C1YFEgFp +eLA== X-Gm-Message-State: AMke39njm0Ri30N/ljbP2jFdupqEmBzPyJ1LVVp5179+v3+OfZ7jPMLzOrs4dIDul5cgKg== X-Received: by 10.223.139.148 with SMTP id o20mr3275537wra.113.1487085711607; Tue, 14 Feb 2017 07:21:51 -0800 (PST) Received: from little-david.home (LFbn-1-9943-152.w86-202.abo.wanadoo.fr. [86.202.61.152]) by smtp.gmail.com with ESMTPSA id a13sm3893287wma.13.2017.02.14.07.21.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 07:21:50 -0800 (PST) Content-Type: text/html User-Agent: NylasMailer-K2 From: David Wong To: Cas Cremers In-Reply-To: References: Message-ID: Date: Tue, 14 Feb 2017 15:21:50 +0000 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 15:21:54 -0000
I can see this problem = even in the case where the client sends an empty Certificate message during= the handshake. If the application does not tell the client what happened, = a NewSessionTicket has no way of indicating if it will include client-auth = in the next session.

David

           =20
          



From nobody Tue Feb 14 07:45: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 AE857129627 for ; Tue, 14 Feb 2017 07:45:09 -0800 (PST)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=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 jvyMe_RHyI2h for ; Tue, 14 Feb 2017 07:45:07 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 3D9F8129483 for ; Tue, 14 Feb 2017 07:45:07 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id w20so113558957qtb.1 for ; Tue, 14 Feb 2017 07:45:07 -0800 (PST)
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=hv/1XCKpPuo00J8YRKtHZI1/BkbmsQsaYR8LEmLAc6I=; b=SddTWzGIuJSrb+SWB+swiADJDpu/B6douu1VQIZF3Zgr8H3HczewVz1hW+zvxbwxyd G75xrwOAwJQuNkzUcdnzcL56rgqJWIoocyWtRMgCWOUEy+F4WO01gDmRPK/9277ERq7i p6Ig+Sece+qKlXsxTaohFuT9X2Cky3mpMgL/M=
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=hv/1XCKpPuo00J8YRKtHZI1/BkbmsQsaYR8LEmLAc6I=; b=Z+cnOpbZ/IpnzQ08J2ugLjOmihljfTWMojc/IOf1Q8VfiHcRz2HK24boxB8Jyh0DJ5 oWbqSvA5SikXc2QZOhI3BhI2SSZn1vLHIeWu+UMFgBbURGeAhFvdoYtUBF3ZAiGZ+lEt h3G1fPqJKcVw0JwJ0czmUq8p4altZxexgQ8Rqg3OF5mKgmZkxLjaIeiP+9fbJcqriM+V YPWbU97ZDlTLaHRdhW+Ljtys+1DphZ4AtCh7FrlHnFKdeNEoVkWMxU/rxpYPMKOCMSTe UW7UfFTnxF3DMaq0zNCdnKMULS0dH+WQahniQliiRO9IWJmo7JVAsRBF9k1JbSl4fcs9 N4+g==
X-Gm-Message-State: AMke39k+C+qr9XQAbWX8Bb5EKKlYvkFA6pXHhMKG2Ts2s+r8GowQbWPh75RGQa6Udp5J7z9krRRB8gxJiE1O3r86
X-Received: by 10.237.34.250 with SMTP id q55mr29905491qtc.127.1487087106149;  Tue, 14 Feb 2017 07:45:06 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: David Benjamin 
Date: Tue, 14 Feb 2017 15:44:55 +0000
Message-ID: 
To: David Wong , Cas Cremers 
Content-Type: multipart/alternative; boundary=001a113eea5ab6b8d805487f72b4
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 15:45:09 -0000

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

NewSessionTicket always includes in-handshake client auth. The resumption
secret can't even be derived without it.

On Tue, Feb 14, 2017 at 10:21 AM David Wong 
wrote:

> I can see this problem even in the case where the client sends an empty
> Certificate message during the handshake. If the application does not tell
> the client what happened, a NewSessionTicket has no way of indicating if it
> will include client-auth in the next session.
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


NewSessionTicket always includes in-handshake client auth.=
 The resumption secret can't even be derived without it.

On Tue, Feb 14, 2017 at 10:21 AM David=
 Wong <davidwong.crypto@gm=
ail.com> wrote:
I can see this problem even in the case=
 where the client sends an empty Certificate message during the handshake. =
If the application does not tell the client what happened, a NewSessionTick=
et has no way of indicating if it will include client-auth in the next sess=
ion.

David

           =20
          


_______________________________________________

TLS mailing list

TLS@i=
etf.org

https://www.ietf.org/mailman/listinfo/t=
ls




--001a113eea5ab6b8d805487f72b4--


From nobody Tue Feb 14 08:14: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 8AB0612967F for ; Tue, 14 Feb 2017 08:14:33 -0800 (PST)
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 bhjIQW2oQWAh for ; Tue, 14 Feb 2017 08:14:31 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 50085129668 for ; Tue, 14 Feb 2017 08:14:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 200ED1B94C; Tue, 14 Feb 2017 18:14:29 +0200 (EET)
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 8_x3frgK6_ao; Tue, 14 Feb 2017 18:14:28 +0200 (EET)
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 C454E21C; Tue, 14 Feb 2017 18:14:28 +0200 (EET)
Date: Tue, 14 Feb 2017 18:14:25 +0200
From: Ilari Liusvaara 
To: Cas Cremers 
Message-ID: <20170214161425.GA3866@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: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 16:14:33 -0000

On Mon, Feb 13, 2017 at 12:32:53PM +0000, Cas Cremers wrote:
> 
> The main takeaway is that the client never really receives any
> acknowledgement of whether the verification provided was successful or
> rejected through an in-band mechanism.
> 
> The context of the keys does not include the client’s authentication status
> (nor the client’s certificate), and is the same in both cases. From a
> formal analysis point of view, this results in a mismatch where the client
> and server may not agree on the mutual authentication status, which is the
> main point we wanted to raise.

It is not just problem of "context of keys". TLS 1.3 explicitly allows
silently rejecting client authentication. No fatal error, no NAK, no
nothing.

Which impiles that client and server can disagree even about status of
in-handshake authentication. Including in resumption, even if the RMS
supposedly includes client's authentication status in its context.

This problem actually cuts protocol layers, and that's why it is so
hard. And things get even more fun when resumption is involved.

I expect there will be quite a bit of implementations that won't
trigger any errors if EE key can be parsed and the client signature
verified (due to layering rendering that way pretty natural).
 
> Assuming now that the key context will not be changed, we suggest to
> explicitly mention in the security guarantees section that the client,
> after sending authentication messages, cannot be sure at any point that the
> server has received these messages and considers the connection to be
> mutually authenticated. If the client wishes to obtain such a guarantee, it
> has to be informed by the server’s application.

See above why changing "context" won't fix the problem.

And yeah, "if you want to be sure, ask application layer" is
probably about the best that can be done.



-Ilari


From nobody Tue Feb 14 08:18: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 5169C12968F for ; Tue, 14 Feb 2017 08:18:07 -0800 (PST)
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, RP_MATCHES_RCVD=-0.001] 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 uwRG_9l9bQOW for ; Tue, 14 Feb 2017 08:18:05 -0800 (PST)
Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 0155812968A for ; Tue, 14 Feb 2017 08:18:04 -0800 (PST)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 56E771380BC.ABA0E
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 56E771380BC for ; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 519D4403B; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 4B5AF2002C; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 468FB40; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from c-73-71-218-252.hsd1.ca.comcast.net ([73.71.218.252]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 14 Feb 2017 17:17:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 14 Feb 2017 08:17:53 -0800
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Atul Luykx 
To: "Dang, Quynh (Fed)" 
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>     
Message-ID: 
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99.2 at cobalt
X-Virus-Status: Clean
Archived-At: 
Cc: Antoine Delignat-Lavaud , Markulf Kohlweiss , IRTF CFRG , tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 16:18:07 -0000

Hey Quynh,

> When someone says AES-128 has 128 bits of security he or she means
> that 2^128 AES operations will break the cipher with probability 100%:
> finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext 
pairs available to the adversary, it will still take roughly 2^128 
operations to recover the key with AES. This contrasts with any mode of 
operation, where adversarial success probability increases according to 
the amount of data available and the computational complexity required 
to perform such an attack is not the limiting factor (which is the core 
of the problem we're discussing right now).

Regardless, correct me if I'm wrong Quynh, but you seem to have two 
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of 
caution instead of recommending that people switch when adversaries have 
success probability 2^{-32}. I don't see the discussion progressing on 
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough 
heuristic, however this can be fixed easily by minimally modifying the 
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
> Hi Markulf and all,
> 
> I provided more explanation below.
> 
>  From: 'Quynh' 
> Date: Monday, February 13, 2017 at 10:45 AM
> To: Markulf Kohlweiss , "Paterson, Kenny"
> , Sean Turner 
> Cc: Antoine Delignat-Lavaud , IRTF CFRG
> , "" 
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769)
> 
>> Hi Markulf,
>> 
>> The probability of a bad thing to happen is actually below (or
>> about) 2^(-33). It practically won’t happen when the chance is 1
>> in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
>> blocks.
>> 
>> Regards,
>> Quynh.
>> 
>> From: TLS  on behalf of Markulf Kohlweiss
>> 
>> Date: Monday, February 13, 2017 at 10:34 AM
>> To: "Paterson, Kenny" , Sean Turner
>> 
>> Cc: Antoine Delignat-Lavaud , IRTF CFRG
>> , "" 
>> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
>> PRs (#765/#769)
>> 
>>> Hello,
>>> 
>>> Our analysis of miTLS also supports option a)
>>> 
>>> A security level of 2^-32 seems too low from a provable security
>>> point of view, especially for a confidentiality bound.
> 
> When someone says AES-128 has 128 bits of security he or she means
> that 2^128 AES operations will break the cipher with probability 100%:
> finding the key and the plaintext.  It does not mean that attackers
> have only 2^(-128) chance of success. If an attacker could run 2^100
> AES operations, his or her chance of success is way below 2^(-32):
> this does not mean that AES has a security level of 2^(-32) or
> 2^(-28).
> 
> The success probability 1/2^32 means that after 2^48 AES operations,
> the attacker has a success probability of 2^-32 which is practically
> zero.
> 
> Also, many users don’t know what “confidentiality bound” means.
> 
> The current text Eric wrote talks about a number 2^24.5 of full-size
> records. In many situations, the record sizes are not full size, but
> different sizes. My latest suggestion text does not assume full size
> records, it covers variable record sizes, it just counts AES-input
> blocks or AES operations.
> 
> Regards,
> Quynh.
> 
>> We verified an implementation of the TLS 1.3 record
>> (https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
>> 2017) where we arrive at a combined bound for authenticity and
>> confidentiality that is compatible with the Iwata et al. bound.
>> 
>> Regards,
>> Markulf (for the miTLS team)
>> 
>> Hi,
>> 
>> My preference is to go with the existing text, option a).
>> 
>> From the github discussion, I think option c) involves a less
>> conservative
>> security bound (success probability for IND-CPA attacker bounded by
>> 2^{-32} instead of 2^{-60}). I can live with that, but the WG should
>> be
>> aware of the weaker security guarantees it provides.
>> 
>> I do not understand option b). It seems to rely on an analysis of
>> collisions of ciphertext blocks rather than the established security
>> proof
>> for AES-GCM.
>> 
>> Regards,
>> 
>> Kenny
>> 
>> On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
>> 
>> wrote:
>> 
>> On 10 February 2017 at 16:07, Sean Turner  wrote:
>> 
>> a) Close these two PRs and go with the existing text [0]
>> b) Adopt PR#765 [1]
>> c) Adopt PR#769 [2]
>> 
>> a) I'm happy enough with the current text (I've implemented that any
>> 
>> it's relatively easy).
>> 
>> I could live with c, but I'm opposed to b. It just doesn't make
>> sense.
>> It's not obviously wrong any more, but the way it is written it is
>> very confusing and easily open to misinterpretation.
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg at irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> 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 Feb 14 08:18: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 3619A129483 for ; Tue, 14 Feb 2017 08:18:39 -0800 (PST)
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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, 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 94nZ80V8MmkF for ; Tue, 14 Feb 2017 08:18:38 -0800 (PST)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 186B3129690 for ; Tue, 14 Feb 2017 08:18:30 -0800 (PST)
Received: by mail-wm0-x241.google.com with SMTP id r18so4306431wmd.3 for ; Tue, 14 Feb 2017 08:18:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:from:to:cc:in-reply-to:references:subject:message-id :date:content-transfer-encoding:mime-version; bh=ptjP3Jk6R7TRnCLjU+9PvGQ7pN+ZreyEQFAOMeGvLSk=; b=AoXPBfhcnWuITO28Y2tGFO/LzN7sGJ0CbmWiIGNMTye+KRC4vHDjSgATnLB54gj4si o/A4Acbps5ZMzh1TBQ4n3iAqs+vvRsNEStedx9A3NKPGj5YOM79LoUG05QAvETQ3tgK0 JXSxy929Gk3Gf2QlJILJhDYHOATDpya5wDLG0QRGovUVt0oKxLNbv63OAs+NFtn0aGs6 SiYYHfB7fIcSI39oYaOjUUBQMYF8rHqd9QJiyU0xT5oScbwuDA4OfByGJLrU4uSUGCXk A24XJsa5NaazrZyBrayJ1SpyBlQ/G2yR/jRYfQH98FeXjP/RTDnTH1x8WYrdWHxCgpjl sTbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:cc:in-reply-to:references :subject:message-id:date:content-transfer-encoding:mime-version; bh=ptjP3Jk6R7TRnCLjU+9PvGQ7pN+ZreyEQFAOMeGvLSk=; b=USDfmK8NtzSSFNMMUVO2D9nvC79sMCC3C/FOmlIxfIFHc2vskxzs5c/uqhaecQc79O KZZStZhE3MpdSwvR19/dSoCSndfDhprqi8swsZODW7j5Gh+YKZiIEqM4r/vNRvgpka/Q m1rK1Smnck5mRCKiySFAtrHaEVJa5aWJqXHQu2aJxygFWhFYNlJn4sOzqgUlFabjlJu5 3lIGBgC/gxrtqhI/ZdrgdvFswUV6fFssxBwlBSJ0VdZV0vma3CLmutLWMDgcV9mCSQcE 1lMi7ktJsR6va+cTDaac7CqEHjVjyArL7Tvs9guHVECp8mRMairllBXMsvm+qCRwoqah Hf4w==
X-Gm-Message-State: AMke39ns3rz3xpF66svDgnBf7XhfoIhJcC1zpJukaqhACN0Z6RO6uKB0lDjROr6hyioMGw==
X-Received: by 10.28.86.214 with SMTP id k205mr3793424wmb.26.1487089108513; Tue, 14 Feb 2017 08:18:28 -0800 (PST)
Received: from little-david.home (LFbn-1-9943-152.w86-202.abo.wanadoo.fr. [86.202.61.152]) by smtp.gmail.com with ESMTPSA id s17sm1395740wrc.6.2017.02.14.08.18.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 08:18:28 -0800 (PST)
Content-Type: text/html
User-Agent: NylasMailer-K2
From: David Wong 
To: David Benjamin 
In-Reply-To: 
References:   
Message-ID: 
Date: Tue, 14 Feb 2017 16:18:27 +0000
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Cas Cremers , tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 16:18:39 -0000





          

            

            On Feb 14 2017, at 4:44 pm, David =
Benjamin <davidben@chromium.org> wrote:
            

            

              
NewSessionTicket always includes in-handshake client auth. The =
resumption secret can't even be derived without it.



Oups, my bad. What about if the client do send a =
certificate, but the server decides not to accept it, but goes on with the =
connection (I think nothing in the spec says that the server needs to =
terminate the connection if the client cert is not good).



From nobody Tue Feb 14 09: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 A052A1295AE for ; Tue, 14 Feb 2017 09:48:22 -0800 (PST)
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 56P46DgPmRS9 for ; Tue, 14 Feb 2017 09:48:21 -0800 (PST)
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 1227712949F for ; Tue, 14 Feb 2017 09:48:21 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id x75so41945488itb.0 for ; Tue, 14 Feb 2017 09:48:21 -0800 (PST)
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; bh=ZZvsQ8Gth7dDNEQWAz4afvB2XVU7eAeUNA4jxfcIhmM=; b=lpvzSkmhlm8ClVFV41rtYSevohzy7kWK4vBZB+E/5tWmJsRjqBSxMPOWF7s03Jl+Rm sMNmDy/nM8evA/9L85TDESqddQqYtA/SWboA/AMLAxyDjD0jSTapSRCsMYYr0rjYf3af 9tlW2VNrMPtjycyltz/vHbZ2v4nIBlDXpC5zZKtaJ1pcRTPvS1IjYEIfrea5pfICVJkp MBirHvg+KPN6MuiYfRxw5TdXRmdXSDWuR52pPSay7zPQrRY2xBlNDqx4NzFbCpihT99r oZaUDAUZbtYCK9WXLCMDPeo3XVTtwn3QGTygiQx12jZonOxSkO7ptx9nOAx1vef5kcfC sVwA==
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=ZZvsQ8Gth7dDNEQWAz4afvB2XVU7eAeUNA4jxfcIhmM=; b=O41gVy5FeATVRL9HGUBpvpPRmgR9bWjV53DCRh3IyWnvYWIRrd+Yzob+so+IE+SG2z +VM4OEbQVXP/TRlmwTAwK1hsheh7VqekChC+EwWZT6SeMalbGnRkFT1fzb7LVELeks96 /BmTgOepUTjj+n/8fqxEK8hNUvjX2gIegSacAU22QImZkU0cSHneYHZ0Gh0/ZQdeqaRF z8NEIsHGFJM9pHH5YE0oKr+NllZ3Y9w41WfBfWye8bsoj1dguQRM+19jL0WJWZbJMwPz 6o+237pN/eQHUW3zEqcU0Y+mHqZAODRgHUfIxnEf2gn79mlyiX5Q6rWSvQz3ZikszmCb r9fA==
X-Gm-Message-State: AMke39kpyIQIdB/fGy9uYXewdrvYKhQjfe4PHs/wcEpOtW2u7rwg0+hoWXA71orRzqws3cCkS7FW+YCMgehw8nDv
X-Received: by 10.107.15.70 with SMTP id x67mr26436585ioi.103.1487094500015; Tue, 14 Feb 2017 09:48:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Tue, 14 Feb 2017 09:48:19 -0800 (PST)
In-Reply-To: 
References: 
From: Ben Schwartz 
Date: Tue, 14 Feb 2017 12:48:19 -0500
Message-ID: 
To: "" 
Content-Type: multipart/alternative; boundary=001a113ed7fe6c156e0548812b0d
Archived-At: 
Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 17:48:22 -0000

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

Thanks for the feedback everyone!  I've incorporated your suggestions and
made a new version:
https://tools.ietf.org/html/draft-schwartz-dns-sni-01

Diff:
https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-00&url2=draft-schwartz-dns-sni-01

On Tue, Feb 7, 2017 at 11:12 AM, Ben Schwartz  wrote:

> Hi TLS,
>
> Like a lot of people here, I'm very interested in ways to reduce the
> leakage of users' destinations in the ClientHello's cleartext SNI.  It
> seems like the past and current proposals to fix the leak are pretty
> difficult, involving a lot of careful cryptography and changes to clients
> and servers.
>
> While we're trying to figure that out, I think there's a simple trick that
> could help a lot: just let domain owners tell users an alternate SNI in a
> DNS entry.
>
> Here's the full draft:
> https://tools.ietf.org/html/draft-schwartz-dns-sni-00
>
> If you just want to glance at it, I recommend Figure 2.
>
> Please read and critique!  This is a starting point; the contents will
> change based on your input.
>
> Thanks,
> Ben Schwartz
>

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


Thanks for the feedback everyone!=C2=A0 I've incorpora=
ted your suggestions and made a new version:

Diff:

On Tue, Feb 7, 2017=
 at 11:12 AM, Ben Schwartz <bemasc@google.com> wrote:
Hi TLS,

Lik=
e a lot of people here, I'm very interested in ways to reduce the leaka=
ge of users' destinations in the ClientHello's cleartext SNI.=C2=A0=
 It seems like the past and current proposals to fix the leak are pretty di=
fficult, involving a lot of careful cryptography and changes to clients and=
 servers.

While we're trying to figure that ou=
t, I think there's a simple trick that could help a lot: just let domai=
n owners tell users an alternate SNI in a DNS entry.

Here's the full draft:

If you ju=
st want to glance at it, I recommend Figure 2.

Ple=
ase read and critique!=C2=A0 This is a starting point; the contents will ch=
ange based on your input.

Thanks,
Ben Sc=
hwartz





--001a113ed7fe6c156e0548812b0d--


From nobody Tue Feb 14 10: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 D3B3312949F for ; Tue, 14 Feb 2017 10:15:39 -0800 (PST)
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 SLR_SUkTqyXu for ; Tue, 14 Feb 2017 10:15:37 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0117.outbound.protection.outlook.com [104.47.34.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C726E129689 for ; Tue, 14 Feb 2017 10:15:37 -0800 (PST)
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=uW83guSmEUWaVKef5UZ9NzlPZiYXeRYcL3fbWjt3fLg=; b=iJX2zGkOoGg3NNV1t3P5gGkrug01hEISFs4xcaAFIuscWrZc2GcTGx5wH6BgBSNF05SBysNUZuQKUGW+YL7LNdvt8O8ls2xYTL5VRsjL6Gh3Scl7eKfmbk2E+mv5eJ/GXmCG9FEOUiSCNX3ep5RsiCT9f5lZRmSaHVVzGLmIOHQ=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 18:15:37 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 18:15:37 +0000
From: Andrei Popov 
To: David Wong , David Benjamin 
Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
Thread-Index: AQHShfVLh43MYmEytkO14a3ComoThqFooDUAgAAGc4CAAAlfgIAAHR8A
Date: Tue, 14 Feb 2017 18:15:36 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: c9f08c2e-3993-4ef5-449f-08d4550579b1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; 
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:ECbTlWO+Ur93SAuauHGg2M/PVHEM4B44x7H+d95WPlBpNAqIh9NnATYVd7du5IG9iWd1qu4yjPmGeuZdtXPr3s/a/HsT8FlZZdVn8ZCYXfzyQKofGaH8F+1Rteqoe2YKYqMSVlYu/NWxNdws51IjOwqfauGQRQQTlSUCWAfPn8zIns/JIVgA4zY6WHCx5QBU1gUSKUBrNHbA2pzbqWfeHbrokCAGAo0ixKSEFKk0k5PpQRAjtdQscNplrFgDsbf+uoNX68vNoendMT0czK3atHiiGKjZHOnxzh531VgQqyE6byctNJn/Kpt8HIXu5p861rOeCaOXcPM/ham3T9DdorALGJ4QzK87CWKoAxmLip1M7gncn7h3puk6RZW7PDdGxDDrsBNIr8bn6E0k9DulcSZARvGDCHoD6IWcAbxDIzZeZ0zD8SZL9fzZK4n8LDK7YwZ1GZIRUbQJ39wVjldGWPs3vJZuA3A1uQcMIYgBgw1gph8L8yFO1CrAW8QKtDA6+kHGW+brXOd6P6Eni6W/JvHSTzuBYfcJaXeY2uc2p2I=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; 
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39860400002)(39850400002)(39840400002)(24454002)(199003)(377454003)(189002)(74316002)(54906002)(10090500001)(2950100002)(6506006)(106116001)(3660700001)(6306002)(8676002)(77096006)(97736004)(9686003)(54896002)(5005710100001)(68736007)(39060400002)(81003)(50986999)(8990500004)(53936002)(54356999)(76176999)(101416001)(2900100001)(81166006)(6246003)(8936002)(10290500002)(92566002)(81156014)(229853002)(790700001)(93886004)(38730400002)(189998001)(236005)(86362001)(106356001)(3280700002)(99286003)(6436002)(55016002)(33656002)(7696004)(7736002)(5660300001)(2906002)(86612001)(4326007)(105586002)(25786008)(6116002)(122556002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08426CD005E640B9865D1BC38C580CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 18:15:36.9981 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843
Archived-At: 
Cc: Cas Cremers , "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 18:15:40 -0000

--_000_CY1PR0301MB08426CD005E640B9865D1BC38C580CY1PR0301MB0842_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is it important for the client to know, from the TLS stack itself, whether =
client authentication succeeded or not? My assumption (perhaps incorrect) h=
as been that it is the server that cares about the client's identity (or id=
entities) in order to make an authorization decision.

This thread also seems to consider client authentication a binary state: th=
e client is either authenticated, or not. In practice, the client may asser=
t multiple identities, and the server may grant various levels of access.

Also, why should the client care whether session ticket X includes client i=
dentity Y? If a client resumes a TLS session with a session ticket that doe=
s not include (or point to) a client authenticator needed to satisfy the cl=
ient's request, the server can initiate client auth (or deny the request).

Cheers,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of David Wong
Sent: Tuesday, February 14, 2017 8:18 AM
To: David Benjamin 
Cc: Cas Cremers ; tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server vi=
ew on client authentication in post-handshake mode in Revision 18




On Feb 14 2017, at 4:44 pm, David Benjamin > wrote:
NewSessionTicket always includes in-handshake client auth. The resumption s=
ecret can't even be derived without it.


Oups, my bad. What about if the client do send a certificate, but the serve=
r decides not to accept it, but goes on with the connection (I think nothin=
g in the spec says that the server needs to terminate the connection if the=
 client cert is not good).

--_000_CY1PR0301MB08426CD005E640B9865D1BC38C580CY1PR0301MB0842_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Is it important for the client to know, from the TL=
S stack itself, whether client authentication succeeded or not? My assumpti=
on (perhaps incorrect) has been that it is the
 server that cares about the client’s identity (or identities) in ord=
er to make an authorization decision.


 


This thread also seems to consider client authentic=
ation a binary state: the client is either authenticated, or not. In practi=
ce, the client may assert multiple identities,
 and the server may grant various levels of access.


 


Also, why should the client care whether session ti=
cket X includes client identity Y? If a client resumes a TLS session with a=
 session ticket that does not include (or point
 to) a client authenticator needed to satisfy the client’s request, t=
he server can initiate client auth (or deny the request).=



 


Cheers,


 


Andrei


 


From: TLS [mailto:tls-bounces@ietf.o=
rg]
On Behalf Of David Wong

Sent: Tuesday, February 14, 2017 8:18 AM

To: David Benjamin <davidben@chromium.org>

Cc: Cas Cremers <cas.cremers@cs.ox.ac.uk>; tls@ietf.org

Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/se=
rver view on client authentication in post-handshake mode in Revision 18


 













On Feb 14 2017, at 4:44 pm, David Benjamin <davidben@chromium.org> wrote:







NewSessionTicket alwa=
ys includes in-handshake client auth. The resumption secret can't even be d=
erived without it.






 








 




Oups, my bad. What about if the client do send a cer=
tificate, but the server decides not to accept it, but goes on with the con=
nection (I think nothing in the spec says that the server needs to terminat=
e the connection if the client cert
 is not good).








--_000_CY1PR0301MB08426CD005E640B9865D1BC38C580CY1PR0301MB0842_--


From nobody Tue Feb 14 10:20: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 6CCCD1293EB for ; Tue, 14 Feb 2017 10:20:19 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 lnYw57N0b57I for ; Tue, 14 Feb 2017 10:20:16 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0109.outbound.protection.outlook.com [23.103.200.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B62C126DFB for ; Tue, 14 Feb 2017 10:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/fE4UIrhydtnHpgZ/wFiryS2clsV6K7d8QcrozGVyTI=; b=JsRnhQGy/mnpjpVgIOqyQIwe2GbQFLDCVtWwpAa8fM7LmTz9Rbft+4fDKZMysktUpZH4/LYoxBXA+B9C1b9RQHbPpeFoeEa9jwECpgJV1sZbcyokefGDKB4SeTMvmw4enP5x81beymkOqiN/PwfuUiqvmEWBwgDOLNzP1FDVKr4=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 18:20:13 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 18:20:13 +0000
From: "Dang, Quynh (Fed)" 
To: Atul Luykx , "Dang, Quynh (Fed)" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QAgACb9ID//85ZAA==
Date: Tue, 14 Feb 2017 18:20:12 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.218.32]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:cJavgSjCOIJJdkKQnL6nrUNwVu46dejnAw+NACjaWOLDwOsnPyD89cr8mZEdNMM203Vjj7dgN8VzDXSnj5CH4d5/VuZmqcYU+mRGCx0pHBZ/oCZfmlplerjj+bdfaCDFA8B+aH+ayCpW/4a8vbhWORJXe6MuSNgU09pmVZKbEFdZUWzFIdCiu8oj04t6udTFy+VEiLXJ8IaWX6wx/QIBwcsSQSjHy+yCM0eTfIOKHZqF2+x21RAUGreBD4h0vwh0gi6pTZmo4TBTSaRI8YR/a1lyjZi0GJ5s+Ijz7qL1iNvPYLF+xeDZ0KN6CX5fQ6/byeoNWl+HlKHvfhsx/hWt07CEpLukkJoa9iLrxy8ZqztBgX0cYgcP1G/Z3kUbO2HHtMaDAC3XiGDjELgy/EygODubE9tLfVP9yVDlIL6xLnXBayLvF0pM2o/6T+uLjGgVfkLGNBj4oC+ZVxeHqnUB9Ryw7Aw0Bdo67nDxIp2v2PoBc9/95vK2ml+lRft5P7GAGQHri6cBYj4qF7JvwCs9jQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(189002)(199003)(377454003)(377424004)(24454002)(86362001)(102836003)(6116002)(4326007)(93886004)(3846002)(2950100002)(6862003)(53936002)(3280700002)(2900100001)(81166006)(189998001)(5660300001)(606005)(38730400002)(81156014)(92566002)(2906002)(54356999)(8676002)(50986999)(4001350100001)(97736004)(76176999)(8936002)(101416001)(7736002)(7906003)(66066001)(229853002)(83506001)(6306002)(54906002)(236005)(122556002)(6486002)(54896002)(6436002)(106116001)(6506006)(106356001)(105586002)(3660700001)(6246003)(53546003)(36756003)(6512007)(8666007)(77096006)(25786008)(68736007)(99286003)(81003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: eb5c1027-041f-409b-5808-08d455061e2a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; 
x-forefront-prvs: 0218A015FA
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D4C8AE2830145qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 18:20:12.9137 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462
Archived-At: 
Cc: Antoine Delignat-Lavaud , Markulf Kohlweiss , IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 18:20:19 -0000

--_000_D4C8AE2830145qdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Atul,

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' >
Cc: Markulf Kohlweiss >=
, Antoine Delignat-Lavaud >=
, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: jus=
t one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is=
 equivalent to computation in the sense that data are produced by computati=
on. 2^x blocks =3D 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). =
And, 1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' >
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss >=
, "Paterson, Kenny"
>, Sean Turner =
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won=92t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS > on behalf of =
Markulf Kohlweiss
>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" >, Sean Turner
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Hello,
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.
Also, many users don=92t know what =93confidentiality bound=94 means.
The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.
Regards,
Quynh.
We verified an implementation of the TLS 1.3 record
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.
Regards,
Markulf (for the miTLS team)
Hi,
My preference is to go with the existing text, option a).
>From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
be
aware of the weaker security guarantees it provides.
I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.
Regards,
Kenny
On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

wrote:
On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]
a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).
I could live with c, but I'm opposed to b. It just doesn't make
sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.
_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
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


--_000_D4C8AE2830145qdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Atul,<=
/div>








From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 11:17 AM

To: 'Quynh' <Quynh.Dang@nist.gov>

Cc: Markulf Kohlweiss <markulf@microsoft.com>, Antoine De=
lignat-Lavaud <antdl@microsoft.co=
m>, IRTF CFRG <cfrg@irtf.org=
>,
 "tls@ietf.org" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hey Quynh,









When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.




The claim is stronger: regardless of the number of plaintext-ciphertex=
t 


pairs available to the adversary, it will still take roughly 2^128 

operations to recover the key with AES. 














Actually =
the same claim: my claim did not require any data requirement: just one cip=
hertext block. 














This contrasts with any mode of 


operation, where adversarial success probability increases according t=
o 


the amount of data available and the computational complexity required=
 


to perform such an attack is not the limiting factor (which is the cor=
e 


of the problem we're discussing right now).














IND-CPA i=
s important. That is why I have always been supporting it. Data is equivale=
nt to computation in the sense that data are produced by computation. 2^x b=
locks =3D 2^x AES operations. 







With 2^48=
 AES operations/input blocks, the actual margin is below 2^(-33). And, 1 in=
 2^32 is 1 in 4,294, 967,296.00
 which is safe.







Quynh. 



















Regardless, correct me if I'm wrong Quynh, but you seem to have two 

issues with Eric's text:


1. the data limit recommendation is too strict, and


2. it only gives a data limit in terms of full records.







For point 1 it seems like most people would rather err on the side of =



caution instead of recommending that people switch when adversaries ha=
ve 


success probability 2^{-32}. I don't see the discussion progressing on=
 


this point, and basically a decision needs to be made.







I don't think point 2 is a problem because it gives people a good enou=
gh 


heuristic, however this can be fixed easily by minimally modifying the=
 


original text.







Atul












On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:




Hi Markulf and all,




I provided more explanation below.




  From: 'Quynh' <Q=
uynh.Dang@nist.gov>


Date: Monday, February 13, 2017 at 10:45 AM


To: Markulf Kohlweiss <mar=
kulf@microsoft.com>, "Paterson, Kenny"



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
" PRs


(#765/#769)






Hi Markulf,




The probability of a bad thing to happen is actually below (or


about) 2^(-33). It practically won=92t happen when the chance is 1

in 2^32. And, to achieve that chance, you must collect 2^48 128-bit

blocks.




Regards,


Quynh.




From: TLS <tls-bounces@ietf=
.org> on behalf of Markulf Kohlweiss



Date: Monday, February 13, 2017 at 10:34 AM


To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Sean Turner



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
"


PRs (#765/#769)






Hello,




Our analysis of miTLS also supports option a)




A security level of 2^-32 seems too low from a provable security


point of view, especially for a confidentiality bound.








When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.  It does not mean that at=
tackers


have only 2^(-128) chance of success. If an attacker could run 2^100

AES operations, his or her chance of success is way below 2^(-32):

this does not mean that AES has a security level of 2^(-32) or


2^(-28).




The success probability 1/2^32 means that after 2^48 AES operations,

the attacker has a success probability of 2^-32 which is practically

zero.




Also, many users don=92t know what =93confidentiality bound=94 means.<=
/div>



The current text Eric wrote talks about a number 2^24.5 of full-size

records. In many situations, the record sizes are not full size, but

different sizes. My latest suggestion text does not assume full size

records, it covers variable record sizes, it just counts AES-input

blocks or AES operations.




Regards,


Quynh.






We verified an implementation of the TLS 1.3 record


(https://eprint.iacr.org=
/2016/1178, to appear at Security & Privacy


2017) where we arrive at a combined bound for authenticity and


confidentiality that is compatible with the Iwata et al. bound.




Regards,


Markulf (for the miTLS team)




Hi,




My preference is to go with the existing text, option a).




From the github discussion, I think option c) involves a less


conservative


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should

be


aware of the weaker security guarantees it provides.




I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security

proof


for AES-GCM.




Regards,




Kenny




On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&=
gt;


wrote:




On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr=
ote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]




a) I'm happy enough with the current text (I've implemented that any



it's relatively easy).




I could live with c, but I'm opposed to b. It just doesn't make


sense.


It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.




_______________________________________________


Cfrg mailing list


Cfrg at irtf.org







_______________________________________________


TLS mailing list




_______________________________________________


TLS mailing list




















--_000_D4C8AE2830145qdangnistgov_--


From nobody Tue Feb 14 10:46: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 6A1A4129570 for ; Tue, 14 Feb 2017 10:46:03 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 zkRrx-H7oVVh for ; Tue, 14 Feb 2017 10:45:57 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0097.outbound.protection.outlook.com [23.103.201.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367E6129731 for ; Tue, 14 Feb 2017 10:45:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GB8P4EGPA4wHJUW0kCgbiUaObJD0uDz8pq0+phIcr1g=; b=u8/5GPv5ShDWD6Vm2J4vUihe6gQXo0NqqNV0mtrNQyMU/EzukDHf3AsWfsPTWNxRy/yPD9KG6+JtnNRMbGFa8TnsZPGG9XKfy0pA11spPyR6uCljzyqcLXM3X2CLa5149oySBEj18bvkxWxQuQ3he8sdG1FXUCgOTRzqtzxrVFc=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 18:45:55 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 18:45:55 +0000
From: "Dang, Quynh (Fed)" 
To: Sean Turner , "tls@ietf.org" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QAgACb9ID//85ZAIAAVXBE
Date: Tue, 14 Feb 2017 18:45:55 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>      , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.218.32]
x-ms-office365-filtering-correlation-id: 03ac788c-a2f2-4f66-a5c6-08d45509b58f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:Bdtr1r5qlT1s7JX8f2rXc8cvJ/qbU7qiZNHejaB1z94MpqUq3+a7Z6fiB7zySi4CqzkZSzTisw+GG51eGm3mR6jlkWVeY26Coot1HoYL/7ooh8n43sXXqQ/GgUjntL7N3POrU+XZqn6iHfvIrM4dz5Dj65irp4lCHhQhp1r6faRVMBouAh/w2k3QIMlUk5DrLN66lX2JPphvD7n0sKmzUWBKvQB59GYLnkvfI4GUoGQ4SU0+3WNDuYVm7dtmwPt5NHj+uqxOL1Kw3xlzeVn52AS9E+sCpdvxuuI/POz1zZb8GiRVnbiWxs1ABpnbBcBdBk+ADJ89HbV+I7CDQo4k6yw1VEW44In2Qu/bAU8JGUtZyvbMvKM149hLCDMKWpUyFdRbG+Y8iTMR00HDZC+FaXevZGlaXV2lLqeCdGMC11xlnvkrJHFDBzfaQGvGWqgZLs8NWnMMMggB2jB+H1oYtJSjg59shQnyJPGIS0oW19plGFgu/KR6zyZjRE+gr3al6yBOWD7whvYKFMBGjvgNJQ==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; 
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(24454002)(377424004)(377454003)(199003)(189002)(106116001)(6436002)(54896002)(105586002)(6506006)(106356001)(229853002)(19627405001)(122556002)(6306002)(9686003)(236005)(2501003)(77096006)(99286003)(33656002)(81003)(55016002)(25786008)(68736007)(3660700001)(6246003)(53546003)(189998001)(81166006)(2900100001)(5660300001)(606005)(38730400002)(7696004)(4326007)(102836003)(86362001)(6116002)(2950100002)(53936002)(3280700002)(93886004)(3846002)(74316002)(101416001)(8936002)(7906003)(66066001)(7736002)(2906002)(54356999)(92566002)(81156014)(76176999)(97736004)(8676002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 18:45:55.2346 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462
Archived-At: 
Cc: IRTF CFRG 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 18:46:03 -0000

--_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Sean and all,


Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/m=
sg22381.html, I have a second suggestion below.


Just replacing this sentence: "

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) security.

" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial or fu=
ll) input blocks may be encrypted with one key. For other suggestions and a=
nalysis, see the referred paper above."


Regards,

Quynh.

________________________________
From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi Atul,

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' >
Cc: Markulf Kohlweiss >=
, Antoine Delignat-Lavaud >=
, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: jus=
t one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is=
 equivalent to computation in the sense that data are produced by computati=
on. 2^x blocks =3D 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). =
And, 1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' >
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss >=
, "Paterson, Kenny"
>, Sean Turner =
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won=92t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS > on behalf of =
Markulf Kohlweiss
>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" >, Sean Turner
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Hello,
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.
Also, many users don=92t know what =93confidentiality bound=94 means.
The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.
Regards,
Quynh.
We verified an implementation of the TLS 1.3 record
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.
Regards,
Markulf (for the miTLS team)
Hi,
My preference is to go with the existing text, option a).
>From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
be
aware of the weaker security guarantees it provides.
I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.
Regards,
Kenny
On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

wrote:
On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]
a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).
I could live with c, but I'm opposed to b. It just doesn't make
sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.
_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
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


--_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











From: Dang, Quynh (Fed)

Sent: Tuesday, February 14, 2017 1:20:12 PM

To: Atul Luykx; Dang, Quynh (Fed)

Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.=
org

Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usa=
ge" PRs (#765/#769)

 






Hi Atul,<=
/div>








From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 11:17 AM

To: 'Quynh' <Quynh.Dang@nist.gov>

Cc: Markulf Kohlweiss <markulf@microsoft.com>, Antoine De=
lignat-Lavaud <antdl@microsoft.co=
m>, IRTF CFRG <cfrg@irtf.org=
>,
 "tls@ietf.org" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hey Quynh,









When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.




The claim is stronger: regardless of the number of plaintext-ciphertex=
t 


pairs available to the adversary, it will still take roughly 2^128 

operations to recover the key with AES. 














Actually =
the same claim: my claim did not require any data requirement: just one cip=
hertext block. 














This contrasts with any mode of 


operation, where adversarial success probability increases according t=
o 


the amount of data available and the computational complexity required=
 


to perform such an attack is not the limiting factor (which is the cor=
e 


of the problem we're discussing right now).














IND-CPA i=
s important. That is why I have always been supporting it. Data is equivale=
nt to computation in the sense that data are produced by computation. 2^x b=
locks =3D 2^x AES operations. 







With 2^48=
 AES operations/input blocks, the actual margin is below 2^(-33). And, 1 in=
 2^32 is 1 in 4,294, 967,296.00
 which is safe.







Quynh. 



















Regardless, correct me if I'm wrong Quynh, but you seem to have two 

issues with Eric's text:


1. the data limit recommendation is too strict, and


2. it only gives a data limit in terms of full records.







For point 1 it seems like most people would rather err on the side of =



caution instead of recommending that people switch when adversaries ha=
ve 


success probability 2^{-32}. I don't see the discussion progressing on=
 


this point, and basically a decision needs to be made.







I don't think point 2 is a problem because it gives people a good enou=
gh 


heuristic, however this can be fixed easily by minimally modifying the=
 


original text.







Atul












On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:




Hi Markulf and all,




I provided more explanation below.




  From: 'Quynh' <Q=
uynh.Dang@nist.gov>


Date: Monday, February 13, 2017 at 10:45 AM


To: Markulf Kohlweiss <mar=
kulf@microsoft.com>, "Paterson, Kenny"



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
" PRs


(#765/#769)






Hi Markulf,




The probability of a bad thing to happen is actually below (or


about) 2^(-33). It practically won=92t happen when the chance is 1

in 2^32. And, to achieve that chance, you must collect 2^48 128-bit

blocks.




Regards,


Quynh.




From: TLS <tls-bounces@ietf=
.org> on behalf of Markulf Kohlweiss



Date: Monday, February 13, 2017 at 10:34 AM


To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Sean Turner



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
"


PRs (#765/#769)






Hello,




Our analysis of miTLS also supports option a)




A security level of 2^-32 seems too low from a provable security


point of view, especially for a confidentiality bound.








When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.  It does not mean that at=
tackers


have only 2^(-128) chance of success. If an attacker could run 2^100

AES operations, his or her chance of success is way below 2^(-32):

this does not mean that AES has a security level of 2^(-32) or


2^(-28).




The success probability 1/2^32 means that after 2^48 AES operations,

the attacker has a success probability of 2^-32 which is practically

zero.




Also, many users don=92t know what =93confidentiality bound=94 means.<=
/div>



The current text Eric wrote talks about a number 2^24.5 of full-size

records. In many situations, the record sizes are not full size, but

different sizes. My latest suggestion text does not assume full size

records, it covers variable record sizes, it just counts AES-input

blocks or AES operations.




Regards,


Quynh.






We verified an implementation of the TLS 1.3 record


(https://eprint.iacr.org=
/2016/1178, to appear at Security & Privacy


2017) where we arrive at a combined bound for authenticity and


confidentiality that is compatible with the Iwata et al. bound.




Regards,


Markulf (for the miTLS team)




Hi,




My preference is to go with the existing text, option a).




From the github discussion, I think option c) involves a less


conservative


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should

be


aware of the weaker security guarantees it provides.




I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security

proof


for AES-GCM.




Regards,




Kenny




On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&=
gt;


wrote:




On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr=
ote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]




a) I'm happy enough with the current text (I've implemented that any



it's relatively easy).




I could live with c, but I'm opposed to b. It just doesn't make


sense.


It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.




_______________________________________________


Cfrg mailing list


Cfrg at irtf.org







_______________________________________________


TLS mailing list




_______________________________________________


TLS mailing list





















--_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_--


From nobody Tue Feb 14 11:45: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 6684D12943B for ; Tue, 14 Feb 2017 11:45:40 -0800 (PST)
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=unavailable 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 5VQ5oTnwEKaa for ; Tue, 14 Feb 2017 11:45:37 -0800 (PST)
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 8C9C4129717 for ; Tue, 14 Feb 2017 11:45:37 -0800 (PST)
Received: by mail-wm0-x244.google.com with SMTP id r18so5139064wmd.3 for ; Tue, 14 Feb 2017 11:45:37 -0800 (PST)
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=bzToNcj0dDUIpOb/RXD4K5BmSD4ioLRGrxo6Z4cPeRs=; b=PAUgx5Mu7Ah/ioHBtLDS0r/BF4bHW79s4+A8vpEWhypmPdwox32dUAQo/DOfyGRcIc us8zG2mTMj9Ryi1hnK5uH/nMiTht6DnRhs7+PqHyyYekR5TM2v8rEB17MbEcm6r0TkiF WbZgw4Dq/uJexyxx/r+QwzrNiEb2VHnauiFH4TzQrzFLeRV6B93ZhYzZvHWFmD2GVhQP LKrXGnwhv8p5wpwyVID3kfZO1P1pNbAu3kKBNjetxLMVYRAsS/ioT1ZA1UZvbGRaiIa7 Kw78V8N44KYE06eu0dC27BDx3JExXr4aG7jHGLZHsPwODsuxt6hFohGZ7vOK3rQL+mrY gFMA==
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=bzToNcj0dDUIpOb/RXD4K5BmSD4ioLRGrxo6Z4cPeRs=; b=SwKqH700FoPqQJYcAQc2KrjA1YTrmS3UO1dtqN+ZBMkEUrWz2YdTHMlK+SYW9q3kL6 9lNl6DJBlHYYr18XUPrMeUj/ooLX+y2cVjUegoXmBFh/5uueL2+U1j9UKFBXpB30lGXY 96i8MmTTFdJ2xiNkNpUqY0FFsUI0ySO0l/FsQeO6Bj3CELpy22kYizdv/ahYhyyLBvV9 Cc/ymfigvxrCWhe5eUXwwwTMr4ZFc69hPqtUi0Biy59XiNuoy4oZlmi/zLcLct98vq56 fkc51YPyCH1fMcJoLyghTca+tP170zpn05COs/dj+Czqd1zlhwqt8XwFqZUjzICoqjzH Xaiw==
X-Gm-Message-State: AMke39lPJGQ9zk8HVEgesOsi8KCMga0D6mpRYIxCaCB171JOATNkWAdMZabzlvNLzXgo4g==
X-Received: by 10.28.57.131 with SMTP id g125mr4744554wma.33.1487101536095; Tue, 14 Feb 2017 11:45:36 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z67sm1963135wrb.49.2017.02.14.11.45.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 11:45:35 -0800 (PST)
From: Yoav Nir 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 14 Feb 2017 21:45:32 +0200
In-Reply-To: 
To: "Dang, Quynh (Fed)" 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>        
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 19:45:40 -0000

--Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E"


--Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Quynh

> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed)  =
wrote:
>=20
> Hi Sean and all,
>=20
> Beside my suggestion at =
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html =
, I =
have a second suggestion below.
>=20
> Just replacing this sentence: "
> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
>    encrypted on a given connection while keeping a safety margin of
>    approximately 2^-57 for Authenticated Encryption (AE) security.
> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial =
or full) input blocks may be encrypted with one key. For other =
suggestions and analysis, see the referred paper above."
>=20
> Regards,
> Quynh.

I like the suggestion, but I=E2=80=99m probably missing something pretty =
basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or (since =
an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10 blocks.

Why is that 2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav



--Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, Quynh

On 14 Feb 2017, at 20:45, Dang, =
Quynh (Fed) <quynh.dang@nist.gov> wrote:

Hi Sean and all,

Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/msg22381.html=
, I have a second suggestion below.

Just replacing this sentence: "  
For AES-GCM, up to 2^24.5 =
full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) =
security.
" in Section 5.5 by this =
sentence: " For AES-GCM, up to 2^48 (partial or full) input blocks may =
be encrypted with one key. For other suggestions and analysis, see =
the referred paper =
above."

Regards,
Quynh. 

I like the suggestion, but I=E2=80=99m probably =
missing something pretty basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 =
bytes each, or (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 =
records of 2^10 blocks.

Why is that =
2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav


=

--Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E--

--Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA
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-----

iQEcBAEBCgAGBQJYo15cAAoJELhJCxUKWMyZZLkH/jEz1cx2yXnvvPPB66DUdovW
02tezRPm1rzV7fqXRwuOUCWrBMTn9KicpH0e++7aVM4ZRIqNodD7SVjgxZomb05p
O+XILGnwL0ESlz3F9kpvGFpoZm1v6xnzM/yvWTmrHxL46gXgsHc8rA+uZprlrnF/
akCjnf+4hNu6C6g1oVWBHA/xb+hTluESnVc/LC4E1ZDU/eFJKLJMhAxoeiycr3Nf
TYjiXAPAXL5OM3EfKvfep5qMpsiJvdpJf5Tefi0taQoRgOI41lAk7gOz4oWYbfxh
pADuSEq+4HWL+g3+iQCQF7SPDr07JABSfnAzibCIDOB5zArRs26iEUJR+0s3j60=
=WfZ7
-----END PGP SIGNATURE-----

--Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA--


From nobody Tue Feb 14 12:18: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 211E81296FC for ; Mon, 13 Feb 2017 09:30:27 -0800 (PST)
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, HTML_MESSAGE=0.001, 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 RuFo3ULXtQTK for ; Mon, 13 Feb 2017 09:30:25 -0800 (PST)
Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C50129559 for ; Mon, 13 Feb 2017 09:30:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 965C11A02E40 for ; Mon, 13 Feb 2017 17:30:23 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk
Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ4rKWGEsfh4 for ; Mon, 13 Feb 2017 17:30:01 +0000 (UTC)
Received: from [192.168.110.205] (host5-81-99-138.range5-81.btcentralplus.com [5.81.99.138]) (Authenticated sender: mark.dunn@objectiveintegration.uk) by mail.objectiveintegration.uk (Postfix) with ESMTPSA id AE5621A01A96 for ; Mon, 13 Feb 2017 17:30:01 +0000 (UTC)
To: tls@ietf.org
References: <000001d282d1$7769bdc0$663d3940$@objectiveintegration.uk> <20170209190530.GA20340@LK-Perkele-V2.elisa-laajakaista.fi>
From: Mark Dunn 
Message-ID: 
Date: Mon, 13 Feb 2017 17:30:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170209190530.GA20340@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------8F51043D1B83AF385CE31064"
Archived-At: 
X-Mailman-Approved-At: Tue, 14 Feb 2017 12:18:55 -0800
Subject: Re: [TLS] ticket_lifetime and generic network layer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 17:30:27 -0000

This is a multi-part message in MIME format.
--------------8F51043D1B83AF385CE31064
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for taking the time to read and respond to my queries, my 
understanding of this protocol is incomplete, but I am working hard to 
remedy that.

On 09/02/17 19:05, Ilari Liusvaara wrote:
> On Thu, Feb 09, 2017 at 12:38:50PM -0000, Mark Dunn wrote:
>> I am reading your TLS 3.1 Standard and the mailing list.
>>
>> It looks great.
>>
>> I am particularly interested in using the 0-RTT feature for IoT timestamped
>> data, which would seem immune from replay attacks
>>
>>   
>>
>> I have a couple of questions
>>
>>   
>>
>> 1) The maximum ticket lifetime is set to 7 days. Is this based on hard
>> science or arbitrary?
>>
>> If it is arbitrary then 8 days for weekly intervals or 32 for days for
>> monthly intervals would  make better commercial sense
>>
>>                 (allowing for variability in wake-up times for constrained
>> devices)
> AFAIK, it is arbitrary. However, long validity periods bring security
> issues, with having to store and protect symmetric keys for a long
> time.
If it IS arbitrary, could we have a recommendation rather than a

"Servers MUST NOT use any value more than 604800 seconds (7 days)"
>> 2) Have you considered using TLS for a generic network layer?
> Note that TLS requires in-order reliable delivery (DTLS doesn't, but
> DTLS 1.3 is currently just handwaving), and neither is available below
> transport layer.
>
>
> -Ilari

Yes DTLS, of course you are correct. I will try and rephrase my questions.

I understand "TLS 1.3 requires in-order reliable delivery", but of 
course, if the protocol relies on in-order reliable data delivery then 
it cannot be secure.
The protocol must assume the opposite in fact, that an attacker will 
break boththose requirements in every way possible.
As the TLS 1.3 protocol seems to have been tested(designed) against a 
formal state machine then clearly someone agrees with me.


If the protocol's responsibility is to secure the application data from 
the insecure world of the Internet

Application | TLS :| TCP | IP | 
<-------------------------------------------> | IP | TCP |: TLS | 
Application
\----------------------------------\/---------------------------------/
                                                 Insecure Internet

then the protocol cannot rely on the TCP handshake, neither can it rely 
on TCP's packet ordering. It would seem TCP is largely redundant as IP 
does the fragmentation and re-assembly.
TCP's only role seems to be to hold open the NAT on a firewall!

Which is why when I look at this protocol, I overlook the ordered data 
in-session ability of TLS ( /head/-of-line blocking.. blah, blah)and in 
my blinkered view see the resumption/0-RTT ability as DTLS.
Any protocol which uses IP directly (including TCP) is responsible for 
reliable data delivery whether it is as simple as an ack/nack/retry or 
uses the sophisticated windowing etc. of TCP.
If these protocols sat on (D)TLS then each of these protocols would 
drive their reliable delivery through the TLS state machine. *(this is 
exciting)*

So, for example if TCP relied on TLS instead of the other way around 
then TCP would be protected under TLS's umbrella of security.

Application | TCP | TLS | IP | 
<-------------------------------------------> | IP |: TLS | TCP | 
Application
\----------------------------\/---------------------------/
                                                 Insecure Internet

TCP's sliding window would work, but the syn/syn-ack/ack handshake would 
be sub-optimal again as early data is not available during authentication.
(D)TLS key changes look like they would happen seamlesslyunderneath.

For the Machine to Machine (or Internet of Things) world however, things 
look much rosier (to me) as "Machines Don't Browse!".
Once the server/client authentication handshake is complete:

1) is it possible to use"resumption" as a three way handshake to 
securely deliver a single packet
2) Is it possible to use "0-RTT" as a mechanism to deliver a single 
packet (if slightly less securely)

Thinking this through (slightly) more carefully now, It would not be 
possible to place (D)TLS between the IP layer and Ethernet Layer as 
Ethernet does not have fragmentationand re-assembly
3) Do you agreethat securing virtualisation with (D)TLS should be 
possible (Application / TCP / IP / VXLAN / (D)TLS / IP)
4) Do you think wireless protocols are candidates as many wireless 
protocols have small packets and perform fragmentation/re-assembly.






--------------8F51043D1B83AF385CE31064
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
    

    Thanks for taking the time to read and respond to my queries, my
      understanding of this protocol is incomplete, but I am working
      hard to remedy that.

    

    
    
On 09/02/17 19:05, Ilari Liusvaara
        wrote:

      

    

      
On Thu, Feb 09, 2017 at 12:38:50PM -0000, Mark Dunn wrote:


      

        
I am reading your TLS 3.1 Standard and the mailing list.

It looks great. 

I am particularly interested in using the 0-RTT feature for IoT timestamped
data, which would seem immune from replay attacks

 

I have a couple of questions

 

1) The maximum ticket lifetime is set to 7 days. Is this based on hard
science or arbitrary?

If it is arbitrary then 8 days for weekly intervals or 32 for days for
monthly intervals would  make better commercial sense

               (allowing for variability in wake-up times for constrained
devices)


      

      
AFAIK, it is arbitrary. However, long validity periods bring security
issues, with having to store and protect symmetric keys for a long
time.

    

    If it IS arbitrary, could we have a recommendation rather than a
      

    

    
    "Servers MUST NOT use any value more
      than 604800 seconds (7 days)"
    

      

        
2) Have you considered using TLS for a generic network layer?


      

      
Note that TLS requires in-order reliable delivery (DTLS doesn't, but
DTLS 1.3 is currently just handwaving), and neither is available below
transport layer.


-Ilari


    

    

    Yes DTLS, of course you are correct. I will try and rephrase
        my questions.

      

      I understand "TLS 1.3 requires in-order reliable delivery", but of
      course, if the protocol relies on in-order reliable data delivery
      then it cannot be secure. 

    The protocol must assume the opposite in fact, that an
      attacker will break both those requirements in every way
      possible.

    As the TLS 1.3 protocol seems to have been tested(designed)
      against a formal state machine then clearly someone agrees with
      me.

    
    
    

    

    If the protocol's responsibility is to secure the
      application data from the insecure world of the Internet

    

    Application | TLS :| TCP | IP |
      <-------------------------------------------> | IP | TCP |:
      TLS | Application

    
    
                      
      \----------------------------------\/---------------------------------/

    
                                                    Insecure
      Internet

    
    
    

    then the protocol cannot rely on the TCP
      handshake, neither can it rely on TCP's packet ordering. It would
      seem TCP is largely redundant as IP does the fragmentation and
      re-assembly.

    
    TCP's only role seems to be to hold open the NAT on a
      firewall!

    
    

    Which is why when I look at this protocol, I overlook the
      ordered data in-session ability of TLS (
    
    head-of-line blocking..
        blah, blah) and in my
      blinkered view see the resumption/0-RTT ability as DTLS.  

    Any protocol which uses IP directly (including TCP) is
      responsible for reliable data delivery whether it is as simple as
      an ack/nack/retry or uses the sophisticated windowing
      etc. of TCP. 

    If these protocols sat on (D)TLS then each of these
      protocols would drive their reliable delivery through the TLS
      state machine. (this is exciting)

    
    

    So, for example if TCP relied on TLS instead of the other
      way around then TCP would be protected under TLS's umbrella
      of security.

    
    

    Application | TCP | TLS | IP |
      <-------------------------------------------> | IP |: TLS |
      TCP | Application

    
    
    
                           
      \----------------------------\/---------------------------/

    
                                                    Insecure
      Internet

    
    
    

    TCP's sliding window would work, but the syn/syn-ack/ack
    handshake would be sub-optimal again as early
      data is not available during authentication.

    
    (D)TLS key changes look like they would happen seamlessly
      underneath.

    

    
    For the Machine to Machine (or Internet of Things) world
      however, things look much rosier (to me) as "Machines Don't
      Browse!".  

    
      Once the server/client authentication handshake is complete:

    

    1) is it possible to use "resumption" as
      a three way handshake to securely deliver a single packet

    
    2) Is it possible to use "0-RTT" as a mechanism to deliver
      a single packet (if slightly less securely)

    
    

    Thinking this through (slightly) more carefully now, It
      would not be possible to place (D)TLS between the IP layer and
      Ethernet Layer as Ethernet does not have fragmentation
      and re-assembly

    3) Do you agree that securing virtualisation
      with (D)TLS should be possible (Application / TCP / IP / VXLAN /
      (D)TLS / IP)

    4) Do you think wireless protocols are candidates as many
      wireless protocols have small packets and perform
      fragmentation/re-assembly.

    

    

    

    

    

  


--------------8F51043D1B83AF385CE31064--


From nobody Tue Feb 14 12:28: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 563DA129847 for ; Tue, 14 Feb 2017 12:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=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 Mb29CmUVNbFZ for ; Tue, 14 Feb 2017 12:28:40 -0800 (PST)
Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id C8D70129853 for ; Tue, 14 Feb 2017 12:28:40 -0800 (PST)
Received: from host86-133-224-58.range86-133.btcentralplus.com ([86.133.224.58]:30260 helo=[192.168.1.64]) by relay03.mail.eu.clara.net (relay.clara.net [81.171.239.33]:10465) with esmtpa (authdaemon_plain:drh) id 1cdjiE-0000qf-Bp  for tls@ietf.org (return-path ); Tue, 14 Feb 2017 20:28:36 +0000
To: "tls@ietf.org list" 
From: Dr Stephen Henson 
Message-ID: 
Date: Tue, 14 Feb 2017 20:28:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [TLS] Questions on certificate_extensions...
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 20:28:44 -0000

A couple of questions on the format and handling of certificate_extensions.

What format is the data that appears in certificate_extension_values? I'd say
that it should be in the same format as the content octets of the extnValue
field of Extension (from RFC5280 et al). So (for example) it would be a BIT
STRING for Key Usage and a SEQUENCE OF OBJECT IDENTIFIER for Extended Key Usage.

As regards the matching rules. How do these apply when a particular extension is
absent from the certificate? For example an absent Key Usage is often taken to
mean no Key Usage restrictions apply. If Key Usage is present in
certificate_extensions does it *require* that the Key Usage extension is
explicitly present in the certificate?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.


From nobody Tue Feb 14 13: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 D94DA129951 for ; Tue, 14 Feb 2017 13:52:10 -0800 (PST)
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, 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 Qic2EJfGrKnJ for ; Tue, 14 Feb 2017 13:52:08 -0800 (PST)
Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 8BD4F1298D0 for ; Tue, 14 Feb 2017 13:52:07 -0800 (PST)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: D7DBA13802A.AA33C
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id D7DBA13802A for ; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id D3CC520098; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id CFB5D2002C; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id C7C5940; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from c-73-71-218-252.hsd1.ca.comcast.net ([73.71.218.252]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 14 Feb 2017 22:52:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 14 Feb 2017 13:52:04 -0800
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Atul Luykx 
To: Yoav Nir 
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>         
Message-ID: 
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99.2 at cobalt
X-Virus-Status: Clean
Archived-At: 
Cc: IRTF CFRG , tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 21:52:11 -0000

> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level. The original text 
recommends switching at 2^{34.5} input blocks, corresponding to a 
success probability of 2^{-60}, whereas his text recommends switching at 
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
> Hi, Quynh
> 
>> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
>> wrote:
>> 
>> Hi Sean and all,
>> 
>> Beside my suggestion at
>> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
>> I have a second suggestion below.
>> 
>> Just replacing this sentence: "
>> 
>> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
>> be
>> encrypted on a given connection while keeping a safety margin of
>> approximately 2^-57 for Authenticated Encryption (AE) security.
>> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
>> (partial or full) input blocks may be encrypted with one key. For
>> other suggestions and analysis, see the referred paper above."
>> 
>> Regards,
>> Quynh.
> 
> I like the suggestion, but I’m probably missing something pretty
> basic about it.
> 
> 2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
> (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
> blocks.
> 
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> 
> Thanks
> 
> Yoav
> 
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Feb 14 14:00: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 A0ED1129951 for ; Tue, 14 Feb 2017 14:00:03 -0800 (PST)
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 KlPly2mDxXFT for ; Tue, 14 Feb 2017 14:00:02 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c: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 F175B129585 for ; Tue, 14 Feb 2017 14:00:01 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id r141so27927304wmg.1 for ; Tue, 14 Feb 2017 14:00:01 -0800 (PST)
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=7ma3ik0oPFELXGGpiTmYxBaOOf+IiXMYsUqCuEXlkNA=; b=pNLjuboxgjU1ydHBdNK7yTZ5FuTAp6I/XxR5k+PsNJaKD7aziOWL3/2nUgzoohk601 RdddLS3bD9j69S/PJ9vXhmLxRodgQP4rOD7NwxEdyF1997FToWqMVXOdQs3P6OCkzcqi 1LXPhW+xGUJuiXUXa6liIyUF1a9YHgWhTohObXXpwXv7xAgqfyrbJSNqekUzCDGQOY/z eDSt3x8cDQ+3s3ojNih/E10eHgj+N3vtHP3d1rK3/HZF3iOXnG9Iz6EZLlj8xPkJW8WI 2E22i73+YkDdLXYWdzHZR110T91GZzpTdgYYoMDydcQvmLnPZNiPasTjx5TqVNx7Yehn 5/Dw==
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=7ma3ik0oPFELXGGpiTmYxBaOOf+IiXMYsUqCuEXlkNA=; b=sMnS5FpRYFzWGgcdc2+NPISv8bIo0B/0vlHnx5zev6nqXkkAu2xby9SfVgcE5nI22M VBnrM215chcCJ/Qzg+TMqqTZ0qyuauj2HQRgUedGBU+p7wUHtI3HIa8kS63ie7t2SdLf fe7wOPClUt+HlhWmM2Cl3zzzsFtF3yXWKSsLpn+t0nhnWFHuhyset6XMw8Z50GzAysJk jbkB3XVrb03jCCwQl574I66yNC2uL68YI+5MflxOZYXUwKKwHpsi4/3VsPTzkywrN7a8 EKFPg5c1yq4Hah9K3lkpt0je4vgDZq3UYJyIuQhjjbQiDlbNl70bBfXiAQ3ywD/6eZ+s jtBw==
X-Gm-Message-State: AMke39l/LwIHzuXxaU1/c+8vYYMsp2QI99Evek6I7RHJxDQEIiiHGta7GceY55N0j8I81Q==
X-Received: by 10.28.185.193 with SMTP id j184mr5383249wmf.86.1487109600526; Tue, 14 Feb 2017 14:00:00 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l130sm5075646wmf.0.2017.02.14.13.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 13:59:59 -0800 (PST)
From: Yoav Nir 
Message-Id: <2B24FC67-764A-47D1-8D24-09B652DF3611@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 14 Feb 2017 23:59:57 +0200
In-Reply-To: 
To: Atul Luykx 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>          
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org list" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 22:00:04 -0000

--Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF"


--Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 14 Feb 2017, at 23:52, Atul Luykx  =
wrote:
>=20
>> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> Because he wants to lower the security level. The original text =
recommends switching at 2^{34.5} input blocks, corresponding to a =
success probability of 2^{-60}, whereas his text recommends switching at =
2^{48} blocks, corresponding to a success probability of 2^{-32}.

OK, missed that.

So I=E2=80=99m in favor of switching the phrasing to be about blocks =
rather than maximum-sized records, but not in favor of lowering the =
security level.

Yoav


--Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 14 Feb 2017, at 23:52, Atul Luykx <Atul.Luykx@esat.kuleuven.be> wrote:

Why is that 2^48 input =
blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level. =
The original text recommends switching at 2^{34.5} input blocks, =
corresponding to a success probability of 2^{-60}, whereas his text =
recommends switching at 2^{48} blocks, corresponding to a success =
probability of 2^{-32}.

OK, missed that. 

So I=E2=80=99m in favor of switching =
the phrasing to be about blocks rather than maximum-sized records, but =
not in favor of lowering the security level.

Yoav

=

--Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF--

--Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695
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-----

iQEcBAEBCgAGBQJYo33dAAoJELhJCxUKWMyZ7+0H/1iVd+9jaw+NwrdstvmvlrRb
QDbFBa6OaTfcjCyR4OQ2fkegshilI0KHSzo/RxgQXWft3nThOk/PPIMPiY+LO+LQ
iejfqGC2DHAQ6c3dm6LyJA4CLQe5K7aC56aVZkaZRUGUxlUec4tdGa2d0VwS4ftV
lB8Q42TUHFBjTz/DYvdR0MtRQkZmq5O7T0EOQG3+P2BqoYx3wRgO+OHg1o2sea4M
o1L0rTASAdINHlBOwaFjPN8Yy6ydNzhLbBr7e9jIGmPZbMF5aIhFOEVGgci1rsjm
+lwoB8oMY0uMmAwAv//7m3zNGo0cjlRXueD0Kpm40pbAByMkYMiiPaymloNKBOo=
=w/QY
-----END PGP SIGNATURE-----

--Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695--


From nobody Tue Feb 14 15: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 A8713129863 for ; Tue, 14 Feb 2017 15:07:43 -0800 (PST)
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 sWq_eZaKhwNs for ; Tue, 14 Feb 2017 15:07:42 -0800 (PST)
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 73FD01289B0 for ; Tue, 14 Feb 2017 15:07:40 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id 11so136703940qkl.3 for ; Tue, 14 Feb 2017 15:07:40 -0800 (PST)
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=m5Gm546lFj5cknf8B7qWiXT9HfP48Ro5AeNKacNOHRE=; b=K2RmUvt2I7/yLQbr4BuVvpxfBIPSTZdA9DrQ63wayez9tiB16qSIi9Ub9DE8Y89CdV us0IifXsyRl5NvjAcXS51jFHEHT29hOcRgz03uANwwGpVqUB9wQQvWwMFL9xQRl+1Wdg wFT5QaUWPJvogy0aY3FXr0trujPUl7B4XuNBZemTJVuWLpnkNxhhjEmwFFmtSbdmG0j+ fpzLNBS3Qx+J2ZrS3+VToOEOkJck4m8Mcl5WQGDegDPufW862A5wlnt13lhGT5csF+/S EtweCUnLlY7F5Ha+xbqTRmfF5u0wignfjlOLn7buqAv2flvlkl82XO6JPSAHTQZSA/FJ 3p+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=m5Gm546lFj5cknf8B7qWiXT9HfP48Ro5AeNKacNOHRE=; b=g+oV8UeEDo0yavMUWzev9tx/3lPV2o0ZT4YKgX1BhbbX94OY2JJmmZ7xOVaLTGmCly p2FSB3HKLKJwba1zintMnQUKcXB1KzP5Tv6TkE5IQrxlRtsyqgFeKoMNXSp4UW+k2zXo sj6Jj+zIr5zpxQiV1bLT4Des+gPSf9h73Nl87/ZnfTvDGEP5oEGrft2lKIFzhP1yZVlx pSZJriNStMkfQakdcTb+/+t3x7o4WLXVNEMYWo7AylXznnpG116KYNz1PJVagjrFPglB 7akU/ktFG0q8YsV2bYR+sOeb5aEZyxNL4bWzA41cMcLNCXawMW53l9PLzJnDxxg+iZp0 eQ8A==
X-Gm-Message-State: AMke39nu3e+3RHiMKOZkYs9fSBZyLL4jhnhgKElG9WfqWtYbbXB9IwBSxqCOjy6DSbjsxRHIB+7tuPe1MAAA8Q==
X-Received: by 10.55.17.73 with SMTP id b70mr17749805qkh.202.1487113659710; Tue, 14 Feb 2017 15:07:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Tue, 14 Feb 2017 15:07:39 -0800 (PST)
In-Reply-To: 
References:    
From: Martin Thomson 
Date: Wed, 15 Feb 2017 10:07:39 +1100
Message-ID: 
To: David Wong 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Cas Cremers , "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 23:07:44 -0000

On 15 February 2017 at 03:18, David Wong  wrote:
> Oups, my bad. What about if the client do send a certificate, but the server
> decides not to accept it, but goes on with the connection (I think nothing
> in the spec says that the server needs to terminate the connection if the
> client cert is not good).


Then it is up to the server to remember this condition.  If it resumes
and later assumes that the client certificate is in place, then it's a
big problem.  Of course, it's easier to NOT remember a client
certificate, so I expect that failure mode to be rare.


From nobody Tue Feb 14 17:08: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 04D1812994F for ; Tue, 14 Feb 2017 17:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 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=-1.887, SPF_HELO_PASS=-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=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 Ajh-9XdJs-ng for ; Tue, 14 Feb 2017 17:07:59 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0113.outbound.protection.outlook.com [104.47.41.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0F9129460 for ; Tue, 14 Feb 2017 17:07:59 -0800 (PST)
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=Raw+RDBTu6ZACSRdjMui6qiZfRcuiEJaqiV5UaQmjqc=; b=cSUHfETPvVjmMQTDnpIYiT1QDHFJ3YaZVV1VZbQzPsn5qwNfRpwiub8/apPhtjmIWS9o+5b/IUXy043KtdMbu/E+z05mll9trEPSE+1WC4RfU+q54i9Wsh+lQJSiW2LoDfT2qDDdUx3zy+XczsfnNOgOscDJoU6hDOBqEmoxnoE=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 01:07:55 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 01:07:55 +0000
From: Andrei Popov 
To: Dr Stephen Henson , "tls@ietf.org list" 
Thread-Topic: [TLS] Questions on certificate_extensions...
Thread-Index: AQHShwD7dCFKEYNAVUOlHuy9Qz7XuqFpP4Ag
Date: Wed, 15 Feb 2017 01:07:55 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: 0770adaa-a414-4c41-a985-08d4553f1311
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844; 
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:+EVA2nd6hkh7lx+ZWQn3rz8TJkvXNrMbqSnfrNkxckEFWES0Zjpt00lmwjNh9/rrOdI0OykWDI1Qgr7fmXxzXtfSvzdbcEF/s3b84coSFEgSix0CEkCfHZixnb8r4pj3lrrjHo6LNSYnVi1TBM38X2gUzDDL/Us/HMVHQa/8Hn+Ddw0kP6hcr8QI2M+FWo5JVogEnZWxwnvrEi3iojEz3Iy7VjPE+OvjR7ghoCcAMB7/zFMM8YPUXFyyXUB55zyt+I/WzxDeWzMOqlgbs68KMg5KNGAySh72LTxXIC18Xm9A3/obUCEYJ1Lrb5dPwo0ObKUPdaXxnev7BzJa/bsRTp4fE1YEuKJv15vly/NoCYQYgXQFwtNi3mh+zg5EXWQnzjdwgm6bcQrMJLg6/9agjZLJiL0fLzu690cjv41yCjBmmp/ojj2h6P4gzeCiShL0bMNJSZEAtYkRc4/zNKqqPrkJAr5Z+uTPJqO34XlUFHK0zZRO7JiuX2h4wkU+zAvbrDDm2ae1Ju+xxWu3l+Kpjye+fRbnQt32bbYmQypDk2Y=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(36789356921836);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; 
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(189002)(199003)(377454003)(252514010)(13464003)(105586002)(101416001)(106116001)(8936002)(305945005)(7736002)(3660700001)(6506006)(81166006)(3280700002)(54356999)(2906002)(76176999)(81156014)(102836003)(106356001)(6116002)(97736004)(50986999)(68736007)(33656002)(8676002)(6436002)(77096006)(25786008)(2900100001)(10090500001)(966004)(55016002)(9686003)(99286003)(92566002)(229853002)(7696004)(6306002)(38730400002)(189998001)(86612001)(2950100002)(5660300001)(53936002)(10290500002)(5005710100001)(8990500004)(86362001)(122556002)(74316002)(6246003)(389900002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
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: 15 Feb 2017 01:07:55.5506 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
Archived-At: 
Subject: Re: [TLS] Questions on certificate_extensions...
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 01:08:01 -0000

> So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF=
 OBJECT IDENTIFIER for Extended Key Usage.
This is correct. The idea is to use the same format your PKI library alread=
y knows how to deal with.

> As regards the matching rules. How do these apply when a particular exten=
sion is absent from the certificate?
"If the server has included a
  non-empty certificate_extensions list, the client certificate MUST
  contain all of the specified extension OIDs that the client
  recognizes."

> For example an absent Key Usage is often taken to mean no Key Usage restr=
ictions apply. If Key Usage is present in certificate_extensions does it *r=
equire* that the Key Usage extension is explicitly present in the certifica=
te?
Based on the above, yes. However, a client that does not recognize e.g. Key=
 Usage extension, must ignore and skip to the next CertificateExtension.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dr Stephen Henson
Sent: Tuesday, February 14, 2017 12:28 PM
To: tls@ietf.org list 
Subject: [TLS] Questions on certificate_extensions...

A couple of questions on the format and handling of certificate_extensions.

What format is the data that appears in certificate_extension_values? I'd s=
ay that it should be in the same format as the content octets of the extnVa=
lue field of Extension (from RFC5280 et al). So (for example) it would be a=
 BIT STRING for Key Usage and a SEQUENCE OF OBJECT IDENTIFIER for Extended =
Key Usage.

As regards the matching rules. How do these apply when a particular extensi=
on is absent from the certificate? For example an absent Key Usage is often=
 taken to mean no Key Usage restrictions apply. If Key Usage is present in =
certificate_extensions does it *require* that the Key Usage extension is ex=
plicitly present in the certificate?

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

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


From nobody Wed Feb 15 02:07: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 A4BAF1294FD for ; Wed, 15 Feb 2017 02:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, 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 i0M7Akm7JC9V for ; Wed, 15 Feb 2017 02:07:19 -0800 (PST)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 9A0D11294D8 for ; Wed, 15 Feb 2017 02:07:19 -0800 (PST)
Received: by mail-wr0-x242.google.com with SMTP id c4so5058929wrd.1 for ; Wed, 15 Feb 2017 02:07:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:from:to:cc:in-reply-to:references:subject:message-id :date:content-transfer-encoding:mime-version; bh=ys+VGXSjOMPBVKzfYLfW+4HdcSbuyv1+a/EsxO5cfdo=; b=BfAv+tSAy0pfqou8u3ZX2FAbMiuL99YCD8M6BempKL2bpBk/IaSCJLkACDGrOfuSJz uF7oJhfa2HpkzTWWfTtP1XTfDmZHPLn8ou0qpkXMzC3Ne+04jxuiKppCHU0J0FwVAMhU L6qItT1G2KgPhEVUD5oRa/G54WrVTNQUpJZFxaUzzYhn/kl0hKqQMzrhf6zWw5X+5sWo P7a7PzQqzrz+jOGkQENanx1HTGumrls/RU9nCFAr4ZjInb3sp3mbdjJyejKrvk0ChS7S facUxJwUrzW7/9I9se7g5PIlTuorAPLMqKP0cnieXaSxSgAEiP+Lhufbf3QnTexh6XVm d4Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:cc:in-reply-to:references :subject:message-id:date:content-transfer-encoding:mime-version; bh=ys+VGXSjOMPBVKzfYLfW+4HdcSbuyv1+a/EsxO5cfdo=; b=NahVEXkiLlL9bC6yQePRbPspXKontGcab7mlX8wvwWBwWaqe9IvyYIezwS4USU6MZf yMB415LxiQtefFkmckrODDD+tQZKXWUHgv7r1L8noL8OnCmV13YBkeZwTC+QW5Jy8WWd iyUlToZM4iqoLe3NGCcvDhIaAkVHdVWpaZEgJOAjNs3tigZ7x1S+TlcIu4Exei1pPWms mW5V3Jvk67gFgdOkxFDb9sJS2oMY71iiWs6UtNS9sxpNFnQHBvPiww1JpLeMM66gpi8G PstxScB4aupltpCaWb/C/YDMtRHA7sWitHLQ1W2cfEcGWX8+F2ZRJLD9Hq8iAW/in9G9 rhug==
X-Gm-Message-State: AMke39kZemuZI3NlTgAS7Rakyo3ocTqa46/8tHd4ouR5AkXztAMVL7dSNPipOaAtYEKwvw==
X-Received: by 10.223.154.100 with SMTP id z91mr3990117wrb.145.1487153238090;  Wed, 15 Feb 2017 02:07:18 -0800 (PST)
Received: from little-david.home (LFbn-1-9943-152.w86-202.abo.wanadoo.fr. [86.202.61.152]) by smtp.gmail.com with ESMTPSA id o2sm4678999wmb.28.2017.02.15.02.07.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 02:07:17 -0800 (PST)
Content-Type: text/html
User-Agent: NylasMailer-K2
From: David Wong 
To: Andrei Popov 
In-Reply-To: 
References:     
Message-ID: 
Date: Wed, 15 Feb 2017 10:07:16 +0000
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Cas Cremers , tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 10:07:20 -0000


I think I can =
agree that this is an application problem, not a TLS problem. But this =
should be mentioned in the spec nonetheless as Cas pointed.








           =20
          



From nobody Wed Feb 15 03:00: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 1CA371294C4 for ; Wed, 15 Feb 2017 03:00:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 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_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 2AX1Ku28B8nz for ; Wed, 15 Feb 2017 03:00:33 -0800 (PST)
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 462CA12952F for ; Wed, 15 Feb 2017 03:00:32 -0800 (PST)
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 3vNbt63cWFz1Hsj; Wed, 15 Feb 2017 12:00:30 +0100 (CET)
X-purgate-ID: 152705::1487156430-0000521C-011ADC44/0/0
X-purgate-size: 2427
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 3vNbt564HVzGpby; Wed, 15 Feb 2017 12:00:29 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C64081A623; Wed, 15 Feb 2017 12:00:29 +0100 (CET)
In-Reply-To: 
To: Andrei Popov 
Date: Wed, 15 Feb 2017 12:00:29 +0100 (CET)
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: <20170215110029.C64081A623@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: Cas Cremers , "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list 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, 15 Feb 2017 11:00:35 -0000

I think the issue is more about the "principle of least surprise".

The client needs to know whether it offered authentication by client cert
and which client cert it offered.  Whether the server accepted it, and
caches the accepted cert in the session or in a session ticket, is
the business of the server (it may help in troubleshooting to know,
but should not be necessary for application flow control).

Clients asserting multiple identities sounds extremely awkward to me.

We do have clients in posession of multiple client certs, but our application
must specify _before_ each TLS handshake which client identity to use (and
this information is necessary for client-side session caching,
and client-side session lookup.

There is a significant difference between cached sessions where a
specific client cert was used (or at least offered by the client),
and cached sessions where no client cert was offered.

If a client tries to access a resource through a session that is
authenticated with SSL client cert A, and the server-side authorization
decision denies access to client cert A, then this will typically
result in an access failure, _without_ the server asking for a different cert.

When no client cert has been used in a session then access to a resource
that requires a (particular) client cert may result in a request of the
server for a client cert (renegotiation up to TLSv1.2) after seeing the
request--provided that the server supports renegotiation.


-Martin



Andrei Popov wrote:
>
> Is it important for the client to know, from the TLS stack itself,
> whether client authentication succeeded or not? My assumption
> (perhaps incorrect) has been that it is the server that cares about
> the client's identity (or identities) in order to make an
> authorization decision.
> 
> This thread also seems to consider client authentication a binary state:
> the client is either authenticated, or not. In practice, the client may
> assert multiple identities, and the server may grant various levels
> of access.
> 
> Also, why should the client care whether session ticket X includes client
> identity Y? If a client resumes a TLS session with a session ticket that
> does not include (or point to) a client authenticator needed to satisfy
> the client's request, the server can initiate client auth (or deny the
> request).
> 
> Cheers,
> 
> Andrei


From nobody Wed Feb 15 04:03: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 BBFCE12952F for ; Wed, 15 Feb 2017 04:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=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 Ng-h5tf15K0T for ; Wed, 15 Feb 2017 04:03:01 -0800 (PST)
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 0072C129440 for ; Wed, 15 Feb 2017 04:03:00 -0800 (PST)
Received: by mail-wr0-x236.google.com with SMTP id k90so189036245wrc.3 for ; Wed, 15 Feb 2017 04:03:00 -0800 (PST)
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=L6YInpvokZSe7qFnMVR4+xgfbEVmtKMNYFxlAo4WfTs=; b=U8KLJAwcVyHibBd4Tdopq8kpo+9jDjbw2UheOZ4oQgIywBG0/2O6dS3MKBSwKvVc0S LCF0jon/pKNZTxmVhN9q3WeLwSb8smZbM/CKkHxN9eSiPD2MuDAthKBsvOn74v3UUteB kGfjh5IcQ2Xlesz2+PaU2YV/3uhJ5O4gpamBeKZ+UWlHl3VR0mFmw8HfKD/dX25GmAoX 7xXJWyHr32lt7x7slN3H0bhDCMN1hy874syJe4YcFXFBvg2XrH7a0Phf7Tzb5kaHUMM1 O1E5xRTZT8neQ8Ic9i2HTBRixEtbTPxiAPZvS5AUSAOUaoR982ri5iES51YlhcKIvuPm LUqQ==
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=L6YInpvokZSe7qFnMVR4+xgfbEVmtKMNYFxlAo4WfTs=; b=U5Roj7SaHfvM4nmDbesiJcJkVx/KaxmH8QOP0PS3SFxF+AWvARBaZ3ecoDLq7mqvZy q4u0cUxShczvGxiR1L9kHCA6ZMy5i0W5Rk7iq8SxbXl/bPBUclNh35Hot5/SRs92dtJf Pb9tVK5PAJ95AMVU87LusQn+Agu/119qiSY14aP3afgfALzlNxcJ5kfi4sWAcHKfEvV1 RjXvgGy9zcPlAx4n9YnrkTSHrje1kQNLBMzzaecLGKBQQnpZgWpumhLgY1giKd5VcdyW +0Ekcsf02RIc1k2N+bxBVUKIvq9wH3RfdI/JGyvXDjvFuuz+WL2LfJPq/zU6TTqve9um jjQQ==
X-Gm-Message-State: AMke39lDyFKhSgrmO5CdKKyaoGFTD0xYDJiiyTUNRd2JNBLzveDNgwe9HFWyoRcuWnTseCoeLnG+bTH5vmmwLA==
X-Received: by 10.223.139.220 with SMTP id w28mr30337439wra.172.1487160179310;  Wed, 15 Feb 2017 04:02:59 -0800 (PST)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.80.138.100 with HTTP; Wed, 15 Feb 2017 04:02:38 -0800 (PST)
In-Reply-To: <20170215110029.C64081A623@ld9781.wdf.sap.corp>
References:  <20170215110029.C64081A623@ld9781.wdf.sap.corp>
From: Cas Cremers 
Date: Wed, 15 Feb 2017 12:02:38 +0000
X-Google-Sender-Auth: VPDtS-MbjwJQQ3C6Wckg1ZsBA0w
Message-ID: 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=f403045ea69e364bf3054890765a
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 12:03:02 -0000

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

Hi,

I think the idea that "this is the best we can do" depends on quite a
number of assumptions. In theory, I think it is easy to fix, but of course
in the design space we're in, the trade offs are more complex.

We also have to consider the non-web use cases where one might expect more
symmetric guarantees between client and server.

Indeed, "principle of least surprise": I personally find this lack of
agreement for the client surprising, i.e., the fact that the client it is
not informed by the server on its authentication status, especially since
the server asked for the certificate in the first place. This is even the
case if the server doesn't implement the reject-cert-but-continue option,
for the post-handshake authentication.

I can imagine applications that depend on the assumption that the client
knows that it has been authenticated, to both decide what it should send,
or to correctly interpret what it is receiving.

To me, this means we need to at least document this. We'll draft a PR.

Best,

Cas





On Wed, Feb 15, 2017 at 11:00 AM, Martin Rex  wrote:

> I think the issue is more about the "principle of least surprise".
>
> The client needs to know whether it offered authentication by client cert
> and which client cert it offered.  Whether the server accepted it, and
> caches the accepted cert in the session or in a session ticket, is
> the business of the server (it may help in troubleshooting to know,
> but should not be necessary for application flow control).
>
> Clients asserting multiple identities sounds extremely awkward to me.
>
> We do have clients in posession of multiple client certs, but our
> application
> must specify _before_ each TLS handshake which client identity to use (and
> this information is necessary for client-side session caching,
> and client-side session lookup.
>
> There is a significant difference between cached sessions where a
> specific client cert was used (or at least offered by the client),
> and cached sessions where no client cert was offered.
>
> If a client tries to access a resource through a session that is
> authenticated with SSL client cert A, and the server-side authorization
> decision denies access to client cert A, then this will typically
> result in an access failure, _without_ the server asking for a different
> cert.
>
> When no client cert has been used in a session then access to a resource
> that requires a (particular) client cert may result in a request of the
> server for a client cert (renegotiation up to TLSv1.2) after seeing the
> request--provided that the server supports renegotiation.
>
>
> -Martin
>
>
>
> Andrei Popov wrote:
> >
> > Is it important for the client to know, from the TLS stack itself,
> > whether client authentication succeeded or not? My assumption
> > (perhaps incorrect) has been that it is the server that cares about
> > the client's identity (or identities) in order to make an
> > authorization decision.
> >
> > This thread also seems to consider client authentication a binary state:
> > the client is either authenticated, or not. In practice, the client may
> > assert multiple identities, and the server may grant various levels
> > of access.
> >
> > Also, why should the client care whether session ticket X includes client
> > identity Y? If a client resumes a TLS session with a session ticket that
> > does not include (or point to) a client authenticator needed to satisfy
> > the client's request, the server can initiate client auth (or deny the
> > request).
> >
> > Cheers,
> >
> > Andrei
>

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


Hi,

I think the idea that "this is=
 the best we can do" depends on quite a number of assumptions. In theo=
ry, I think it is easy to fix, but of course in the design space we're =
in, the trade offs are more complex.

We also have =
to consider the non-web use cases where one might expect more symmetric gua=
rantees between client and server.

Indeed, "p=
rinciple of least surprise": I personally find this lack of agreement =
for the client surprising, i.e., the fact that the client it is not informe=
d by the server on its authentication status, especially since the server a=
sked for the certificate in the first place. This is even the case if the s=
erver doesn't implement the reject-cert-but-continue option, for the po=
st-handshake authentication.

I can imagine applica=
tions that depend on the assumption that the client knows that it has been =
authenticated, to both decide what it should send, or to correctly interpre=
t what it is receiving.

To me, this means we need =
to at least document this. We'll draft a PR.

B=
est,

Cas


<=
br>


On Wed, Feb 15, 2017 at 11:00 AM, Martin Rex <mrex@sap.com>=
 wrote:
I think the issue is more =
about the "principle of least surprise".



The client needs to know whether it offered authentication by client cert
and which client cert it offered.=C2=A0 Whether the server accepted it, and=


caches the accepted cert in the session or in a session ticket, is

the business of the server (it may help in troubleshooting to know,

but should not be necessary for application flow control).



Clients asserting multiple identities sounds extremely awkward to me.



We do have clients in posession of multiple client certs, but our applicati=
on

must specify _before_ each TLS handshake which client identity to use (and<=
br>
this information is necessary for client-side session caching,

and client-side session lookup.



There is a significant difference between cached sessions where a

specific client cert was used (or at least offered by the client),

and cached sessions where no client cert was offered.



If a client tries to access a resource through a session that is

authenticated with SSL client cert A, and the server-side authorization

decision denies access to client cert A, then this will typically

result in an access failure, _without_ the server asking for a different ce=
rt.



When no client cert has been used in a session then access to a resource
that requires a (particular) client cert may result in a request of the

server for a client cert (renegotiation up to TLSv1.2) after seeing the

request--provided that the server supports renegotiation.





-Martin








Andrei Popov wrote:

>

> Is it important for the client to know, from the TLS stack itself,

> whether client authentication succeeded or not? My assumption

> (perhaps incorrect) has been that it is the server that cares about
> the client's identity (or identities) in order to make an

> authorization decision.

>

> This thread also seems to consider client authentication a binary stat=
e:

> the client is either authenticated, or not. In practice, the client ma=
y

> assert multiple identities, and the server may grant various levels
> of access.

>

> Also, why should the client care whether session ticket X includes cli=
ent

> identity Y? If a client resumes a TLS session with a session ticket th=
at

> does not include (or point to) a client authenticator needed to satisf=
y

> the client's request, the server can initiate client auth (or deny=
 the

> request).

>

> Cheers,

>

> Andrei





--f403045ea69e364bf3054890765a--


From nobody Wed Feb 15 04:11: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 965AC129567 for ; Wed, 15 Feb 2017 04:11:56 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.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 CNC3zaUkIbMT for ; Wed, 15 Feb 2017 04:11:54 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0114.outbound.protection.outlook.com [23.103.201.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEC0129495 for ; Wed, 15 Feb 2017 04:11:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D7veV6v2X2BlPwUiF362sH96WxmtHtgP7BmaOQF5x2Q=; b=MAV86Yvb00JvCPifQJMFThANJpz2fYenPu9ThyC9dn840Bm3gc5/elvSU3a74aZMIdP87Pc3jywhff3DAG/8zkrSrGIQr/bobocf/kQh8F7i1ToZBRJwvPyaTYA7fewYxHVFPgMhP2fr3IUf0eYdw1RC4UFoyZ/9F7X/Qetkxuk=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 12:11:51 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 12:11:51 +0000
From: "Dang, Quynh (Fed)" 
To: Atul Luykx , Yoav Nir 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwyaNRpm4jTNwkW4fHeK7pLqGKFpp3IA
Date: Wed, 15 Feb 2017 12:11:50 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>          
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.105.150]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:3ioq2qNaXfhh2ZevHNxSFqw9v9soSxAmz8pjc9gy3+GlJVyUT+yfQfwpZ+hlq619joha/ZUxajhjRRC/b1Lr39KD7j7wUjW/LMlIVaLRgRSp/9HC7RdZgl5ZUYuFWJm0fN31mVrg297GfIuc3+K3jNzmUmanmeSpNpwdW9FxUWT3rYqd8QoajH+ORTbn+50UUXmZm70yRY+IobR7szBSQ53XutO+gSyRCzvQGQogiMzWr7F2cqDRGVzDX99gWDlKxf3Jk97ZDE5hv9ZyTCzf/CAb9f8JTe/wgqHcB00IdGZxk1fZPhQjQpDy2Ylt6m+U70oT3ivKUWFrMG6c1PNXFwgF23cDrXH/w49QMrnNtvOJhytMHVJKdTD6hK3oUWD3h+PKxcafroI06d0rvwapK2lrCs1FyTNOXDqvB670lr/aU4Hj37uewfifuyPiBJhwi87Ys1mLGp9bnf22jdcoRsFwzYGEYu6Ov1lYh5wiR724jsovabZRVx7huhm9DoEIlOl5rsSmzBc1mGHPxYsWIw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(199003)(189002)(377424004)(229853002)(99286003)(54906002)(50986999)(76176999)(101416001)(93886004)(102836003)(54356999)(36756003)(53936002)(3846002)(389900002)(2906002)(6116002)(86362001)(3280700002)(106116001)(81156014)(81166006)(92566002)(8676002)(106356001)(6246003)(606005)(54896002)(6512007)(6306002)(3660700001)(122556002)(105586002)(189998001)(236005)(4001350100001)(66066001)(25786008)(8936002)(4326007)(6436002)(77096006)(83506001)(2950100002)(68736007)(6506006)(7736002)(5660300001)(6486002)(53546003)(2900100001)(39060400002)(97736004)(38730400002)(7906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 8c7ee9a8-5fff-4500-262d-08d4559bd2c4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; 
x-forefront-prvs: 021975AE46
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D4C9AB9C302D5qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 12:11:50.8492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 12:11:56 -0000

--_000_D4C9AB9C302D5qdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir >
Cc: 'Quynh' >, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically=
 the same: they are practically zero.  And, 2^-32 is an absolute chance in =
this case meaning that all attackers can=92t improve their chance: no matte=
r how much computational power the attacker has.

I don=92t understand why the number 2^-60 is your special chosen number for=
 this ? In your =93theory=94, 2^-112 would be in =93higher=94 security than=
 2^-60.

Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) >
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I=92m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
------
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--_000_D4C9AB9C302D5qdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Atul,







I hope you had a happy Valentine! 









From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 4:52 PM

To: Yoav Nir <ynir.ietf@gmail.com>

Cc: 'Quynh' <Quynh.Dang@nist.gov>, IRTF CFRG <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.=
org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)

















Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Because he wants to lower the security level. 














I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practi=
cally the same: they are practically zero.  And, 2^-32 is an absolute =
chance in this case meaning that all attackers can=92t improve their chance=
: no matter how much computational power
 the attacker has.   







I don=92t understand why the number 2^-60 is your special chosen numbe=
r for this ? In your =93theory=94, 2^-112 would be in =93higher=94 security=
 than 2^-60. 







Quynh.  



















The original text 


recommends switching at 2^{34.5} input blocks, corresponding to a 

success probability of 2^{-60}, whereas his text recommends switching =
at 


2^{48} blocks, corresponding to a success probability of 2^{-32}.






Atul







On 2017-02-14 11:45, Yoav Nir wrote:




Hi, Quynh






On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.dang@nist.gov>


wrote:




Hi Sean and all,




Beside my suggestion at



I have a second suggestion below.




Just replacing this sentence: "




For AES-GCM, up to 2^24.5 full-size records (about 24 million) may

be


encrypted on a given connection while keeping a safety margin of


approximately 2^-57 for Authenticated Encryption (AE) security.


" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48=



(partial or full) input blocks may be encrypted with one key. For

other suggestions and analysis, see the referred paper above."



Regards,


Quynh.






I like the suggestion, but I=92m probably missing something pretty

basic about it.




2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or

(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10

blocks.




Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Thanks




Yoav








Links:


------



_______________________________________________


TLS mailing list




















--_000_D4C9AB9C302D5qdangnistgov_--


From nobody Wed Feb 15 05:46: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 F38EB1295E8 for ; Wed, 15 Feb 2017 05:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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=rhul.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 7KXJ3AaPExyP for ; Wed, 15 Feb 2017 05:46:31 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20055.outbound.protection.outlook.com [40.107.2.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B761294AD for ; Wed, 15 Feb 2017 05:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zTl04xdrJ75e17uqBfz2L0OHNo/+X6LxAHPLUiveiaw=; b=zd0dEnLK0DOkYQw8OWrhyI6fh4QFNAog+OGa7tETBqd7OTqJJKc1KA3JwLefRQiFMTz0Jkaf+B2tevNYNUlc1UsCq1gZAzQt3WM9ePxA0ZCoPp91gtQvGYQG3yf/ZapJSJV4gMXoKhp1nVh6VID7y3WxqrwjkXRImI5Ve4OhFMM=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 13:46:28 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 13:46:28 +0000
From: "Paterson, Kenny" 
To: "Dang, Quynh (Fed)" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwykYuvgBCblgkOlDzVRxLEvWqFp+0YAgAAacIA=
Date: Wed, 15 Feb 2017 13:46:28 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>          , 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [219.59.14.82]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:UjeNrd4xMu3XNr7jy+YyHoJM9Imrl6CNIvn3/nNbJRoRcG/Uj80nnHTU/U3d0tNEi8cYlTQ3DFpcHaNGXyn5JTGDwHu9vbWYDmdGPAJRdADLmyCylP/TTv9JZE5H3erIecEK8aTpyxPVu+m6lDqKVLGYpqqEw6V2z+9p7OF2iUk/EWqyRFjO4Sp5H0z9xuK4wlK4QAl+ivZ/mei/hztpa8rg+rXFFyxwvi4PYMsHWo4PA9bC7iPrEihV1/6bwlvkJNKS4wKpMnKJU29V4dWajhSwP5V1iJC5XlaPhzFTKK/QhOgS0CNYONDjoWAQukhfdEU1P4M9jSSjHJ2ShJ1sGiOTFNGiDW8ESgLgC2OGAX4c00qOHSyybVTKnxP9Difh0mhvhFng8R5Eoh/IPDsO1HdeJMQSvwbUW7sur/bOO/13bt/pOfDTzNXVs0Keg/n753QijrANf5y3kZHiTijfmdsr3ZrXw9dk4meDtsXlDjp+7WiIhe3VOFoCk0zsb4KCDnucJfhDEmRFMUOT2CkN4w==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(189002)(24454002)(377424004)(199003)(6246003)(54356999)(7736002)(7906003)(106356001)(106116001)(105586002)(97736004)(101416001)(2906002)(50986999)(189998001)(74482002)(66066001)(4326007)(93886004)(33656002)(76176999)(3846002)(6116002)(102836003)(6916009)(81166006)(36756003)(2900100001)(53546003)(8936002)(8676002)(92566002)(229853002)(81156014)(38730400002)(236005)(82746002)(68736007)(83716003)(5660300001)(39060400002)(122556002)(53936002)(86362001)(54906002)(25786008)(77096006)(6512007)(2950100002)(42882006)(6436002)(8656002)(6306002)(3280700002)(6506006)(606005)(6486002)(110136004)(54896002)(389900002)(99286003)(3660700001)(104396002)(19625805005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 1c2bb23d-854c-4996-932f-08d455a90aae
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1908; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908; 
x-forefront-prvs: 021975AE46
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_"
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 13:46:28.2359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 13:46:34 -0000

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

SGkgUXV5bmgsDQoNCkknbSBtZWFudCB0byBiZSBvbiB2YWNhdGlvbiwgYnV0IEknbSBmaW5kaW5n
IHRoaXMgb24tZ29pbmcgZGlzY3Vzc2lvbiBmYXNjaW5hdGluZywgc28gSSdtIGNoaXBwaW5nIGlu
IGFnYWluLg0KDQpPbiAxNSBGZWIgMjAxNywgYXQgMjE6MTIsIERhbmcsIFF1eW5oIChGZWQpIDxx
dXluaC5kYW5nQG5pc3QuZ292PG1haWx0bzpxdXluaC5kYW5nQG5pc3QuZ292Pj4gd3JvdGU6DQoN
CkhpIEF0dWwsDQoNCkkgaG9wZSB5b3UgaGFkIGEgaGFwcHkgVmFsZW50aW5lIQ0KDQpGcm9tOiBB
dHVsIEx1eWt4IDxBdHVsLkx1eWt4QGVzYXQua3VsZXV2ZW4uYmU8bWFpbHRvOkF0dWwuTHV5a3hA
ZXNhdC5rdWxldXZlbi5iZT4+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxNyBhdCA0
OjUyIFBNDQpUbzogWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnluaXIuaWV0
ZkBnbWFpbC5jb20+Pg0KQ2M6ICdRdXluaCcgPFF1eW5oLkRhbmdAbmlzdC5nb3Y8bWFpbHRvOlF1
eW5oLkRhbmdAbmlzdC5nb3Y+PiwgSVJURiBDRlJHIDxjZnJnQGlydGYub3JnPG1haWx0bzpjZnJn
QGlydGYub3JnPj4sICJ0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0
Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1RMU10gW0NmcmddIENs
b3Npbmcgb3V0IHRsczEuMyAiTGltaXRzIG9uIGtleSB1c2FnZSIgUFJzICgjNzY1LyM3NjkpDQoN
CldoeSBpcyB0aGF0IDJeNDggaW5wdXQgYmxvY2tzIHJhdGhlciB0aGFuIDJeMzQuNSBpbnB1dCBi
bG9ja3M/DQpCZWNhdXNlIGhlIHdhbnRzIHRvIGxvd2VyIHRoZSBzZWN1cml0eSBsZXZlbC4NCg0K
SSByZXNwZWN0ZnVsbHkgZGlzYWdyZWUuIDJeLTMyLCAyXi0zMywgMl4tNTcsIDJeLTYwLCAyXi0x
MTIgYXJlIHByYWN0aWNhbGx5IHRoZSBzYW1lOiB0aGV5IGFyZSBwcmFjdGljYWxseSB6ZXJvLg0K
DQpJJ20gbm90IGNsZWFyIHdoYXQgeW91IG1lYW4gYnkgInByYWN0aWNhbGx5IiBoZXJlLiBUaGV5
J3JlIGNsZWFybHkgbm90IHRoZSBzYW1lIGFzIHJlYWwgbnVtYmVycy4gQW5kIGlmIHdlIGFyZSBi
ZWluZyBjb25zZXJ2YXRpdmUgYWJvdXQgc2VjdXJpdHksIHRoZW4gdGhlIGV4dHJlbWVzIGluIHlv
dXIgbGlzdCBhcmUgYSBsb25nIHdheSBhcGFydC4NCg0KQW5kLCAyXi0zMiBpcyBhbiBhYnNvbHV0
ZSBjaGFuY2UgaW4gdGhpcyBjYXNlIG1lYW5pbmcgdGhhdCBhbGwgYXR0YWNrZXJzIGNhbuKAmXQg
aW1wcm92ZSB0aGVpciBjaGFuY2U6IG5vIG1hdHRlciBob3cgbXVjaCBjb21wdXRhdGlvbmFsIHBv
d2VyIHRoZSBhdHRhY2tlciBoYXMuDQoNCkEgc3VmZmljaWVudGx5IHBvd2VyZnVsIGFkdmVyc2Fy
eSBjb3VsZCBjYXJyeSBvdXQgYW4gZXhoYXVzdGl2ZSBrZXkgc2VhcmNoIGZvciBHQ00ncyB1bmRl
cmx5aW5nIEFFUyBrZXkuIFNvIEknbSBub3Qgc3VyZSB3aGF0IHlvdSdyZSBjbGFpbWluZyBoZXJl
IHdoZW4geW91IHNwZWFrIG9mICJhYnNvbHV0ZSBjaGFuY2UiLg0KDQpJIGRvbuKAmXQgdW5kZXJz
dGFuZCB3aHkgdGhlIG51bWJlciAyXi02MCBpcyB5b3VyIHNwZWNpYWwgY2hvc2VuIG51bWJlciBm
b3IgdGhpcyA/DQoNClRoaXMgaXMgYSBiaXQgc3VidGxlLCBidXQgSSdsbCB0cnkgdG8gZXhwbGFp
biBpbiBzaW1wbGUgdGVybXMuDQoNCldlIGNhbiBjb252ZW5pZW50bHkgcHJvdmUgYSBib3VuZCBv
ZiBhYm91dCB0aGlzIHNpemUgKGFjdHVhbGx5IDJeLTU3KSBmb3IgSU5ULUNUWFQgZm9yIGEgd2lk
ZSByYW5nZSBvZiBwYXJhbWV0ZXJzIGNvdmVyaW5nIGJvdGggVExTIGFuZCBEVExTICh3aGVyZSBt
YW55IHZlcmlmaWNhdGlvbiBmYWlsdXJlcyBtYXkgYmUgcGVybWl0dGVkKS4gVGhlbiwgc2luY2Ug
d2UncmUgdWx0aW1hdGVseSBpbnRlcmVzdGVkIGluIEFFIHNlY3VyaXR5LCB3ZSB3b3VsZCBsaWtl
IHRvIChyb3VnaGx5KSBtYXRjaCB0aGlzIGZvciBJTkQtQ1BBIHNlY3VyaXR5LCB0byBnZXQgYXMg
Z29vZCBhIGJvdW5kIGFzIHdlIGNhbiBmb3IgQUUgc2VjdXJpdHkgKHRoZSBzZWN1cml0eSBib3Vu
ZHMgZm9yIHRoZSB0d28gbm90aW9ucyBzdW0gdG8gZ2l2ZSBhbiBBRSBzZWN1cml0eSBib3VuZCAt
IHNlZSBwYWdlIDIgb2YgdGhlICJBRSBib3VuZHMiIG5vdGUpLg0KDQpJbiB2aWV3IG9mIHRoZSBJ
TlQtQ1RYVCBib3VuZCB0aGVyZSdzIG5vIHBvaW50IHB1c2hpbmcgdGhlIElORC1DUEEgYm91bmQg
bXVjaCBsb3dlciB0aGFuIDJeLTYwIGlmIHRoZSB1bHRpbWF0ZSB0YXJnZXQgaXMgQUUgc2VjdXJp
dHkuIEl0IGp1c3QgaHVydHMgdGhlIGRhdGEgbGltaXRzIG1vcmUgd2l0aG91dCBzaWduaWZpY2Fu
dGx5IGltcHJvdmluZyBBRSBzZWN1cml0eS4NCg0KRmluYWxseSwgMl4tNjAgaXMgbm90ICpvdXIq
IHNwZWNpYWwgY2hvc2VuIG51bWJlci4gV2Ugd3JvdGUgYSBub3RlIHRoYXQgY29udGFpbmVkIGEg
dGFibGUgb2YgdmFsdWVzLCBhbmQgaXQncyB3b3J0aCBub3RpbmcgdGhhdCB3ZSBkaWQgbm90IG1h
a2UgYSBzcGVjaWZpYyByZWNvbW1lbmRhdGlvbiBpbiBvdXIgbm90ZSBmb3Igd2hpY2ggcm93IG9m
IHRoZSB0YWJsZSB0byBzZWxlY3QuDQoNCihOYXR1cmFsbHksIHRob3VnaCwgd2UnZCBsaWtlIHNl
Y3VyaXR5IHRvIGJlIGFzIGhpZ2ggYXMgcG9zc2libGUgd2l0aG91dCBtYWtpbmcgcmVrZXlpbmcg
YSBmcmVxdWVudCBldmVudC4gSXQncyBhIGNvbnRpbnVpbmcgc3VycHJpc2UgdG8gbWUgdGhhdCB5
b3UgYXJlIHB1c2hpbmcgZm9yIGFuIG9wdGlvbiB0aGF0IGFjdHVhbGx5IHJlZHVjZXMgc2VjdXJp
dHkgd2hlbiBhY2hpZXZpbmcgaGlnaGVyIHNlY3VyaXR5IGRvZXMgbm90IHNlZW0gdG8gY2F1c2Ug
YW55IHByb2JsZW1zIGZvciBpbXBsZW1lbnRvcnMuKQ0KDQpJbiB5b3VyIOKAnHRoZW9yeeKAnSwg
Ml4tMTEyIHdvdWxkIGJlIGluIOKAnGhpZ2hlcuKAnSBzZWN1cml0eSB0aGFuIDJeLTYwLg0KDQpJ
dCBjZXJ0YWlubHkgd291bGQsIGlmIGl0IHdlcmUgYWNoaWV2YWJsZSAod2hpY2ggaXQgaXMgbm90
IGZvciBHQ00gd2l0aG91dCBwdXR0aW5nIHNvbWUgcXVpdGUgZXh0cmVtZSBsaW1pdHMgb24gZGF0
YSBwZXIga2V5KS4NCg0KQ2hlZXJzLA0KDQpLZW5ueQ0KDQpRdXluaC4NCg0KDQpUaGUgb3JpZ2lu
YWwgdGV4dA0KcmVjb21tZW5kcyBzd2l0Y2hpbmcgYXQgMl57MzQuNX0gaW5wdXQgYmxvY2tzLCBj
b3JyZXNwb25kaW5nIHRvIGENCnN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTYwfSwgd2hlcmVh
cyBoaXMgdGV4dCByZWNvbW1lbmRzIHN3aXRjaGluZyBhdA0KMl57NDh9IGJsb2NrcywgY29ycmVz
cG9uZGluZyB0byBhIHN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTMyfS4NCg0KQXR1bA0KDQpP
biAyMDE3LTAyLTE0IDExOjQ1LCBZb2F2IE5pciB3cm90ZToNCkhpLCBRdXluaA0KT24gMTQgRmVi
IDIwMTcsIGF0IDIwOjQ1LCBEYW5nLCBRdXluaCAoRmVkKSA8cXV5bmguZGFuZ0BuaXN0Lmdvdjxt
YWlsdG86cXV5bmguZGFuZ0BuaXN0Lmdvdj4+DQp3cm90ZToNCkhpIFNlYW4gYW5kIGFsbCwNCkJl
c2lkZSBteSBzdWdnZXN0aW9uIGF0DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL3Rscy9jdXJyZW50L21zZzIyMzgxLmh0bWwgWzFdLA0KSSBoYXZlIGEgc2Vjb25kIHN1Z2dl
c3Rpb24gYmVsb3cuDQpKdXN0IHJlcGxhY2luZyB0aGlzIHNlbnRlbmNlOiAiDQpGb3IgQUVTLUdD
TSwgdXAgdG8gMl4yNC41IGZ1bGwtc2l6ZSByZWNvcmRzIChhYm91dCAyNCBtaWxsaW9uKSBtYXkN
CmJlDQplbmNyeXB0ZWQgb24gYSBnaXZlbiBjb25uZWN0aW9uIHdoaWxlIGtlZXBpbmcgYSBzYWZl
dHkgbWFyZ2luIG9mDQphcHByb3hpbWF0ZWx5IDJeLTU3IGZvciBBdXRoZW50aWNhdGVkIEVuY3J5
cHRpb24gKEFFKSBzZWN1cml0eS4NCiIgaW4gU2VjdGlvbiA1LjUgYnkgdGhpcyBzZW50ZW5jZTog
IiBGb3IgQUVTLUdDTSwgdXAgdG8gMl40OA0KKHBhcnRpYWwgb3IgZnVsbCkgaW5wdXQgYmxvY2tz
IG1heSBiZSBlbmNyeXB0ZWQgd2l0aCBvbmUga2V5LiBGb3INCm90aGVyIHN1Z2dlc3Rpb25zIGFu
ZCBhbmFseXNpcywgc2VlIHRoZSByZWZlcnJlZCBwYXBlciBhYm92ZS4iDQpSZWdhcmRzLA0KUXV5
bmguDQpJIGxpa2UgdGhlIHN1Z2dlc3Rpb24sIGJ1dCBJ4oCZbSBwcm9iYWJseSBtaXNzaW5nIHNv
bWV0aGluZyBwcmV0dHkNCmJhc2ljIGFib3V0IGl0Lg0KMl4yNC41IGZ1bGwtc2l6ZSByZWNvcmRz
IGlzIDJeMjQuNSByZWNvcmRzIG9mIDJeMTQgYnl0ZXMgZWFjaCwgb3INCihzaW5jZSBhbiBBRVMg
YmxvY2sgaXMgMTYgYnl0ZXMgb3IgMl40IGJ5dGVzKSAyXjI0LjUgcmVjb3JkcyBvZiAyXjEwDQpi
bG9ja3MuDQpXaHkgaXMgdGhhdCAyXjQ4IGlucHV0IGJsb2NrcyByYXRoZXIgdGhhbiAyXjM0LjUg
aW5wdXQgYmxvY2tzPw0KVGhhbmtzDQpZb2F2DQpMaW5rczoNCi0tLS0tLQ0KWzFdIGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMjIzODEuaHRtbA0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls
aW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxt
YWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by90bHMNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PkhpIFF1eW5oLDxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0
dXJlIj5JJ20gbWVhbnQgdG8gYmUgb24gdmFjYXRpb24sIGJ1dCBJJ20gZmluZGluZyB0aGlzIG9u
LWdvaW5nIGRpc2N1c3Npb24gZmFzY2luYXRpbmcsIHNvIEknbSBjaGlwcGluZyBpbiBhZ2Fpbi4m
bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KT24gMTUgRmViIDIwMTcsIGF0IDIxOjEyLCBEYW5nLCBR
dXluaCAoRmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1eW5oLmRhbmdAbmlzdC5nb3YiPnF1eW5o
LmRhbmdAbmlzdC5nb3Y8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+SGkgQXR1bCw8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PkkgaG9wZSB5b3UgaGFkIGEgaGFwcHkgVmFsZW50aW5lISZuYnNwOzwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln
bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M
RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47
IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF
Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BdHVsIEx1eWt4ICZsdDs8YSBocmVmPSJtYWls
dG86QXR1bC5MdXlreEBlc2F0Lmt1bGV1dmVuLmJlIj5BdHVsLkx1eWt4QGVzYXQua3VsZXV2ZW4u
YmU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3Nw
YW4+VHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTcgYXQgNDo1MiBQTTxicj4NCjxzcGFuIHN0eWxl
PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPllvYXYgTmlyICZsdDs8YSBocmVmPSJtYWls
dG86eW5pci5pZXRmQGdtYWlsLmNvbSI+eW5pci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+J1F1eW5oJyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOlF1eW5oLkRhbmdAbmlzdC5nb3YiPlF1eW5oLkRhbmdAbmlzdC5nb3Y8L2E+
Jmd0OywgSVJURiBDRlJHICZsdDs8YSBocmVmPSJtYWlsdG86Y2ZyZ0BpcnRmLm9yZyI+Y2ZyZ0Bp
cnRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNA
aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq
ZWN0OiA8L3NwYW4+UmU6IFtUTFNdIFtDZnJnXSBDbG9zaW5nIG91dCB0bHMxLjMgJnF1b3Q7TGlt
aXRzIG9uIGtleSB1c2FnZSZxdW90OyBQUnMgKCM3NjUvIzc2OSk8YnI+DQo8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP
Q0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAw
IDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1B
Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1
YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pldo
eSBpcyB0aGF0IDJeNDggaW5wdXQgYmxvY2tzIHJhdGhlciB0aGFuIDJeMzQuNSBpbnB1dCBibG9j
a3M/PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkJlY2F1c2UgaGUgd2FudHMgdG8gbG93ZXIg
dGhlIHNlY3VyaXR5IGxldmVsLiA8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHJlc3BlY3RmdWxseSBkaXNhZ3Jl
ZS4gMl4tMzIsIDJeLTMzLCAyXi01NywgMl4tNjAsIDJeLTExMiBhcmUgcHJhY3RpY2FsbHkgdGhl
IHNhbWU6IHRoZXkgYXJlIHByYWN0aWNhbGx5IHplcm8uICZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JJ20gbm90IGNsZWFyIHdoYXQg
eW91IG1lYW4gYnkgJnF1b3Q7cHJhY3RpY2FsbHkmcXVvdDsgaGVyZS4gVGhleSdyZSBjbGVhcmx5
IG5vdCB0aGUgc2FtZSBhcyByZWFsIG51bWJlcnMuIEFuZCBpZiB3ZSBhcmUgYmVpbmcgY29uc2Vy
dmF0aXZlIGFib3V0IHNlY3VyaXR5LCB0aGVuIHRoZSBleHRyZW1lcyBpbiB5b3VyIGxpc3QgYXJl
IGEgbG9uZyB3YXkgYXBhcnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5BbmQsIDJeLTMyIGlzIGFuIGFic29sdXRl
IGNoYW5jZSBpbiB0aGlzIGNhc2UgbWVhbmluZyB0aGF0IGFsbCBhdHRhY2tlcnMgY2Fu4oCZdCBp
bXByb3ZlIHRoZWlyIGNoYW5jZTogbm8gbWF0dGVyIGhvdyBtdWNoIGNvbXB1dGF0aW9uYWwgcG93
ZXIgdGhlIGF0dGFja2VyIGhhcy4gJm5ic3A7Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpBIHN1ZmZpY2llbnRseSBwb3dlcmZ1bCBhZHZlcnNh
cnkgY291bGQgY2Fycnkgb3V0IGFuIGV4aGF1c3RpdmUga2V5IHNlYXJjaCBmb3IgR0NNJ3MgdW5k
ZXJseWluZyBBRVMga2V5LiBTbyBJJ20gbm90IHN1cmUgd2hhdCB5b3UncmUgY2xhaW1pbmcgaGVy
ZSB3aGVuIHlvdSBzcGVhayBvZiAmcXVvdDthYnNvbHV0ZSBjaGFuY2UmcXVvdDsuJm5ic3A7DQo8
ZGl2PiZuYnNwOw0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+
SSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHRoZSBudW1iZXIgMl4tNjAgaXMgeW91ciBzcGVjaWFs
IGNob3NlbiBudW1iZXIgZm9yIHRoaXMgPw0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgYSBiaXQgc3VidGxlLCBidXQgSSdsbCB0
cnkgdG8gZXhwbGFpbiBpbiBzaW1wbGUgdGVybXMuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KV2UgY2FuIGNvbnZlbmllbnRseSBwcm92ZSBhIGJvdW5kIG9mIGFib3V0IHRoaXMgc2l6
ZSAoYWN0dWFsbHkgMl4tNTcpIGZvciBJTlQtQ1RYVCBmb3IgYSB3aWRlIHJhbmdlIG9mIHBhcmFt
ZXRlcnMgY292ZXJpbmcgYm90aCBUTFMgYW5kIERUTFMgKHdoZXJlIG1hbnkgdmVyaWZpY2F0aW9u
IGZhaWx1cmVzIG1heSBiZSBwZXJtaXR0ZWQpLiBUaGVuLCBzaW5jZSB3ZSdyZSB1bHRpbWF0ZWx5
IGludGVyZXN0ZWQgaW4gQUUgc2VjdXJpdHksIHdlIHdvdWxkDQogbGlrZSB0byAocm91Z2hseSkg
bWF0Y2ggdGhpcyBmb3IgSU5ELUNQQSBzZWN1cml0eSwgdG8gZ2V0IGFzIGdvb2QgYSBib3VuZCBh
cyB3ZSBjYW4gZm9yIEFFIHNlY3VyaXR5ICh0aGUgc2VjdXJpdHkgYm91bmRzIGZvciB0aGUgdHdv
IG5vdGlvbnMgc3VtIHRvIGdpdmUgYW4gQUUgc2VjdXJpdHkgYm91bmQgLSBzZWUgcGFnZSAyIG9m
IHRoZSAmcXVvdDtBRSBib3VuZHMmcXVvdDsgbm90ZSkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5JbiB2aWV3IG9mIHRoZSBJTlQtQ1RYVCBib3VuZCB0aGVyZSdzIG5vIHBv
aW50IHB1c2hpbmcgdGhlIElORC1DUEEgYm91bmQgbXVjaCBsb3dlciB0aGFuIDJeLTYwIGlmIHRo
ZSB1bHRpbWF0ZSB0YXJnZXQgaXMgQUUgc2VjdXJpdHkuIEl0IGp1c3QgaHVydHMgdGhlIGRhdGEg
bGltaXRzIG1vcmUgd2l0aG91dCBzaWduaWZpY2FudGx5IGltcHJvdmluZyBBRSBzZWN1cml0eS4m
bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZpbmFsbHksIDJeLTYwIGlzIG5v
dCAqb3VyKiBzcGVjaWFsIGNob3NlbiBudW1iZXIuIFdlIHdyb3RlIGEgbm90ZSB0aGF0IGNvbnRh
aW5lZCBhIHRhYmxlIG9mIHZhbHVlcywgYW5kIGl0J3Mgd29ydGggbm90aW5nIHRoYXQgd2UgZGlk
IG5vdCBtYWtlIGEgc3BlY2lmaWMgcmVjb21tZW5kYXRpb24gaW4gb3VyIG5vdGUgZm9yIHdoaWNo
IHJvdyBvZiB0aGUgdGFibGUgdG8gc2VsZWN0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+KE5hdHVyYWxseSwgdGhvdWdoLCB3ZSdkIGxpa2Ugc2VjdXJpdHkgdG8gYmUgYXMg
aGlnaCBhcyBwb3NzaWJsZSB3aXRob3V0IG1ha2luZyByZWtleWluZyBhIGZyZXF1ZW50IGV2ZW50
LiBJdCdzIGEgY29udGludWluZyBzdXJwcmlzZSB0byBtZSB0aGF0IHlvdSBhcmUgcHVzaGluZyBm
b3IgYW4gb3B0aW9uIHRoYXQgYWN0dWFsbHkgcmVkdWNlcyBzZWN1cml0eSB3aGVuIGFjaGlldmlu
ZyBoaWdoZXIgc2VjdXJpdHkgZG9lcyBub3Qgc2VlbSB0bw0KIGNhdXNlIGFueSBwcm9ibGVtcyBm
b3IgaW1wbGVtZW50b3JzLikmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5JbiB5b3VyIOKAnHRoZW9yeeKA
nSwgMl4tMTEyIHdvdWxkIGJlIGluIOKAnGhpZ2hlcuKAnSBzZWN1cml0eSB0aGFuIDJeLTYwLiZu
YnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5JdCBjZXJ0YWlubHkgd291bGQsIGlmIGl0IHdlcmUgYWNoaWV2YWJsZSAod2hpY2ggaXQgaXMg
bm90IGZvciBHQ00gd2l0aG91dCBwdXR0aW5nIHNvbWUgcXVpdGUgZXh0cmVtZSBsaW1pdHMgb24g
ZGF0YSBwZXIga2V5KS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVy
cyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pktlbm55Jm5ic3A7PC9kaXY+DQo8YnI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5RdXlu
aC4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz
cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP
T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg
c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj5UaGUgb3JpZ2luYWwgdGV4dCA8L2Rpdj4NCjxkaXY+cmVjb21tZW5kcyBzd2l0Y2hpbmcg
YXQgMl57MzQuNX0gaW5wdXQgYmxvY2tzLCBjb3JyZXNwb25kaW5nIHRvIGEgPC9kaXY+DQo8ZGl2
PnN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTYwfSwgd2hlcmVhcyBoaXMgdGV4dCByZWNvbW1l
bmRzIHN3aXRjaGluZyBhdCA8L2Rpdj4NCjxkaXY+Ml57NDh9IGJsb2NrcywgY29ycmVzcG9uZGlu
ZyB0byBhIHN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTMyfS48L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PkF0dWw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uIDIwMTct
MDItMTQgMTE6NDUsIFlvYXYgTmlyIHdyb3RlOjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19P
VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRk
ZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2PkhpLCBR
dXluaDwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS
SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsg
UEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj5PbiAxNCBGZWIgMjAxNywg
YXQgMjA6NDUsIERhbmcsIFF1eW5oIChGZWQpICZsdDs8YSBocmVmPSJtYWlsdG86cXV5bmguZGFu
Z0BuaXN0LmdvdiI+cXV5bmguZGFuZ0BuaXN0LmdvdjwvYT4mZ3Q7PC9kaXY+DQo8ZGl2Pndyb3Rl
OjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+SGkgU2VhbiBhbmQgYWxsLDwvZGl2Pg0KPGRpdj48
L2Rpdj4NCjxkaXY+QmVzaWRlIG15IHN1Z2dlc3Rpb24gYXQ8L2Rpdj4NCjxkaXY+PGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMjM4
MS5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50
L21zZzIyMzgxLmh0bWw8L2E+IFsxXSw8L2Rpdj4NCjxkaXY+SSBoYXZlIGEgc2Vjb25kIHN1Z2dl
c3Rpb24gYmVsb3cuPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5KdXN0IHJlcGxhY2luZyB0aGlz
IHNlbnRlbmNlOiAmcXVvdDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkZvciBBRVMtR0NNLCB1
cCB0byAyXjI0LjUgZnVsbC1zaXplIHJlY29yZHMgKGFib3V0IDI0IG1pbGxpb24pIG1heTwvZGl2
Pg0KPGRpdj5iZTwvZGl2Pg0KPGRpdj5lbmNyeXB0ZWQgb24gYSBnaXZlbiBjb25uZWN0aW9uIHdo
aWxlIGtlZXBpbmcgYSBzYWZldHkgbWFyZ2luIG9mPC9kaXY+DQo8ZGl2PmFwcHJveGltYXRlbHkg
Ml4tNTcgZm9yIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiAoQUUpIHNlY3VyaXR5LjwvZGl2Pg0K
PGRpdj4mcXVvdDsgaW4gU2VjdGlvbiA1LjUgYnkgdGhpcyBzZW50ZW5jZTogJnF1b3Q7IEZvciBB
RVMtR0NNLCB1cCB0byAyXjQ4PC9kaXY+DQo8ZGl2PihwYXJ0aWFsIG9yIGZ1bGwpIGlucHV0IGJs
b2NrcyBtYXkgYmUgZW5jcnlwdGVkIHdpdGggb25lIGtleS4gRm9yPC9kaXY+DQo8ZGl2Pm90aGVy
IHN1Z2dlc3Rpb25zIGFuZCBhbmFseXNpcywgc2VlIHRoZSByZWZlcnJlZCBwYXBlciBhYm92ZS4m
cXVvdDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlF1eW5o
LjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48L2Rpdj4NCjxkaXY+SSBsaWtlIHRoZSBzdWdn
ZXN0aW9uLCBidXQgSeKAmW0gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmcgcHJldHR5PC9kaXY+
DQo8ZGl2PmJhc2ljIGFib3V0IGl0LjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+Ml4yNC41IGZ1
bGwtc2l6ZSByZWNvcmRzIGlzIDJeMjQuNSByZWNvcmRzIG9mIDJeMTQgYnl0ZXMgZWFjaCwgb3I8
L2Rpdj4NCjxkaXY+KHNpbmNlIGFuIEFFUyBibG9jayBpcyAxNiBieXRlcyBvciAyXjQgYnl0ZXMp
IDJeMjQuNSByZWNvcmRzIG9mIDJeMTA8L2Rpdj4NCjxkaXY+YmxvY2tzLjwvZGl2Pg0KPGRpdj48
L2Rpdj4NCjxkaXY+V2h5IGlzIHRoYXQgMl40OCBpbnB1dCBibG9ja3MgcmF0aGVyIHRoYW4gMl4z
NC41IGlucHV0IGJsb2Nrcz88L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlRoYW5rczwvZGl2Pg0K
PGRpdj48L2Rpdj4NCjxkaXY+WW9hdjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj5MaW5rczo8L2Rpdj4NCjxkaXY+LS0tLS0tPC9kaXY+DQo8ZGl2Plsx
XSA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJy
ZW50L21zZzIyMzgxLmh0bWwiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl
Yi90bHMvY3VycmVudC9tc2cyMjM4MS5odG1sPC9hPjwvZGl2Pg0KPGRpdj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj5UTFMgbWFpbGlu
ZyBsaXN0PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRm
Lm9yZzwvYT48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz
PC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+VExTIG1haWxpbmcgbGlzdDwv
c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5v
cmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3RsczwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_--


From nobody Wed Feb 15 09:05: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 A430E12955D for ; Wed, 15 Feb 2017 09:05:17 -0800 (PST)
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=unavailable 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 VWRcLywQnpp9 for ; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
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 9B971129683 for ; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id p22so65752663qka.0 for ; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
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=rPQLotHZVefq48IRqlZOrechzCecrcx+PJ+tH863kbE=; b=oLnwMPD6nMW1EX1vJ19xhi+46DT2g6dYbtn7Psc/wBfeha/b7UV7OkT38b0CXdnj7k OIGW5sFJRFucBPGrBXVOH+bCUK0iCyfWK60PlevhjbeQ8n2uZZp1QEX9F2tkgfbFln6m 6VVSOExDqRbaEEo9EkLDKhTscDmlvQ2CuAGT9e85A5BmY/+9cCLdcV3b3rVpvtMTfTx+ CPzRzncQmsrWd4itMs4RNxIUETIesbPVZU1wE6ZuuPsfbySyCWtuohYFhKtUShQ7Gwax 7/MnxQj4Gr17pJg86CS1HhsP4BDZOoio8V5d8r0OAsWYbmjC6DkS5HOTfJPR+eujDVD5 hIiQ==
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=rPQLotHZVefq48IRqlZOrechzCecrcx+PJ+tH863kbE=; b=LJMROvKBasZlAh04EuQbigviRPAvk1Z+AWteQ0dg1LzGCrv+iLanzN+0aK4FGO7yr5 7AAli99ma66TFigmCeDS2gO8RzWMVPtWqvklNWgFFl0RGQP91YVBmXz34G1R8RaXG1LG o3Byu+49LjcdYBrQr53aKDKZPNggLnaXesTd55Zp1NxcQ0b+VMgjs0Ch/cSB+J4IxCt+ GnfeYdjvAUMPY+k3mjZ3lJOy8ARCO0ELRURPyVqk9HBxkGPK+O/OXi5hLr9q82MlhUCB mVaNa2eAX/rolXBPEUaTWMV2+DnneKt/wTZ7KSLoXZsBvgzHWm3EsdgKIgr8mIQGpt9I EL0Q==
X-Gm-Message-State: AMke39lQMgd/coA0nn1jmGGho8IPF1Hw1dezz/E5hDnnD8wCeVr+xKUgc+P82reFlUrNmjTuwnNY8IL6Ik+lJg==
X-Received: by 10.233.235.66 with SMTP id b63mr36433927qkg.144.1487178314706;  Wed, 15 Feb 2017 09:05:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:05:14 -0800 (PST)
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>            
From: Martin Thomson 
Date: Thu, 16 Feb 2017 04:05:14 +1100
Message-ID: 
To: "Paterson, Kenny" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:05:17 -0000

Kenny's response here is quite informative and clarifies this somewhat.

2^24.5 (the current text) is still a big number.  Though it might seem
a little small, I see no practical reason to change it.  In the most
perverse case, that means 520MB of one octet records (23MB of actual
data) before an update is forced.  It's hard to get excited about that
as a practical limitation.

Frankly, I'm more concerned that this isn't small enough and that it
could it be practical to deploy an implementation that don't support
KeyUpdate.  That would cause a real interop problem.

On 16 February 2017 at 00:46, Paterson, Kenny  w=
rote:
> Hi Quynh,
>
> I'm meant to be on vacation, but I'm finding this on-going discussion
> fascinating, so I'm chipping in again.
>
> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)  wrote:
>
> Hi Atul,
>
> I hope you had a happy Valentine!
>
> From: Atul Luykx 
> Date: Tuesday, February 14, 2017 at 4:52 PM
> To: Yoav Nir 
> Cc: 'Quynh' , IRTF CFRG , "tls@ietf.o=
rg"
> 
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769)
>
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
>
> Because he wants to lower the security level.
>
>
> I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practical=
ly
> the same: they are practically zero.
>
>
> I'm not clear what you mean by "practically" here. They're clearly not th=
e
> same as real numbers. And if we are being conservative about security, th=
en
> the extremes in your list are a long way apart.
>
> And, 2^-32 is an absolute chance in this case meaning that all attackers
> can=E2=80=99t improve their chance: no matter how much computational powe=
r the
> attacker has.
>
>
> A sufficiently powerful adversary could carry out an exhaustive key searc=
h
> for GCM's underlying AES key. So I'm not sure what you're claiming here w=
hen
> you speak of "absolute chance".
>
>
> I don=E2=80=99t understand why the number 2^-60 is your special chosen nu=
mber for
> this ?
>
>
> This is a bit subtle, but I'll try to explain in simple terms.
>
> We can conveniently prove a bound of about this size (actually 2^-57) for
> INT-CTXT for a wide range of parameters covering both TLS and DTLS (where
> many verification failures may be permitted). Then, since we're ultimatel=
y
> interested in AE security, we would like to (roughly) match this for IND-=
CPA
> security, to get as good a bound as we can for AE security (the security
> bounds for the two notions sum to give an AE security bound - see page 2 =
of
> the "AE bounds" note).
>
> In view of the INT-CTXT bound there's no point pushing the IND-CPA bound
> much lower than 2^-60 if the ultimate target is AE security. It just hurt=
s
> the data limits more without significantly improving AE security.
>
> Finally, 2^-60 is not *our* special chosen number. We wrote a note that
> contained a table of values, and it's worth noting that we did not make a
> specific recommendation in our note for which row of the table to select.
>
> (Naturally, though, we'd like security to be as high as possible without
> making rekeying a frequent event. It's a continuing surprise to me that y=
ou
> are pushing for an option that actually reduces security when achieving
> higher security does not seem to cause any problems for implementors.)
>
> In your =E2=80=9Ctheory=E2=80=9D, 2^-112 would be in =E2=80=9Chigher=E2=
=80=9D security than 2^-60.
>
>
> It certainly would, if it were achievable (which it is not for GCM withou=
t
> putting some quite extreme limits on data per key).
>
> Cheers,
>
> Kenny
>
> Quynh.
>
>
> The original text
> recommends switching at 2^{34.5} input blocks, corresponding to a
> success probability of 2^{-60}, whereas his text recommends switching at
> 2^{48} blocks, corresponding to a success probability of 2^{-32}.
>
> Atul
>
> On 2017-02-14 11:45, Yoav Nir wrote:
>
> Hi, Quynh
>
> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
> wrote:
> Hi Sean and all,
> Beside my suggestion at
> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
> I have a second suggestion below.
> Just replacing this sentence: "
> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
> be
> encrypted on a given connection while keeping a safety margin of
> approximately 2^-57 for Authenticated Encryption (AE) security.
> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
> (partial or full) input blocks may be encrypted with one key. For
> other suggestions and analysis, see the referred paper above."
> Regards,
> Quynh.
>
> I like the suggestion, but I=E2=80=99m probably missing something pretty
> basic about it.
> 2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
> (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
> blocks.
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> Thanks
> Yoav
> Links:
> ------
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
> _______________________________________________
> 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
>


From nobody Wed Feb 15 09:20: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 F319D129572 for ; Wed, 15 Feb 2017 09:20:46 -0800 (PST)
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, 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=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 uj2ZnE8YtygZ for ; Wed, 15 Feb 2017 09:20:45 -0800 (PST)
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 C34001295F0 for ; Wed, 15 Feb 2017 09:20:44 -0800 (PST)
Received: by mail-wr0-x241.google.com with SMTP id i10so32077388wrb.0 for ; Wed, 15 Feb 2017 09:20:44 -0800 (PST)
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=ypd6iXJmbyw8ITdPYpT0JWT9mqayqe0kORvWYMLP3ms=; b=pasFOIXVkGX9epodVrdYvEMvw/cGAS5+znIaSzon8ktL033nQNkpHyrjjfDjszc21M WSroOU2Nxbiin91jL8MiXC8CXfYKUHGC9lAMTj3VqIlBGBkE33IQEaRzEOSt1gVus9FB 5sHwYbX3HB0zSCzZ8HMTMNJKzhsx1Iz6LKNdbiXyOfKH5JqRKDzmDNtS0WG5Baillc3C QoyI30tnPNeizAFk57ctAd7DQxmys/wrI5kNYmAABcBvpYUFCf0X5UOOwj4+2jqcn/OM LlysuABeJujgnCP2kJO1k8RM81WLTTss4cTry/5BvLuAmQzHKgepFkMLA9QNydoLgspM ++0g==
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=ypd6iXJmbyw8ITdPYpT0JWT9mqayqe0kORvWYMLP3ms=; b=KCVZS5d64hhyquatm58vtGX2syIL8JYG/qG64N9UGGk98cVgg5HbAotugfM4NvPDk6 rQ4y9UgM8jrGa3aLpDFXKBaFx9ycaiiq9ORpAAZNbUgqKjQC3BNxYpbvqWuaSgIlodA7 D1xgLDkoccMcxRCT+qsCLiAUYVFhKbIBqqyzBnkTk5rYiUT9kIdibrB6QrS8C67OZ9GU ZTWsnlYuXDf7Ed8LU7XSSHEjxxRfV7LUOKSdIbwgF1h5gQ+nKmC3ZF9sIa7xvsW3/gEO ST1uYTBwGkofT/iQL4377CjPuXAiI21HQ2/i5c+JpWLRRlhxd/lcc+sAvVu520Eqr5go qRvw==
X-Gm-Message-State: AMke39mu3oGAKY89KlW9WFyvLT+gzne8G6RHgZnR/6MRUBF9i1dL8Wbm787jt6zt4f9ivg==
X-Received: by 10.223.152.2 with SMTP id v2mr30972319wrb.109.1487179243317; Wed, 15 Feb 2017 09:20:43 -0800 (PST)
Received: from [192.168.137.219] ([176.13.243.119]) by smtp.gmail.com with ESMTPSA id s18sm171632wmb.18.2017.02.15.09.20.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:20:42 -0800 (PST)
From: Yoav Nir 
Message-Id: <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 15 Feb 2017 19:20:39 +0200
In-Reply-To: 
To: Martin Thomson 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>             
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:20:47 -0000

--Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748"


--Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 15 Feb 2017, at 19:05, Martin Thomson  =
wrote:
>=20
> Frankly, I'm more concerned that this isn't small enough and that it
> could it be practical to deploy an implementation that don't support
> KeyUpdate.  That would cause a real interop problem.

Maybe we should resurrect [1] and add 3DES support so as to grease =
KeyUpdate.

No, not really, but TLS is not just the web, and there are connections =
that last for a long time and transfer large amounts of data. Think =
datacenter synchronization. At packet-sized records 24 million records =
amounts to 36 GB. That is considerably larger than a 4 GB software =
update I downloaded over HTTPS a few years ago, but not out of the =
ballpark.

Yoav

[1] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 =



--Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 15 Feb 2017, at 19:05, =
Martin Thomson <martin.thomson@gmail.com> wrote:

Frankly, I'm more concerned that this isn't small enough and =
that it
could it be practical to deploy an implementation =
that don't support
KeyUpdate.  That would cause a =
real interop problem.

Maybe we should resurrect [1] and add 3DES =
support so as to grease KeyUpdate.

No, not really, but TLS is not just the =
web, and there are connections that last for a long time and transfer =
large amounts of data. Think datacenter synchronization. At packet-sized =
records 24 million records amounts to 36 GB. That is considerably larger =
than a 4 GB software update I downloaded over HTTPS a few years ago, but =
not out of the ballpark.

Yoav

[1] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2=
-05

=

--Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748--

--Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6
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-----

iQEcBAEBCgAGBQJYpI3oAAoJELhJCxUKWMyZxCoH/i78Njd11PRpuJ7mYbuDY1TH
mnRUTGoxtXDl6WpZNIxBhXyTewrH6HMEUlc7E6EESLwF2YN0uAPAnZZRlEqgjA8V
rI1sZ8R6zJhIIg2Zhp1gmEbQTH6DhVsA+FLkEddKtqVK9k1Htac72saurbK1kqzo
fg529uv2+/WxxENbnqzDFi6KSOjVxaFERjuR8pNWBMbkuFVWJcdeRQIo6+hH7xqn
GoqEV8hGeBLwlWMq0epSrr/QxZzDGIkj6lxbjMeugYb2dQ7fl0YaRWAc85HVf+DL
JvEHwCR6VfRbK0V2ApSREJMuC/qDQW1ZWGxkZjDWljQ1zp/0/rIZqnkXVhCQ+RY=
=Eibu
-----END PGP SIGNATURE-----

--Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6--


From nobody Wed Feb 15 09:25: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 546DF12964C for ; Wed, 15 Feb 2017 09:25:38 -0800 (PST)
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=unavailable 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 NCCUqu34d4xE for ; Wed, 15 Feb 2017 09:25:37 -0800 (PST)
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 27E8E129636 for ; Wed, 15 Feb 2017 09:25:37 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id w20so142457587qtb.1 for ; Wed, 15 Feb 2017 09:25:37 -0800 (PST)
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=AK113fekdUpSZpTf7ils2iO0GpV9Ztdr0+lCD+1QXq0=; b=DTtlvJwRiIvFFuSpI2eLMzO8SWX1LDecUp09RNz+QzcQcZnWWTXLEEIyhYCS4sDAZ/ EJvbtrU+4ugn38BeDbpCKNosI5pv+6h+MI9go5gFi3gkAjdLQZDTjf3voy4cSp1wlqtE Lt3S1GH/7pUpLU8Y7tP+eDODvG+dZB86NIQgMTtMAJvXJBzHZ8h5HA/P42CM6vYW80vv 3TVY+l9NMmIUFHI74JXJq5Gh+35e/8ifEN+Go46PXPCEQJqJbHiXXdrxtSjyyeLYk0f9 a/6umb6p6fTksybphjV6jpT9NWfULcoAIfLS89Dy6rkvL3zJTPiksngcn43ek5fQeRtz cQrg==
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=AK113fekdUpSZpTf7ils2iO0GpV9Ztdr0+lCD+1QXq0=; b=mdN7Qt6wUUP7tWzxf4dXCWMplqPmqHTSfp+Yj3BVu4eVcI1msCHLLtYDtUmZiHgCi8 PPku/gZ4Pa0s+BVwace4f2jTc2S7Q8NSAHp2clELfc1usKvjRQVfDIT7tnyP/HxFqFil i062+8mApuUZTNl0izASL7nlxGIM5CHlVkpknQXcnV5DPY4pMFBbexxZb4C+I/Iq+8Aq da4buikYX8q5ftq4XAQWZkQ5jIzw95nu25Oj05FLrMjqVKRxk+bV7tfi7OfD0ckgoZ/Z 0aMktuRGVZrugO2le07yr02sbaeeH8uS6Ybsyvq7ty6wJn253sG8830/0hCtAtzV1/d3 4gcg==
X-Gm-Message-State: AMke39minSvIBN8KJ4kynLsRqnEtXfyz68tFmesqqd7POY5RetphCnnkV2O+QMkmu1BplNT9gF0GaFFvF50D9A==
X-Received: by 10.200.55.112 with SMTP id p45mr36746074qtb.278.1487179536228;  Wed, 15 Feb 2017 09:25:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:25:35 -0800 (PST)
In-Reply-To: <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>
From: Martin Thomson 
Date: Thu, 16 Feb 2017 04:25:35 +1100
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:25:38 -0000

On 16 February 2017 at 04:20, Yoav Nir  wrote:
> No, not really, but TLS is not just the web, and there are connections that
> last for a long time and transfer large amounts of data. Think datacenter
> synchronization. At packet-sized records 24 million records amounts to 36
> GB. That is considerably larger than a 4 GB software update I downloaded
> over HTTPS a few years ago, but not out of the ballpark.

I realize that's going to require updates pretty often (once you open
up the CWND), but I don't think that it is frequent enough to be a
concern.

I well know that HTTP gets used at these volumes more often than
people realize.  I'd rather recommend ChaCha for those niche uses
though if the rate was sufficiently high.


From nobody Wed Feb 15 09:30: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 7069B129614 for ; Wed, 15 Feb 2017 09:30:10 -0800 (PST)
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, 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 9VcxJTMoKKTL for ; Wed, 15 Feb 2017 09:30:09 -0800 (PST)
Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::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 35278129572 for ; Wed, 15 Feb 2017 09:30:09 -0800 (PST)
Received: by mail-wr0-x243.google.com with SMTP id k90so31931520wrc.3 for ; Wed, 15 Feb 2017 09:30:09 -0800 (PST)
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=+P9AJ22m0W1uR0IeGX8lhwirkFyNvSm4ddY0ivyy1EE=; b=l2G2/eWiTmKtTmyxMJSTgK9UaOIK9so4V60VJ3ZOpTEc3AcnpdRXaS50KcxbDxYcGC qv7br8TfEkdxbnIeyI2kLOclKMQSn24igR3IZGxSDiumkoFdyUwpRV4vO+na7+81lZX3 hD4dW5iVqSvoMHchS9QAgoce5GQ2Ds5EK+N80A+Q72tH5xaC7kuPTyPJvVAoV5G8WRzA vVqLw9DQsV63yRrscmU6+gG1eTh1sXdLrEQ7oBgPWMl9EuVPj5KaAsPki+SxrkztY4/U JKzftGXBCVfFNBDGhOs9Q7G/pTDzwOFpwXz88chAj6uVkmBlVrkiVQLtwOatYJLrE7pm 8//w==
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=+P9AJ22m0W1uR0IeGX8lhwirkFyNvSm4ddY0ivyy1EE=; b=SY48zTCMPCRNCuXwtkVS5UVHnAJbFliqWNjpDlvd57rUVsZHAgKbESB0ylN5nKQZlD IjUQWzbDsmM17ka+HILoTN4NDMV+lZuWpL/Dm0BzWOELxeb7X13O93CYgQhflWmY3DRx GVQNikqoVKq896ls+B7P3U5m4BjMpkhSGrK//L6yy2vZfPVGaTsqtc5Z8zPCDlO+6yWl Do4HHNS7TXUN/dkpRnEdNezRj5VCRpBShgszbt4enLoWn99dLGRYhySBfOXGUZ7QLCkl pMYp9ij4JLJsqrAc+PzI7YithUjhqzbBCuLAppSNlc7NWLSKYdPzla2L+qwznNeMS3hE YwRA==
X-Gm-Message-State: AMke39mLWnnr/OPzc77/wBxYxjUiUqxDc7QC3xFk0cLaRVgntwzWQ7wHUFBuE32d473QUA==
X-Received: by 10.223.161.130 with SMTP id u2mr35286995wru.127.1487179807685;  Wed, 15 Feb 2017 09:30:07 -0800 (PST)
Received: from [192.168.137.219] ([176.13.243.119]) by smtp.gmail.com with ESMTPSA id i73sm212628wmd.11.2017.02.15.09.30.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:30:06 -0800 (PST)
From: Yoav Nir 
Message-Id: <4639F8A9-1DD7-48E5-ABE4-2658311E0C33@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 15 Feb 2017 19:30:04 +0200
In-Reply-To: 
To: Martin Thomson 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com> 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:30:10 -0000

--Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 15 Feb 2017, at 19:25, Martin Thomson  =
wrote:
>=20
> On 16 February 2017 at 04:20, Yoav Nir  wrote:
>> No, not really, but TLS is not just the web, and there are =
connections that
>> last for a long time and transfer large amounts of data. Think =
datacenter
>> synchronization. At packet-sized records 24 million records amounts =
to 36
>> GB. That is considerably larger than a 4 GB software update I =
downloaded
>> over HTTPS a few years ago, but not out of the ballpark.
>=20
> I realize that's going to require updates pretty often (once you open
> up the CWND), but I don't think that it is frequent enough to be a
> concern.
>=20
> I well know that HTTP gets used at these volumes more often than
> people realize.  I'd rather recommend ChaCha for those niche uses
> though if the rate was sufficiently high.

And now I=E2=80=99ve lost you. A moment ago I thought you were concerned =
that people would fail to implement KeyUpdate. Are you now suggesting =
that it be removed entirely from TLS 1.3?

There=E2=80=99s no getting around the fact that AES-GCM is faster on =
certain processors than ChaCha, and speed is likely to be a major =
concern for exactly the same systems that use the high data volumes.

Yoav



--Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04
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-----

iQEcBAEBCgAGBQJYpJAcAAoJELhJCxUKWMyZFHMH/jaqnZ0ip7jimuowadDp4sEU
STdxpj3GcmISV/+f+J1Aeod/ZSa4WniM+R+liPsONEVQOOkbBI/aCqb5HnuyDskn
R3old6vEGfbzk5JWAEB9WtCQWVpOeuruJgAMpvI+32HyX6j7nDxzpEqtvKMWff+V
d97+o0hvW3jI+9dPmOkVN/FXfw2Eh/2qx4aqyotbw11iZxTaFvSAIgOGiI3DsF8Z
ULq5B4laFejs454CukmctJ/TShWqHUSDJTnft5l8AcdDSskwqIkxzy3o5k8sytzx
q4I/CXHkeVgG+M4otbM+uBnps4fvhAyqRrXS5HtBAfyLPQXpQIjG+vOvNCmZIGs=
=amz4
-----END PGP SIGNATURE-----

--Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04--


From nobody Wed Feb 15 09:33: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 269401296A9 for ; Wed, 15 Feb 2017 09:33:36 -0800 (PST)
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=unavailable 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 UmvB6IxQMSt9 for ; Wed, 15 Feb 2017 09:33:22 -0800 (PST)
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 8DAA51296AD for ; Wed, 15 Feb 2017 09:33:22 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id u25so158306240qki.2 for ; Wed, 15 Feb 2017 09:33:22 -0800 (PST)
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=zJYzbrH0hTyIR14j/7bll3X852dqxW5Den39cRhYLCo=; b=svnN8FTt0+W3K2etYF3e1STN5Ceh2NBGhu32C2nJvG3K0LFdaQFp/2Hfe2ZuOfvPjP lHuzgcTciQADC4xbCk26BAq6ye7pFoEaNDPIcHxUDGVPMmGi60jW9mcO1HNCJotCQf6h 0AoFW/awysYdlubSC2mLDJNaTwL+/zFjJy6QiMjxscchziokl9CQR6eQwLI6xABRklpj sQ69qfB2YpA9pSsf2hWptfACIuhgGlysO6Vp36ymg5NlPbQPVS6SQ981o6j51fs9CD7W FDo/U16Y3Y1LeScgOHZDgh9f6QlKK26Jn+WaQL6RfF6GO1SzotEUR4sERjc9aIcpc+7o hg2w==
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=zJYzbrH0hTyIR14j/7bll3X852dqxW5Den39cRhYLCo=; b=AKJipKsSKhB8l/jcOgtANib/i87DSTwKKpipLOwzajZnOp+id8c8+el0l47z4DMtjq 0Rf+eK2C8n7MU1xGiR7B0BO6cRnjc+91gcg/g6lRMYxgD3/zl5ppZx8puUAXznTxeBH+ krQRU0E0gqwnyv2khNrvNyiFTxavPITBDiOy+0FSNba2IurSyNz6cgjnsURopo6+bmyO Y9Y+y5UHPcEUXBvY2XnkIhmDP4ifxAaKwwbr8FAf9qTi7mGjrnfxwwsoka7/pAR4UfvB GkAIzuKMxAutY3JVfSr0wtUTyseFUPmrRqXaaPFO8bolrn32qIBrAet2iEQWgllqAeVK ogRQ==
X-Gm-Message-State: AMke39mDArNwJtMzVvSZV/eTZOoUcKdcbaNLN0T/v0Wqx1PxQvx5cGHvnf1loM9qPyMmAoUjNo0wpspEwRhAKA==
X-Received: by 10.233.235.66 with SMTP id b63mr36582482qkg.144.1487180001787;  Wed, 15 Feb 2017 09:33:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:33:21 -0800 (PST)
In-Reply-To: <4639F8A9-1DD7-48E5-ABE4-2658311E0C33@gmail.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>  <4639F8A9-1DD7-48E5-ABE4-2658311E0C33@gmail.com>
From: Martin Thomson 
Date: Thu, 16 Feb 2017 04:33:21 +1100
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:33:36 -0000

On 16 February 2017 at 04:30, Yoav Nir  wrote:
> And now I=E2=80=99ve lost you. A moment ago I thought you were concerned =
that people would fail to implement KeyUpdate. Are you now suggesting that =
it be removed entirely from TLS 1.3?


No.  My point was that if GCM requires more updates than you can
handle (because you are running well in excess of 1Tbps perhaps, I
don't know, my crystal ball isn't that good), then use ChaCha where
you don't need to update so often.  Obviously there is a tradeoff
there given the relative availability of hardware support, which you
likely need at those rates, but again the crystal ball is imperfect in
telling us how that story plays out.


From nobody Wed Feb 15 10:27: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 542141296D3 for ; Wed, 15 Feb 2017 10:27:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=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 bTZv6XbUKD21 for ; Wed, 15 Feb 2017 10:27:18 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.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 80075129B1B for ; Wed, 15 Feb 2017 10:27:18 -0800 (PST)
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=mBKY4wE0/UFOJvLOVVbqsdVukg20lInp1baraZd+cpU=; b=aWccwZGsTDiIkfCA6M/xl2NFEvpVBwn3FYySvhnuKAoBYI7b1tbF3AEfPXYEem4r0bOB9UDQVIFZqUmTnfs7BI1fdS8zIZWGP2KENts9hNAcxn0zBoSrWLHUs+YJx/SMGNy1Z6JPm4ZTWAAFyecpDJFvQHZnYHfFPor/26PS1Wg=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 18:27:14 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 18:27:14 +0000
From: Andrei Popov 
To: David Wong 
Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
Thread-Index: AQHShfVLh43MYmEytkO14a3ComoThqFooDUAgAAGc4CAAAlfgIAAHR8AgAENgQCAAItuMA==
Date: Wed, 15 Feb 2017 18:27:14 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: 1e9218db-4825-4d9f-91df-08d455d043c6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; 
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:WsdfNs+nQslHfrOVqBGA7cx5wfdCgi5EEtWTlYwOcP9gRilBfbN0kTiJzevKs1QhK3V8nzaciHSjuuozmdU3GaVq1pYzX7h1m3Xc8q1KZiBX6ZNFSHIT0YoD4kXgpBqdBIifAHbv0q32/p2M4EWMUNMjag7e3bvIvydWnjEL1pOaCLQ1XSRlTR0dR5OAfLZfDE4CXeNjtnnvEpd6Jz6i/GF426lqoWqT0QadkIAQKjhMiqNXC/iPKqlqLkY27dEnSEGiDN55B7dxGmkZNlVpD1fIrK67VLQvd26kQWCFn4vUWKDLAdTDhQIRuC2KU1cHihyw7oih5DOuT65MxTeq++XGiV0WfLh1WbCJnFu24Nx+M+rhivQnRd3UybqewZCmCvBNLvyx3vFizTL9X4BjaTtmR5dlki4qvg/tZDqy2j2t6nlGA8JQIZ3bESKMDn+JIqMr4hTKStO1HmOOZEig2QpLfYexInf1/Pe/bEOWX9Or1p/mjFXCZX3dQ/8yYL4/fIeaCMDPD1WtkREgCNVISwjBHJnHW9+YxE4yZuFKaKw=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(6072148)(6042181); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; 
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(106356001)(3280700002)(790700001)(229853002)(189998001)(38730400002)(93886004)(86362001)(105586002)(86612001)(2906002)(25786008)(6116002)(389900002)(102836003)(122556002)(7696004)(99286003)(55016002)(7736002)(33656002)(5660300001)(6436002)(4326007)(6506006)(106116001)(10090500001)(6916009)(54896002)(8676002)(77096006)(3660700001)(6306002)(9686003)(97736004)(2950100002)(74316002)(54906002)(81166006)(101416001)(76176999)(8936002)(10290500002)(92566002)(2900100001)(68736007)(6246003)(5005710100001)(54356999)(39060400002)(50986999)(53936002)(8990500004)(81156014)(110136004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 18:27:14.1335 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843
Archived-At: 
Cc: Cas Cremers , "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 18:27:20 -0000

--_000_CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0CY1PR0301MB0842_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, I agree that it is useful to mention this in the spec.

From: David Wong [mailto:davidwong.crypto@gmail.com]
Sent: Wednesday, February 15, 2017 2:07 AM
To: Andrei Popov 
Cc: David Benjamin ; Cas Cremers ; tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server vi=
ew on client authentication in post-handshake mode in Revision 18

I think I can agree that this is an application problem, not a TLS problem.=
 But this should be mentioned in the spec nonetheless as Cas pointed.

--_000_CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0CY1PR0301MB0842_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Yes, I agree that it is useful to mention this in t=
he spec.


 


From: David Wong [mailto:davidwong.c=
rypto@gmail.com]


Sent: Wednesday, February 15, 2017 2:07 AM

To: Andrei Popov <Andrei.Popov@microsoft.com>

Cc: David Benjamin <davidben@chromium.org>; Cas Cremers <ca=
s.cremers@cs.ox.ac.uk>; tls@ietf.org

Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/se=
rver view on client authentication in post-handshake mode in Revision 18


 








I think I can agree that this is an application prob=
lem, not a TLS problem. But this should be mentioned in the spec nonet=
heless as Cas pointed.












--_000_CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0CY1PR0301MB0842_--


From nobody Wed Feb 15 11: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 609AC129A7E for ; Wed, 15 Feb 2017 11:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level: 
X-Spam-Status: No, score=-1.598 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, 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 E3_ErlDH09ja for ; Wed, 15 Feb 2017 11:49:02 -0800 (PST)
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 2CAE5129A7D for ; Wed, 15 Feb 2017 11:49:02 -0800 (PST)
Received: by mail-wm0-x244.google.com with SMTP id r18so9852797wmd.3 for ; Wed, 15 Feb 2017 11:49:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:from:to:cc:in-reply-to:references:subject:message-id :date:content-transfer-encoding:mime-version; bh=o3pQrmKdFk4hTLtIg/IpxQe+vUkM516qE0afGaDzUhg=; b=txNVY3co9dnBuAJ8lE4fFbZ3JsMu+c9duDRf9HSiuUFtSvSMMjr6Lfv/qWJRsr3CiE 4H5asTdqcVtJp0Rd2M3GcDT39eUG7tL98c2j46fsfe3hjRoK1siG7g5o/mbAZSyFSDjU q6pXkgtI1JQcjGELyV4cufgqjyT+fl234RpTlU4VIX4Ti+T579X/XKsy44zKa3iVQXyp hXjE7w+AqAk6WWxyPD8cdHZe7pWD6dh5g7IgfgWRHQsDlPJENkOibWChg7HyiOVABmrT D7Nf76xY2ZVJH9ejDpIdeKmF9RkGGqXn15oVCfxow+R8w2Grn4osNbxZUtbB9kYCl4vf 9D9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:cc:in-reply-to:references :subject:message-id:date:content-transfer-encoding:mime-version; bh=o3pQrmKdFk4hTLtIg/IpxQe+vUkM516qE0afGaDzUhg=; b=tRh1EO8bUOY5vtx44k/geIjtnTfZaBAImjgkbMd4zFOu1CpZmwZdrWIt69ySGtQG26 KrVu7cCahaNYF82ES4MuqxtIBbbcQ8PsRN5CKtdiTRIsZC913cIdoIyC1AiGaMIDV3ue +l2ZUNpoWdUYc4wugcw1P84jJmKKNP9gaTISp8jCS4u/IGUIFy0+B/7I8Nk1pL2trQ+3 tlF0cmGPHtAqX6la6fYMUEXVl92MQmc2NLxTQfYQUP+RfsoKSHowuScxck46ci/9W2E6 4TC9uihrQBMD/Y8zuuw8xrB5EP4e9oZeABHu6KDPXoKtG/7pociTIcZwHziyQVulalaX nTDQ==
X-Gm-Message-State: AMke39lJtyCJgvbHOnsIOg024g6jRbN6Tc1BEVoRsOk+elpV4mGrYebfTqhlSgePTzG/DA==
X-Received: by 10.28.188.213 with SMTP id m204mr9288437wmf.0.1487188140608; Wed, 15 Feb 2017 11:49:00 -0800 (PST)
Received: from little-david.home (LFbn-1-9943-152.w86-202.abo.wanadoo.fr. [86.202.61.152]) by smtp.gmail.com with ESMTPSA id p7sm6050283wrc.34.2017.02.15.11.48.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 11:49:00 -0800 (PST)
Content-Type: text/html
User-Agent: NylasMailer-K2
From: David Wong 
To: Andrei Popov 
In-Reply-To: 
References:       
Message-ID: 
Date: Wed, 15 Feb 2017 19:48:59 +0000
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Cas Cremers , tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 19:49:03 -0000


On Feb 15 2017, at 7:27 pm, Andrei Popov <Andrei.Popov@microsoft.=
com> wrote: 

            

             =20









Yes, I agree that it is =
useful to mention this in the spec.


 



It would be nice is to have two different PRs =
solving this issue. One mentioning this as a potential issue that the =
application must be aware of. I've seen things like that for example =
in rfc 5746: https://tools.ietf.org/html/rfc5746#section-5
>    While this extension mitigates the =
man-in-the-middle attack described
   in the overview, it does not resolve =
all possible problems an
   application may face if it is unaware of =
renegotiation.  For example,
   during renegotiation, either the client or =
the server can present a
   different certificate than was used earlier.  =
This may come as a
   surprise to application developers (who might have =
expected, for
   example, that a "getPeerCertificates()" API call returns =
the same
   value if called twice), and might be handled in an insecure way=
.

A second PR could try to tackle this by adding a=
 new message, for example an "AcknowledgeClientAuthentication" message that=
 the server would send to confirm (or not) the validation of the client =
certificate. I think this would add a bit of complexity for less "surprise"=
. I'm not too keen on this, and I think this could be added as an extension=
 instead, but I think it would be nice to have to see if it integrates =
nicely in the current draft.

David












           =20
          



From nobody Wed Feb 15 11:52: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 E005D1297AA for ; Wed, 15 Feb 2017 11:52:39 -0800 (PST)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 q4YoXq7fURok for ; Wed, 15 Feb 2017 11:52:38 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 1148412978B for ; Wed, 15 Feb 2017 11:52:38 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id p22so70475683qka.0 for ; Wed, 15 Feb 2017 11:52:37 -0800 (PST)
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=a3K9rIVaJV5gPMpXNXL7HKFwN4qCwD+4z0c2j55gxhY=; b=ioZIbga+flarvSoL4cYgxg9HT4mHqIFTr7batLNc8VO37ubayJtMZiX54h5IGav4bO NSLCocQahms1r98PLbUrv/52eJA7TgZa4yx19ZYy0VkKBmdNGpqs1/9G2vREr0ix3Kor Ud8/HILYdV61kFb+gYNekxDPCr58SjwdOFAEE=
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=a3K9rIVaJV5gPMpXNXL7HKFwN4qCwD+4z0c2j55gxhY=; b=e6KYm6xy1l6kLZftNp6zA+WK3NWOEgRQpBhdgRGFj5ji8ryg/szx2DGHrXhQoqAC3d 3ndWqIkFpcxw6E8TbNUUxsV4tVqCbSmSGOy+L2XElPl0XxGzZsvkI1E25h0oGZePoLgc 9fM7/GMqI+lSWkSb6/5C9c+K+r8Z9rZz5XaX0KPiTklWR8vH2RI27fHEW5Pv67Bksbu9 DBCNVdweg/QnHJvrJ7WWrqBSOVDb+axteytweA3e1JjaKjo/t+WQ10i2PHlCKHwXlpvt 94N4MY8l7P1R0WrHWO6/KERZMXu318YiO2zWJe57lX8vfYuzh5iYPNsnh6BmppwF1CEq ajjQ==
X-Gm-Message-State: AMke39keEi0CBcJfXw/ESBoBnVkSUgm2SkXzGCShzh6NCH637yBdXuZ07QGqVq8D7tTvfNYqaWEtersZQJvJ01kL
X-Received: by 10.55.22.74 with SMTP id g71mr19078335qkh.40.1487188356970; Wed, 15 Feb 2017 11:52:36 -0800 (PST)
MIME-Version: 1.0
References:        
In-Reply-To: 
From: David Benjamin 
Date: Wed, 15 Feb 2017 19:52:26 +0000
Message-ID: 
To: David Wong , Andrei Popov 
Content-Type: multipart/alternative; boundary=001a11474584bbb0f805489705c2
Archived-At: 
Cc: Cas Cremers , tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 19:52:40 -0000

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

On Wed, Feb 15, 2017 at 2:49 PM David Wong 
wrote:

> On Feb 15 2017, at 7:27 pm, Andrei Popov 
> wrote:
>
> Yes, I agree that it is useful to mention this in the spec.
>
>
>
>
> It would be nice is to have two different PRs solving this issue. One
> mentioning this as a potential issue that the application must be aware of.
> I've seen things like that for example in rfc 5746:
> https://tools.ietf.org/html/rfc5746#section-5
>
> >  While this extension mitigates the man-in-the-middle attack described
> in the overview, it does not resolve all possible problems an application
> may face if it is unaware of renegotiation. For example, during
> renegotiation, either the client or the server can present a different
> certificate than was used earlier. This may come as a surprise to
> application developers (who might have expected, for example, that a
> "getPeerCertificates()" API call returns the same value if called twice),
> and might be handled in an insecure way.
>
> A second PR could try to tackle this by adding a new message, for example
> an "AcknowledgeClientAuthentication" message that the server would send to
> confirm (or not) the validation of the client certificate. I think this
> would add a bit of complexity for less "surprise". I'm not too keen on
> this, and I think this could be added as an extension instead, but I think
> it would be nice to have to see if it integrates nicely in the current
> draft.
>

Post-handshake auth exists basically entirely to service HTTP/1.1 reactive
client certificate which was previously hacked on via renegotiation. I
think we should not make this feature any more complicated than absolutely
necessary to support this mode, and we should not add more bells and
whistles to it to encourage further use.

For the HTTP/1.1 use case, this is not necessary because it's reasonable
for client/server to agree that the server will not send any more data for
that request until it has processed the client's authentication messages.

David

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


On Wed, Feb 15=
, 2017 at 2:49 PM David Wong <davidwong.crypto@gmail.com> wrote:
On Feb 15 2017, at 7:27 pm, Andrei Popo=
v <Andrei.Popov@microsoft.com> wrote:=C2=A0

            

             =20









Yes, I agree that it is useful to mention this in the spec.


=C2=A0



It would be nice is to have two different PRs solving=
 this issue. One mentioning=C2=A0this as a potential issue that the applica=
tion must be aware of. I've seen things like that for example in=C2=A0r=
fc=C2=A05746:=C2=A0https://tools.ietf.org/html/rfc5746=
#section-5

>=C2=A0   While this extension mitigates the man-in-t=
he-middle attack described
   in the overview, it does not resolve all possible problems an
   application may face if it is unaware of renegotiation.  For example,
   during renegotiation, either the client or the server can present a
   different certificate than was used earlier.  This may come as a
   surprise to application developers (who might have expected, for
   example, that a "getPeerCertificates()" API call returns the s=
ame
   value if called twice), and might be handled in an insecure way.

A second PR could try to tackle this by adding a new message, for exampl=
e an "AcknowledgeClientAuthentication" message that the server wo=
uld send to confirm (or not) the validation of the client certificate. I th=
ink this would add a bit of complexity for less "surprise". I'=
;m not too keen on this, and I think this could be added as an extension in=
stead, but I think it would be nice to have to see if it integrates nicely =
in the current draft.

Post-hand=
shake auth exists basically entirely to service HTTP/1.1 reactive client ce=
rtificate which was previously hacked on via renegotiation. I think we shou=
ld not make this feature any more complicated than absolutely necessary to =
support this mode, and we should not add more bells and whistles to it to e=
ncourage further use.

For the HTTP/1.1 use case, t=
his is not necessary because it's reasonable for client/server to agree=
 that the server will not send any more data for that request until it has =
processed the client's authentication messages.

David


--001a11474584bbb0f805489705c2--


From nobody Wed Feb 15 12:01: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 4AFB5129B31 for ; Wed, 15 Feb 2017 12:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.887
X-Spam-Level: 
X-Spam-Status: No, score=-3.887 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_H2=-1.887, SPF_HELO_PASS=-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=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 omKe-7kvPtq6 for ; Wed, 15 Feb 2017 12:01:37 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0128.outbound.protection.outlook.com [104.47.36.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533F3129AA0 for ; Wed, 15 Feb 2017 12:01:19 -0800 (PST)
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=Q4B0jZ80BrBuLGyMqeQYKIe4187ZhPuXZ9ajCevgT4s=; b=T3ePiDjjaz152tr4WNhCdRI2UHYMUArrUdQ9UVilVR8hF3ZkGj+O3bNgQBc56pugddFbiKc9Et7klQJ9IG5XkVFq1xVnex7tSeeQ0y6ce8I4TjV+iI1FPrBL8I0QM5xrmcFlyGKsjpgtLXGETCZiv9QlKNgB0m7MwgfPH9IvuWY=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 20:01:17 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 20:01:18 +0000
From: Andrei Popov 
To: David Benjamin , David Wong 
Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
Thread-Index: AQHShfVLh43MYmEytkO14a3ComoThqFooDUAgAAGc4CAAAlfgIAAHR8AgAENgQCAAItuMIAAFxmAgAAA9wCAAAIHYA==
Date: Wed, 15 Feb 2017 20:01:17 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: da620d03-a5a1-441e-b7c5-08d455dd67a1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844; 
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:moubxxp0vfikNYBtQlgXQYlY4uyA/r4nd/ra5AEcJfbzEfRsx3FcIWnq2R7nLTXf57nIjTFsKhZygbSNzVy6YGm6NwOD6Vze+bbq2kAVakb/Dfnn7nImeREsqkGY6ztz4NNJdgBqZOOn6iE/w4hrfNJtsAP5wrYq98fMOMFsm1r7fU3GP8PJk9tHnvCULCHwv0NMQESUQ6zHQBmeeTZR9lhDdY18ap4d2t3TybbXGeMruPw3okn82xEdY/DQC48yo8RkO5EflJ3juRatxY4spwh/KHvlvAaeY/kUYjcCr5AtKHFFY+8nmvLGr8zb952MRXkbAW06sosNbIHulzWXuNu3US/bCHNpIg5kTjWoufY=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; 
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(189002)(199003)(377454003)(24454002)(101416001)(105586002)(8936002)(106116001)(7736002)(3660700001)(6506006)(81166006)(4326007)(97736004)(790700001)(54356999)(102836003)(81156014)(76176999)(68736007)(2906002)(6116002)(6436002)(106356001)(50986999)(3280700002)(33656002)(8676002)(77096006)(25786008)(606005)(2900100001)(9686003)(55016002)(236005)(54906002)(10090500001)(99286003)(7696004)(6306002)(92566002)(229853002)(189998001)(38730400002)(86612001)(2950100002)(93886004)(53936002)(54896002)(5005710100001)(8990500004)(5660300001)(86362001)(122556002)(74316002)(6246003)(7906003)(19609705001)(389900002)(39060400002)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08424704E884306DA56402268C5B0CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 20:01:17.8695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
Archived-At: 
Cc: Cas Cremers , "tls@ietf.org" 
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 20:01:40 -0000

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

SSBhZ3JlZSB3aXRoIERhdmlkOiBhIGRpZmZlcmVudCBjbGllbnQgYXV0aCBtZWNoYW5pc20gaXMg
aW4gdGhlIHdvcmtzIGZvciBIVFRQLzIuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IERh
dmlkIEJlbmphbWluIFttYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnXQ0KU2VudDogV2VkbmVz
ZGF5LCBGZWJydWFyeSAxNSwgMjAxNyAxMTo1MiBBTQ0KVG86IERhdmlkIFdvbmcgPGRhdmlkd29u
Zy5jcnlwdG9AZ21haWwuY29tPjsgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0
LmNvbT4NCkNjOiBDYXMgQ3JlbWVycyA8Y2FzLmNyZW1lcnNAY3Mub3guYWMudWs+OyB0bHNAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBBd2t3YXJkIEhhbmRzaGFrZTogUG9zc2libGUgbWlz
bWF0Y2ggb2YgY2xpZW50L3NlcnZlciB2aWV3IG9uIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBw
b3N0LWhhbmRzaGFrZSBtb2RlIGluIFJldmlzaW9uIDE4DQoNCk9uIFdlZCwgRmViIDE1LCAyMDE3
IGF0IDI6NDkgUE0gRGF2aWQgV29uZyA8ZGF2aWR3b25nLmNyeXB0b0BnbWFpbC5jb208bWFpbHRv
OmRhdmlkd29uZy5jcnlwdG9AZ21haWwuY29tPj4gd3JvdGU6DQpPbiBGZWIgMTUgMjAxNywgYXQg
NzoyNyBwbSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86
QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KWWVzLCBJIGFncmVlIHRoYXQg
aXQgaXMgdXNlZnVsIHRvIG1lbnRpb24gdGhpcyBpbiB0aGUgc3BlYy4NCg0KDQoNCkl0IHdvdWxk
IGJlIG5pY2UgaXMgdG8gaGF2ZSB0d28gZGlmZmVyZW50IFBScyBzb2x2aW5nIHRoaXMgaXNzdWUu
IE9uZSBtZW50aW9uaW5nIHRoaXMgYXMgYSBwb3RlbnRpYWwgaXNzdWUgdGhhdCB0aGUgYXBwbGlj
YXRpb24gbXVzdCBiZSBhd2FyZSBvZi4gSSd2ZSBzZWVuIHRoaW5ncyBsaWtlIHRoYXQgZm9yIGV4
YW1wbGUgaW4gcmZjIDU3NDY6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzQ2I3Nl
Y3Rpb24tNQ0KDQo+ICBXaGlsZSB0aGlzIGV4dGVuc2lvbiBtaXRpZ2F0ZXMgdGhlIG1hbi1pbi10
aGUtbWlkZGxlIGF0dGFjayBkZXNjcmliZWQgaW4gdGhlIG92ZXJ2aWV3LCBpdCBkb2VzIG5vdCBy
ZXNvbHZlIGFsbCBwb3NzaWJsZSBwcm9ibGVtcyBhbiBhcHBsaWNhdGlvbiBtYXkgZmFjZSBpZiBp
dCBpcyB1bmF3YXJlIG9mIHJlbmVnb3RpYXRpb24uIEZvciBleGFtcGxlLCBkdXJpbmcgcmVuZWdv
dGlhdGlvbiwgZWl0aGVyIHRoZSBjbGllbnQgb3IgdGhlIHNlcnZlciBjYW4gcHJlc2VudCBhIGRp
ZmZlcmVudCBjZXJ0aWZpY2F0ZSB0aGFuIHdhcyB1c2VkIGVhcmxpZXIuIFRoaXMgbWF5IGNvbWUg
YXMgYSBzdXJwcmlzZSB0byBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzICh3aG8gbWlnaHQgaGF2ZSBl
eHBlY3RlZCwgZm9yIGV4YW1wbGUsIHRoYXQgYSAiZ2V0UGVlckNlcnRpZmljYXRlcygpIiBBUEkg
Y2FsbCByZXR1cm5zIHRoZSBzYW1lIHZhbHVlIGlmIGNhbGxlZCB0d2ljZSksIGFuZCBtaWdodCBi
ZSBoYW5kbGVkIGluIGFuIGluc2VjdXJlIHdheS4NCg0KQSBzZWNvbmQgUFIgY291bGQgdHJ5IHRv
IHRhY2tsZSB0aGlzIGJ5IGFkZGluZyBhIG5ldyBtZXNzYWdlLCBmb3IgZXhhbXBsZSBhbiAiQWNr
bm93bGVkZ2VDbGllbnRBdXRoZW50aWNhdGlvbiIgbWVzc2FnZSB0aGF0IHRoZSBzZXJ2ZXIgd291
bGQgc2VuZCB0byBjb25maXJtIChvciBub3QpIHRoZSB2YWxpZGF0aW9uIG9mIHRoZSBjbGllbnQg
Y2VydGlmaWNhdGUuIEkgdGhpbmsgdGhpcyB3b3VsZCBhZGQgYSBiaXQgb2YgY29tcGxleGl0eSBm
b3IgbGVzcyAic3VycHJpc2UiLiBJJ20gbm90IHRvbyBrZWVuIG9uIHRoaXMsIGFuZCBJIHRoaW5r
IHRoaXMgY291bGQgYmUgYWRkZWQgYXMgYW4gZXh0ZW5zaW9uIGluc3RlYWQsIGJ1dCBJIHRoaW5r
IGl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSB0byBzZWUgaWYgaXQgaW50ZWdyYXRlcyBuaWNlbHkg
aW4gdGhlIGN1cnJlbnQgZHJhZnQuDQoNClBvc3QtaGFuZHNoYWtlIGF1dGggZXhpc3RzIGJhc2lj
YWxseSBlbnRpcmVseSB0byBzZXJ2aWNlIEhUVFAvMS4xIHJlYWN0aXZlIGNsaWVudCBjZXJ0aWZp
Y2F0ZSB3aGljaCB3YXMgcHJldmlvdXNseSBoYWNrZWQgb24gdmlhIHJlbmVnb3RpYXRpb24uIEkg
dGhpbmsgd2Ugc2hvdWxkIG5vdCBtYWtlIHRoaXMgZmVhdHVyZSBhbnkgbW9yZSBjb21wbGljYXRl
ZCB0aGFuIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgdGhpcyBtb2RlLCBhbmQgd2Ug
c2hvdWxkIG5vdCBhZGQgbW9yZSBiZWxscyBhbmQgd2hpc3RsZXMgdG8gaXQgdG8gZW5jb3VyYWdl
IGZ1cnRoZXIgdXNlLg0KDQpGb3IgdGhlIEhUVFAvMS4xIHVzZSBjYXNlLCB0aGlzIGlzIG5vdCBu
ZWNlc3NhcnkgYmVjYXVzZSBpdCdzIHJlYXNvbmFibGUgZm9yIGNsaWVudC9zZXJ2ZXIgdG8gYWdy
ZWUgdGhhdCB0aGUgc2VydmVyIHdpbGwgbm90IHNlbmQgYW55IG1vcmUgZGF0YSBmb3IgdGhhdCBy
ZXF1ZXN0IHVudGlsIGl0IGhhcyBwcm9jZXNzZWQgdGhlIGNsaWVudCdzIGF1dGhlbnRpY2F0aW9u
IG1lc3NhZ2VzLg0KDQpEYXZpZA0K

--_000_CY1PR0301MB08424704E884306DA56402268C5B0CY1PR0301MB0842_
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
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWxtc2csIGxpLmdt
YWlsbXNnLCBkaXYuZ21haWxtc2cNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWxfbXNnOw0KCW1zby1t
YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u
dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5nbWFpbG1zZzENCgl7bXNv
LXN0eWxlLW5hbWU6Z21haWxfbXNnMTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5JIGFncmVlIHdpdGggRGF2aWQ6IGEgZGlmZmVyZW50IGNsaWVudCBhdXRoIG1lY2hh
bmlzbSBpcyBpbiB0aGUgd29ya3MgZm9yIEhUVFAvMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+IERhdmlkIEJlbmphbWluIFttYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0u
b3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTUsIDIwMTcgMTE6
NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIFdvbmcgJmx0O2Rhdmlkd29uZy5jcnlwdG9AZ21h
aWwuY29tJmd0OzsgQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZn
dDs8YnI+DQo8Yj5DYzo8L2I+IENhcyBDcmVtZXJzICZsdDtjYXMuY3JlbWVyc0Bjcy5veC5hYy51
ayZndDs7IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gQXdrd2Fy
ZCBIYW5kc2hha2U6IFBvc3NpYmxlIG1pc21hdGNoIG9mIGNsaWVudC9zZXJ2ZXIgdmlldyBvbiBj
bGllbnQgYXV0aGVudGljYXRpb24gaW4gcG9zdC1oYW5kc2hha2UgbW9kZSBpbiBSZXZpc2lvbiAx
ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
V2VkLCBGZWIgMTUsIDIwMTcgYXQgMjo0OSBQTSBEYXZpZCBXb25nICZsdDs8YSBocmVmPSJtYWls
dG86ZGF2aWR3b25nLmNyeXB0b0BnbWFpbC5jb20iPmRhdmlkd29uZy5jcnlwdG9AZ21haWwuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu
IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDE1IDIwMTcsIGF0IDc6MjcgcG0sIEFuZHJl
aSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0
YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTom
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K
PHAgY2xhc3M9ImdtYWlsbXNnIiBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx
cHQiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WWVzLCBJIGFncmVl
IHRoYXQgaXQgaXMgdXNlZnVsIHRvIG1lbnRpb24gdGhpcyBpbiB0aGUgc3BlYy48L3NwYW4+PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsbXNnIiBzdHlsZT0ibWFyZ2luOjBp
bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZzEiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3Vs
ZCBiZSBuaWNlIGlzIHRvIGhhdmUgdHdvIGRpZmZlcmVudCBQUnMgc29sdmluZyB0aGlzIGlzc3Vl
LiBPbmUgbWVudGlvbmluZyZuYnNwO3RoaXMgYXMgYSBwb3RlbnRpYWwgaXNzdWUgdGhhdCB0aGUg
YXBwbGljYXRpb24gbXVzdCBiZSBhd2FyZSBvZi4gSSd2ZSBzZWVuIHRoaW5ncyBsaWtlIHRoYXQg
Zm9yIGV4YW1wbGUgaW4mbmJzcDtyZmMmbmJzcDs1NzQ2OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzQ2I3NlY3Rpb24tNSIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzQ2I3NlY3Rpb24tNTwvYT48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsgV2hpbGUgdGhp
cyBleHRlbnNpb24gbWl0aWdhdGVzIHRoZSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2sgZGVzY3Jp
YmVkIGluIHRoZSBvdmVydmlldywgaXQgZG9lcyBub3QgcmVzb2x2ZSBhbGwgcG9zc2libGUgcHJv
YmxlbXMgYW4gYXBwbGljYXRpb24gbWF5IGZhY2UgaWYgaXQgaXMgdW5hd2FyZSBvZiByZW5lZ290
aWF0aW9uLiBGb3IgZXhhbXBsZSwgZHVyaW5nIHJlbmVnb3RpYXRpb24sIGVpdGhlciB0aGUNCiBj
bGllbnQgb3IgdGhlIHNlcnZlciBjYW4gcHJlc2VudCBhIGRpZmZlcmVudCBjZXJ0aWZpY2F0ZSB0
aGFuIHdhcyB1c2VkIGVhcmxpZXIuIFRoaXMgbWF5IGNvbWUgYXMgYSBzdXJwcmlzZSB0byBhcHBs
aWNhdGlvbiBkZXZlbG9wZXJzICh3aG8gbWlnaHQgaGF2ZSBleHBlY3RlZCwgZm9yIGV4YW1wbGUs
IHRoYXQgYSAmcXVvdDtnZXRQZWVyQ2VydGlmaWNhdGVzKCkmcXVvdDsgQVBJIGNhbGwgcmV0dXJu
cyB0aGUgc2FtZSB2YWx1ZSBpZiBjYWxsZWQgdHdpY2UpLCBhbmQNCiBtaWdodCBiZSBoYW5kbGVk
IGluIGFuIGluc2VjdXJlIHdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QSBzZWNvbmQgUFIgY291bGQgdHJ5IHRvIHRhY2tsZSB0aGlzIGJ5
IGFkZGluZyBhIG5ldyBtZXNzYWdlLCBmb3IgZXhhbXBsZSBhbiAmcXVvdDtBY2tub3dsZWRnZUNs
aWVudEF1dGhlbnRpY2F0aW9uJnF1b3Q7IG1lc3NhZ2UgdGhhdCB0aGUgc2VydmVyIHdvdWxkIHNl
bmQgdG8gY29uZmlybSAob3Igbm90KSB0aGUgdmFsaWRhdGlvbiBvZiB0aGUgY2xpZW50IGNlcnRp
ZmljYXRlLiBJIHRoaW5rIHRoaXMgd291bGQgYWRkIGEgYml0DQogb2YgY29tcGxleGl0eSBmb3Ig
bGVzcyAmcXVvdDtzdXJwcmlzZSZxdW90Oy4gSSdtIG5vdCB0b28ga2VlbiBvbiB0aGlzLCBhbmQg
SSB0aGluayB0aGlzIGNvdWxkIGJlIGFkZGVkIGFzIGFuIGV4dGVuc2lvbiBpbnN0ZWFkLCBidXQg
SSB0aGluayBpdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdG8gc2VlIGlmIGl0IGludGVncmF0ZXMg
bmljZWx5IGluIHRoZSBjdXJyZW50IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBvc3QtaGFu
ZHNoYWtlIGF1dGggZXhpc3RzIGJhc2ljYWxseSBlbnRpcmVseSB0byBzZXJ2aWNlIEhUVFAvMS4x
IHJlYWN0aXZlIGNsaWVudCBjZXJ0aWZpY2F0ZSB3aGljaCB3YXMgcHJldmlvdXNseSBoYWNrZWQg
b24gdmlhIHJlbmVnb3RpYXRpb24uIEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBtYWtlIHRoaXMgZmVh
dHVyZSBhbnkgbW9yZSBjb21wbGljYXRlZCB0aGFuIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIHN1
cHBvcnQNCiB0aGlzIG1vZGUsIGFuZCB3ZSBzaG91bGQgbm90IGFkZCBtb3JlIGJlbGxzIGFuZCB3
aGlzdGxlcyB0byBpdCB0byBlbmNvdXJhZ2UgZnVydGhlciB1c2UuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aGUgSFRUUC8xLjEgdXNl
IGNhc2UsIHRoaXMgaXMgbm90IG5lY2Vzc2FyeSBiZWNhdXNlIGl0J3MgcmVhc29uYWJsZSBmb3Ig
Y2xpZW50L3NlcnZlciB0byBhZ3JlZSB0aGF0IHRoZSBzZXJ2ZXIgd2lsbCBub3Qgc2VuZCBhbnkg
bW9yZSBkYXRhIGZvciB0aGF0IHJlcXVlc3QgdW50aWwgaXQgaGFzIHByb2Nlc3NlZCB0aGUgY2xp
ZW50J3MgYXV0aGVudGljYXRpb24gbWVzc2FnZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CY1PR0301MB08424704E884306DA56402268C5B0CY1PR0301MB0842_--


From nobody Wed Feb 15 13: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 264A112987D for ; Wed, 15 Feb 2017 13:58:45 -0800 (PST)
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=dWjirJ2i; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=a+vlSPiy
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5nIkaGvG6mr for ; Wed, 15 Feb 2017 13:58:42 -0800 (PST)
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 E685312987B for ; Wed, 15 Feb 2017 13:58:42 -0800 (PST)
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 v1FLsUtm024207; Wed, 15 Feb 2017 13:58:42 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Tw+G4oxUDccxj4H6yal7+Ht8yjen5kL+UlJXFjrFIiQ=; b=dWjirJ2i5WdaB9JIN/1AOsf35JLh8RDFsGABjkJwR7fE2CVWTmbWYlZS/QmKqJOYCL88 K8TZFSjE0ZY7u3PHibbgMoFqjVCXG6S4Ht73/KDi3KS+ehYEyNkAnBRLMNA7n5zaOkxA /TyuLSUbJAoReMC255mPUThjAtUE/MzJrAk= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 28mwq8gd88-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Feb 2017 13:58:42 -0800
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 15 Feb 2017 16:58:31 -0500
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=Tw+G4oxUDccxj4H6yal7+Ht8yjen5kL+UlJXFjrFIiQ=; b=a+vlSPiyF2IAjT9RJ3ixkCytJik053wdXF/dWHmqjfyuk5QyoVSIN5zUw4L3SJXeZIuNdY4VjqSBPQW3JEUbY5pmFonuC8K4qW8n5f2UlfOu3yWMDM9g2I1S5hpTyyY+pRnZnZOL1exfE5Mhys5JIQ6AWWwake6mAmE8fiMu96Y=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1184.namprd15.prod.outlook.com (10.175.2.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 21:58:29 +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.0888.030; Wed, 15 Feb 2017 21:58:29 +0000
From: Kyle Nekritz 
To: Eric Rescorla , "tls@ietf.org" 
Thread-Topic: [TLS] (no subject)
Thread-Index: AQHSgxobmLTy3ekfmkioGSfnCuvkJqFqpLsw
Date: Wed, 15 Feb 2017 21:58:28 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c091:200::2:486f]
x-ms-office365-filtering-correlation-id: c955f89c-3e7c-457a-2479-08d455edc679
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1184;
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1184; 7:edSg+GLXaDZKwLzrbpN3UyaNEHJO0euiGBxxJ6E1F/uInVioD0vYL+4iXZm+GqvIJymkb3sjsCtOL40nHmyZhv+tCoq/wRffBtkBHc+W8VkiNpL0wdF5Egcb+inn5tly0I8QkCvTuxwHxK5wWMY9ECbUoVQZj9DkgepJ9ODFqDRk93wsgDj7n9hOMCoo4NVNlXdZSRYFb9q8OpaB3EljBGNEsRr3kAjefMUQNdJMGl406b4wBO7Eo+f7xE012R2nLaXJJR1T7Lpq5bIZTSnSpY3hZ5vPGuZ3VpzV6bGk+FS0vb8GTZK7AvQVXnYf4xut5YPFbwuv2ls15gGITrnPvg==; 20:6vfIu+dJKN3Tw8XTleBA+aZucNYGgMwGta2w+gqzQxfMbEAQfQlj1SKxKxxNwG+/K/7PUd7i5GDNbk4HXgveveM21JTPzgWZ3m787mkaYodZmYBGjuLOk500INlrQ8ckm83mmpLpwTtufyQR2A6JyDWuF+1lMAHnhpZgoXdSSBQ=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:MWHPR15MB1184; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1184; 
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(199003)(189002)(53936002)(2900100001)(229853002)(38730400002)(221163002)(8936002)(5660300001)(8676002)(74316002)(81156014)(6246003)(86362001)(81166006)(7696004)(54896002)(54356999)(105586002)(77096006)(101416001)(189998001)(3280700002)(6436002)(3660700001)(2950100002)(25786008)(55016002)(9686003)(7736002)(6306002)(6506006)(2501003)(92566002)(106356001)(99286003)(106116001)(790700001)(2906002)(33656002)(76176999)(122556002)(68736007)(6116002)(102836003)(50986999)(389900002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1184; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182433C5D00B08356C66A31AF5B0MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 21:58:28.9408 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1184
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-02-15_11:, , signatures=0
Archived-At: 
Subject: Re: [TLS] (no subject)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 21:58:45 -0000

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

SSBoYXZlIGEgc21hbGwgcHJlZmVyZW5jZSBmb3Igb3B0aW9uIDEuIEkgdGhpbmsgaW4gYSB3YXkg
IzIgYW5kICMzIHJlcXVpcmUgYSBzcGVjaWFsIGNhc2UgYXMgd2VsbCBmb3IgdGhlIFBTSyBiaW5k
ZXIgdHJhbnNjcmlwdC4gVW5sZXNzIHdlIGNvbnNpZGVyIHRoZSB0cnVuY2F0ZWQgQ2xpZW50SGVs
bG8gYW5kIHRoZSByZXN0IG9mIHRoZSBDbGllbnRIZWxsbyBzZXBhcmF0ZSBtZXNzYWdlcywgdGhl
IGhhbmRzaGFrZSBoYXNoIHdpbGwgaGF2ZSB0byBtb3ZlIGJhY2t3YXJkcyBhZnRlciBjb21wdXRh
dGlvbiBvZiB0aGUgYmluZGVycyAocmVtb3ZpbmcgQ2xpZW50SGVsbG9bdHJ1bmNhdGVkXSBhbmQg
YWRkaW5nIHRoZSBmdWxsIENsaWVudEhlbGxvKS4gQWxsb3dpbmcgdGhlIGhhc2ggdG8gc29sZWx5
IG1vdmUgZm9yd2FyZCBhbGxvd3MgZm9yIGEgYml0IHNpbXBsZXIgaW1wbGVtZW50YXRpb24uDQoN
CkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJp
YyBSZXNjb3JsYQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcgNDoxOCBQTQ0KVG86
IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gKG5vIHN1YmplY3QpDQoNCkhpIGZvbGtzLA0K
DQpXZSBuZWVkIHRvIGNsb3NlIG9uIGFuIGlzc3VlIGFib3V0IHRoZSBzaXplIG9mIHRoZQ0Kc3Rh
dGUgaW4gdGhlIEhlbGxvUmV0cnlSZXF1ZXN0LiBCZWNhdXNlIHdlIGNvbnRpbnVlIHRoZSB0cmFu
c2NyaXB0DQphZnRlciBIUlIsIGlmIHlvdSB3YW50IGEgc3RhdGVsZXNzIEhSUiB0aGUgc2VydmVy
IG5lZWRzIHRvIGluY29ycG9yYXRlDQp0aGUgaGFzaCBzdGF0ZSBpbnRvIHRoZSBjb29raWUuIEhv
d2V2ZXIsIHRoaXMgaGFzIHR3byBpc3N1ZXM6DQoNCjEuIFRoZSAiQVBJIiBmb3IgY29udmVudGlv
bmFsIGhhc2hlcyBpc24ndCBkZXNpZ25lZCB0byBiZSBjaGVja3BvaW50ZWQNCiAgIGF0IGFyYml0
cmFyeSBwb2ludHMgKHRob3VnaCBQS0NTIzExIGF0IGxlYXN0IGRvZXMgaGF2ZSBzdXBwb3J0DQog
ICBmb3IgdGhpcy4pDQoyLiBUaGUgc3RhdGUgaXMgYmlnZ2VyIHRoYW4geW91IHdvdWxkIGxpa2Ug
Yi9jIHlvdSBuZWVkIHRvIHN0b3JlIGJvdGgNCiAgIHRoZSBjb21wcmVzc2lvbiBmdW5jdGlvbiBh
bmQgdGhlICJyZW1haW5kZXIiIG9mIGJ5dGVzIHRoYXQgZG9uJ3QNCiAgIGZpdCBpbiBbMF0NCg0K
T3BpbmlvbnMgZGlmZmVyIGFib3V0IGhvdyBzZXZlcmUgYWxsIHRoaXMgaXMsIGJ1dCBpdCdzIGNl
cnRhaW5seQ0KdW5hZXN0aGV0aWMsIGFuZCBpdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSBzdGF0ZSB0
aGF0IHdhcyBzdG9yZWQgaW4NCnRoZSBIUlIgY29va2llIHdhcyBqdXN0IGEgaGFzaCBvdXRwdXQu
IFRoZXJlIHNlZW0gdG8gYmUgdGhyZWUNCm1ham9yIGFwcHJvYWNoZXMgZm9yIHRoaXMgKGFzaWRl
IGZyb20gImRvIG5vdGhpbmciKS4NCg0KMS4gU3BlY2lhbCBjYXNlIEhSUiBhbmQgc2F5IHRoYXQg
dGhlIHRyYW5zY3JpcHQgaXMgZWl0aGVyDQoNCiAgIENIIHx8IFNIIC4uLi4gICAobm8gSFJSKQ0K
DQogICAgIG9yDQoNCiAgIEhhc2goQ0gxKSB8fCBIUlIgfHwgQ0ggLi4uIChIUlIpICBbMV0NCg0K
DQoyLiBQcmUtaGFzaCB0aGUgbWVzc2FnZXMsIHNvIHRoYXQgdGhlIGhhbmRzaGFrZSBoYXNoDQog
ICBiZWNvbWVzOg0KDQogICBIYW5kc2hha2VfaGFzaF9OID0gSGFzaChIYXNoKG1zZ18xKSB8fCBI
YXNoKG1zZ18yKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uIEhhc2gobXNnX04pKQ0K
DQozLiBSZWN1cnNpdmVseSBoYXNoLCBzbyB0aGF0IHRoZSBoYW5kc2hha2UgaGFzaCBiZWNvbWVz
Og0KDQogICBIYW5kc2hha2VfaGFzaF9OPSBIYXNoKEhhbmRzaGFrZV9oYXNoX04tMSB8fCBtc2df
TikNCg0KW0FzIEFudG9pbmUgRGVsaWduYXQtTGF2YXVkIHBvaW50cyBvdXQsIHRoaXMgaXMgYmFz
aWNhbGx5IG1ha2luZw0KYSBuZXcgTWVya2xlLURhbWdhcmQgaGFzaCB3aXRoIEggYXMgdGhlIGNv
bXByZXNzaW9uIGZ1bmN0aW9uLl0NCg0KDQpJJ3ZlIHBvc3RlZCBQUiM4NzYsIHdoaWNoIGltcGxl
bWVudHMgdmVyc2lvbiAjMiwgYnV0IHdlIGNvdWxkIGRvIGFueSBvbmUgb2YgdGhlIHRocmVlLg0K
YW5kIHRoZXkgYWxsIGhhdmUgdGhlIHNhbWUgc3RhdGUgc2l6ZS4gVGhlIGFyZ3VtZW50IGZvciAj
MSBzZWVtcyB0byBiZQ0KdGhhdCBpdCdzIHRoZSBtaW5pbWFsIGNoYW5nZSwgYW5kIGFsc28gdGhl
IG1pbmltYWwgb3ZlcmhlYWQsIGFuZCB0aGUNCmFyZ3VtZW50IGFnYWluc3QgaXMgdGhhdCBpdCdz
IG5vbi11bmlmb3JtIGJlY2F1c2UgQ0gxIGlzIHRyZWF0ZWQNCmRpZmZlcmVudGx5LiAgV2UgbWln
aHQgaW1hZ2luZSBtYWtpbmcgaXQgc2VlbSBtb3JlIHVuaWZvcm0gYnkgYWxzbw0KaGFzaGluZyBI
UlIgYnV0IHRoYXQgZG9lc24ndCBtYWtlIHRoZSBjb2RlIGFueSBzaW1wbGVyLiBWZXJzaW9ucyAj
Mg0KYW5kICMzIGJvdGggYXJlIG1vcmUgdW5pZm9ybSBidXQgYWxzbyBtb3JlIGNvbXBsaWNhdGVk
IGNoYW5nZXMuDQoNClRoZSBhcmd1bWVudHMgZm9yICMyIHZlcnN1cyAjMyBhcmUgdGhhdCAjMyBp
cyBzb21ld2hhdCBmYXN0ZXINCihjb25zaWRlciB0aGUgY2FzZSB3aGVyZSB5b3UgaGF2ZSBhIHNo
b3J0IG1lc3NhZ2UgdG8gYWRkLCAjMiBhbHdheXMNCm5lZWRzIHRvIHJ1biB0aGUgY29tcHJlc3Np
b24gZnVuY3Rpb24gdHdpY2Ugd2hlcmVhcyAjMyBjYW4gcnVuIGl0DQpvbmNlKS4gSG93ZXZlciwg
d2l0aCAjMyBpdCBpcyBwb3NzaWJsZSB0byB0YWtlIGEgaGFzaCBmb3IgYW4gdW5rbm93bg0KdHJh
bnNjcmlwdCBhbmQgY3JlYXRlIGEgbmV3IGhhc2ggdGhhdCBtYXRjaGVzIHRoYXQgdW5rbm93biB0
cmFuc2NyaXB0DQpwbHVzIGFuIGFyYml0cmFyeSBzdWZmaXguICBUaGlzIGlzIGFscmVhZHkgYSBw
cm9wZXJ0eSBvZiB0aGUgTS1EDQpoYXNoZXMgd2UgYXJlIHVzaW5nIGJ1dCBpdCdzIHdvcnNlIGhl
cmUgYmVjYXVzZSB0aG9zZSBoYXNoZXMgYWRkDQpwYWRkaW5nIGFuZCBsZW5ndGggYXQgdGhlIGVu
ZCBiZWZvcmUgZmluYWxpemluZywgc28gYW4gZXh0ZW5zaW9uDQp3b3VsZG4ndCBnZW5lcmFsbHkg
cmVmbGVjdCBhIHZhbGlkIGhhbmRzaGFrZSB0cmFuc2NyaXB0LCB3aGVyZWFzIGluDQp0aGlzIGNh
c2UgeW91IGdldCB0byBhcHBlbmQgYSB2YWxpZCBtZXNzYWdlLCBiZWNhdXNlIHRoZSBwYWRkaW5n
IGlzDQphZGRlZCB3aXRoIGV2ZXJ5IGZpbmFsaXphdGlvbiBzdGFnZS4gSSBkb24ndCBrbm93IG9m
IGFueSByZWFzb24NCndoeSB0aGlzIHdvdWxkIGJlIGEgc2VjdXJpdHkgaXNzdWUsIGJ1dCBJIGRv
bid0IGhhdmUgYW55IHByb29mIGl0J3MNCm5vdCwgZWl0aGVyLg0KDQpJJ2QgbGlrZSB0byBnZXQg
dGhlIFdHJ3MgdGhvdWdodHMgb24gaG93IHRvIHJlc29sdmUgdGhpcyBpc3N1ZSBvdmVyIHRoZSBu
ZXh0DQp3ZWVrIG9yIHNvIHNvIHdlIGNhbiBjbG9zZSB0aGlzIG91dC4NCg0KLUVrcg0KDQpbMF0g
VGhlIHdvcnN0LWNhc2Ugb3ZlcmhlYWQgZm9yIFNIQS0yNTYgaXMgPiA2NCBieXRlcyBhbmQgZm9y
IFNIQS01MTINCml04oCZcyA+IDEyOCBieXRlcy4gVGhlIGF2ZXJhZ2UgaXMgaGFsZiB0aGF0Lg0K
DQpbMV0gV2UgYWN0dWFsbHkgbmVlZCB0byBkbyBzb21ldGhpbmcgdG8gbWFrZSBpdCBpbmplY3Rp
dmUsIGJlY2F1c2UNCkgoQ0gxKSBtaWdodCBsb29rIGxpa2UgYSBoYW5kc2hha2UgbWVzc2FnZSwg
YnV0IHRoYXQgc2hvdWxkIGJlIGVhc3kuDQoNCg0K

--_000_MWHPR15MB1182433C5D00B08356C66A31AF5B0MWHPR15MB1182namp_
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
b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz
cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs
aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7
DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw
dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5
bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46
MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg
dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIGEgc21hbGwgcHJlZmVyZW5jZSBmb3Ig
b3B0aW9uIDEuIEkgdGhpbmsgaW4gYSB3YXkgIzIgYW5kICMzIHJlcXVpcmUgYSBzcGVjaWFsIGNh
c2UgYXMgd2VsbCBmb3IgdGhlIFBTSyBiaW5kZXIgdHJhbnNjcmlwdC4gVW5sZXNzIHdlIGNvbnNp
ZGVyIHRoZSB0cnVuY2F0ZWQgQ2xpZW50SGVsbG8NCiBhbmQgdGhlIHJlc3Qgb2YgdGhlIENsaWVu
dEhlbGxvIHNlcGFyYXRlIG1lc3NhZ2VzLCB0aGUgaGFuZHNoYWtlIGhhc2ggd2lsbCBoYXZlIHRv
IG1vdmUgYmFja3dhcmRzIGFmdGVyIGNvbXB1dGF0aW9uIG9mIHRoZSBiaW5kZXJzIChyZW1vdmlu
ZyBDbGllbnRIZWxsb1t0cnVuY2F0ZWRdIGFuZCBhZGRpbmcgdGhlIGZ1bGwgQ2xpZW50SGVsbG8p
LiBBbGxvd2luZyB0aGUgaGFzaCB0byBzb2xlbHkgbW92ZSBmb3J3YXJkIGFsbG93cyBmb3IgYSBi
aXQNCiBzaW1wbGVyIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDks
IDIwMTcgNDoxOCBQTTxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFtUTFNdIChubyBzdWJqZWN0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgbmVlZCB0byBjbG9zZSBvbiBhbiBpc3N1ZSBhYm91dCB0
aGUgc2l6ZSBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPnN0YXRlIGluIHRoZSBIZWxsb1JldHJ5UmVxdWVzdC4gQmVjYXVzZSB3ZSBjb250
aW51ZSB0aGUgdHJhbnNjcmlwdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+YWZ0ZXIgSFJSLCBpZiB5b3Ugd2FudCBhIHN0YXRlbGVzcyBIUlIgdGhl
IHNlcnZlciBuZWVkcyB0byBpbmNvcnBvcmF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGhhc2ggc3RhdGUgaW50byB0aGUgY29va2llLiBI
b3dldmVyLCB0aGlzIGhhcyB0d28gaXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBUaGUgJnF1b3Q7QVBJJnF1b3Q7IGZvciBjb252
ZW50aW9uYWwgaGFzaGVzIGlzbid0IGRlc2lnbmVkIHRvIGJlIGNoZWNrcG9pbnRlZDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw
O2F0IGFyYml0cmFyeSBwb2ludHMgKHRob3VnaCBQS0NTIzExIGF0IGxlYXN0IGRvZXMgaGF2ZSBz
dXBwb3J0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDsgJm5ic3A7Zm9yIHRoaXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVGhlIHN0YXRlIGlzIGJpZ2dlciB0aGFuIHlvdSB3b3Vs
ZCBsaWtlIGIvYyB5b3UgbmVlZCB0byBzdG9yZSBib3RoPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGhlIGNvbXByZXNzaW9u
IGZ1bmN0aW9uIGFuZCB0aGUgJnF1b3Q7cmVtYWluZGVyJnF1b3Q7IG9mIGJ5dGVzIHRoYXQgZG9u
J3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAmbmJzcDtmaXQgaW4gWzBdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9waW5pb25zIGRpZmZlciBhYm91dCBob3cgc2V2ZXJlIGFsbCB0
aGlzIGlzLCBidXQgaXQncyBjZXJ0YWlubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVuYWVzdGhldGljLCBhbmQgaXQgd291bGQgYmUgbmljZSBp
ZiB0aGUgc3RhdGUgdGhhdCB3YXMgc3RvcmVkIGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgSFJSIGNvb2tpZSB3YXMganVzdCBhIGhhc2gg
b3V0cHV0LiBUaGVyZSBzZWVtIHRvIGJlIHRocmVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYWpvciBhcHByb2FjaGVzIGZvciB0aGlzIChhc2lk
ZSBmcm9tICZxdW90O2RvIG5vdGhpbmcmcXVvdDspLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBTcGVjaWFsIGNhc2UgSFJSIGFuZCBzYXkg
dGhhdCB0aGUgdHJhbnNjcmlwdCBpcyBlaXRoZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0NIIHx8IFNIIC4uLi4gJm5i
c3A7IChubyBIUlIpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO29yPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
ICZuYnNwO0hhc2goQ0gxKSB8fCBIUlIgfHwgQ0ggLi4uIChIUlIpICZuYnNwO1sxXTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFByZS1o
YXNoIHRoZSBtZXNzYWdlcywgc28gdGhhdCB0aGUgaGFuZHNoYWtlIGhhc2g8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtiZWNv
bWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDsgJm5ic3A7SGFuZHNoYWtlX2hhc2hfTiA9IEhhc2goSGFzaChtc2dfMSkgfHwgSGFz
aChtc2dfMik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi4gSGFzaChtc2df
TikpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjMuIFJlY3Vyc2l2ZWx5IGhhc2gsIHNvIHRoYXQgdGhlIGhhbmRzaGFrZSBoYXNoIGJlY29tZXM6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAmbmJzcDtIYW5kc2hha2VfaGFzaF9OPSBIYXNoKEhhbmRzaGFrZV9oYXNoX04tMSB8fCBt
c2dfTik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+W0FzIEFudG9pbmUgRGVsaWduYXQtTGF2YXVkIHBvaW50cyBvdXQsIHRoaXMgaXMgYmFzaWNh
bGx5IG1ha2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YSBuZXcgTWVya2xlLURhbWdhcmQgaGFzaCB3aXRoIEggYXMgdGhlIGNvbXByZXNzaW9u
IGZ1bmN0aW9uLl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JJ3ZlIHBvc3RlZCBQUiM4NzYsIHdoaWNoIGltcGxlbWVudHMgdmVyc2lvbiAj
MiwgYnV0IHdlIGNvdWxkIGRvIGFueSBvbmUgb2YgdGhlIHRocmVlLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZXkgYWxsIGhhdmUgdGhl
IHNhbWUgc3RhdGUgc2l6ZS4gVGhlIGFyZ3VtZW50IGZvciAjMSBzZWVtcyB0byBiZTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCBpdCdzIHRo
ZSBtaW5pbWFsIGNoYW5nZSwgYW5kIGFsc28gdGhlIG1pbmltYWwgb3ZlcmhlYWQsIGFuZCB0aGU8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZ3Vt
ZW50IGFnYWluc3QgaXMgdGhhdCBpdCdzIG5vbi11bmlmb3JtIGJlY2F1c2UgQ0gxIGlzIHRyZWF0
ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRp
ZmZlcmVudGx5LiZuYnNwOyBXZSBtaWdodCBpbWFnaW5lIG1ha2luZyBpdCBzZWVtIG1vcmUgdW5p
Zm9ybSBieSBhbHNvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5oYXNoaW5nIEhSUiBidXQgdGhhdCBkb2Vzbid0IG1ha2UgdGhlIGNvZGUgYW55IHNp
bXBsZXIuIFZlcnNpb25zICMyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5hbmQgIzMgYm90aCBhcmUgbW9yZSB1bmlmb3JtIGJ1dCBhbHNvIG1vcmUg
Y29tcGxpY2F0ZWQgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFyZ3VtZW50cyBmb3IgIzIgdmVyc3VzICMzIGFyZSB0aGF0
ICMzIGlzIHNvbWV3aGF0IGZhc3RlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+KGNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIHlvdSBoYXZlIGEgc2hv
cnQgbWVzc2FnZSB0byBhZGQsICMyIGFsd2F5czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVlZHMgdG8gcnVuIHRoZSBjb21wcmVzc2lvbiBmdW5j
dGlvbiB0d2ljZSB3aGVyZWFzICMzIGNhbiBydW4gaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9uY2UpLiBIb3dldmVyLCB3aXRoICMzIGl0IGlz
IHBvc3NpYmxlIHRvIHRha2UgYSBoYXNoIGZvciBhbiB1bmtub3duPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cmFuc2NyaXB0IGFuZCBjcmVhdGUg
YSBuZXcgaGFzaCB0aGF0IG1hdGNoZXMgdGhhdCB1bmtub3duIHRyYW5zY3JpcHQ8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBsdXMgYW4gYXJiaXRy
YXJ5IHN1ZmZpeC4mbmJzcDsgVGhpcyBpcyBhbHJlYWR5IGEgcHJvcGVydHkgb2YgdGhlIE0tRDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGFzaGVz
IHdlIGFyZSB1c2luZyBidXQgaXQncyB3b3JzZSBoZXJlIGJlY2F1c2UgdGhvc2UgaGFzaGVzIGFk
ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGFk
ZGluZyBhbmQgbGVuZ3RoIGF0IHRoZSBlbmQgYmVmb3JlIGZpbmFsaXppbmcsIHNvIGFuIGV4dGVu
c2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
d291bGRuJ3QgZ2VuZXJhbGx5IHJlZmxlY3QgYSB2YWxpZCBoYW5kc2hha2UgdHJhbnNjcmlwdCwg
d2hlcmVhcyBpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+dGhpcyBjYXNlIHlvdSBnZXQgdG8gYXBwZW5kIGEgdmFsaWQgbWVzc2FnZSwgYmVjYXVz
ZSB0aGUgcGFkZGluZyBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+YWRkZWQgd2l0aCBldmVyeSBmaW5hbGl6YXRpb24gc3RhZ2UuIEkgZG9uJ3Qg
a25vdyBvZiBhbnkgcmVhc29uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj53aHkgdGhpcyB3b3VsZCBiZSBhIHNlY3VyaXR5IGlzc3VlLCBidXQgSSBk
b24ndCBoYXZlIGFueSBwcm9vZiBpdCdzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3QsIGVpdGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIGxpa2UgdG8gZ2V0IHRoZSBXRydzIHRo
b3VnaHRzIG9uIGhvdyB0byByZXNvbHZlIHRoaXMgaXNzdWUgb3ZlciB0aGUgbmV4dDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2VlayBvciBzbyBz
byB3ZSBjYW4gY2xvc2UgdGhpcyBvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlswXSBUaGUgd29yc3QtY2FzZSBvdmVyaGVh
ZCBmb3IgU0hBLTI1NiBpcyAmZ3Q7IDY0IGJ5dGVzIGFuZCBmb3IgU0hBLTUxMjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXTigJlzICZndDsgMTI4
IGJ5dGVzLiBUaGUgYXZlcmFnZSBpcyBoYWxmIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSBXZSBhY3R1YWxseSBuZWVkIHRvIGRv
IHNvbWV0aGluZyB0byBtYWtlIGl0IGluamVjdGl2ZSwgYmVjYXVzZTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SChDSDEpIG1pZ2h0IGxvb2sgbGlr
ZSBhIGhhbmRzaGFrZSBtZXNzYWdlLCBidXQgdGhhdCBzaG91bGQgYmUgZWFzeS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_MWHPR15MB1182433C5D00B08356C66A31AF5B0MWHPR15MB1182namp_--


From nobody Thu Feb 16 03:42: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 49FCF129A95; Thu, 16 Feb 2017 03:42:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148724536629.15905.11891893610273518899.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 03:42:46 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-12.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is the mailing list 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, 16 Feb 2017 11:42:46 -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-12.txt
	Pages           : 32
	Date            : 2017-02-16

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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-12


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 Feb 16 03:54: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 DCF8C1299F1 for ; Thu, 16 Feb 2017 03:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 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_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 R321s8AwOUmn for ; Thu, 16 Feb 2017 03:54:12 -0800 (PST)
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 0F2FF1299A9 for ; Thu, 16 Feb 2017 03:54:12 -0800 (PST)
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 3vPF1Z2n3Rz25VL; Thu, 16 Feb 2017 12:54:10 +0100 (CET)
X-purgate-ID: 152705::1487246050-00002B31-C0278D5B/0/0
X-purgate-size: 1377
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 3vPF1Y5WMpzGpJT; Thu, 16 Feb 2017 12:54:09 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AE7E21A625; Thu, 16 Feb 2017 12:54:09 +0100 (CET)
In-Reply-To: 
To: David Benjamin 
Date: Thu, 16 Feb 2017 12:54:09 +0100 (CET)
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: <20170216115409.AE7E21A625@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: Cas Cremers , tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list 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, 16 Feb 2017 11:54:14 -0000

David Benjamin wrote:
> 
> Post-handshake auth exists basically entirely to service HTTP/1.1 reactive
> client certificate which was previously hacked on via renegotiation. I
> think we should not make this feature any more complicated than absolutely
> necessary to support this mode, and we should not add more bells and
> whistles to it to encourage further use.
> 
> For the HTTP/1.1 use case, this is not necessary because it's reasonable
> for client/server to agree that the server will not send any more data for
> that request until it has processed the client's authentication messages.

Well, the funny thing here is how HTTP/1.1 POST works when the server
asks for a certificate through renegotiation.  The client-side data,
which may be a multi-megabyte upload, will be performed entirely before
the renegotiation, and any renegotiation requested by the server might
be sitting in the incoming network buffer and ignored by the
client.  Depending on how much data the server expects, and the bandwith
available to the client upstream, the server might not even want to start
the renegotiation handshake before the client has completed transmission,
because this might result in a connection termination (when the client
needs more than 2*MSL for the upload and doesn't perform any recv() / SSL_Read
on the socket while uploading.

-Martin


From nobody Thu Feb 16 04: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 ABB6F129AD5 for ; Thu, 16 Feb 2017 04:29:43 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 IKkatHFKFc_E for ; Thu, 16 Feb 2017 04:29:41 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADD7129AC6 for ; Thu, 16 Feb 2017 04:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mn427C0mM0Y1SKWnGL0lLQfr4uMnjO2JxwenELlWOjg=; b=dT3KPENs+l9JSnAPpaPIba6ZVlO11b53psU6lxpHwY1zShArPJLv8kRmSmeDgMmFd+qPf3aj9xjwL0C2tLk5w4+3zxnPWRD2MN9kObo5zqyKZr0lDkBIzzqHBumwg9p4LeK2VZ+R4Hr9SODIhilxXe/y5gDsx9kHoiRGdL1AT3s=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 12:23:06 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.034; Thu, 16 Feb 2017 12:23:05 +0000
From: "Dang, Quynh (Fed)" 
To: "Paterson, Kenny" , "Dang, Quynh (Fed)" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwyaNRpm4jTNwkW4fHeK7pLqGKFpp3IAgABuRACAASc0AA==
Date: Thu, 16 Feb 2017 12:23:05 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>            
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.219.235]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:PNqhs7Oz7bssgbJDv8FflZ5IyyGxCn67rxc6v4oUTehPAkehfhi/AjVPmyirnpII+pE3aw8ahmf9hiSGbjWMdiznZxrje37UOGw7iu/O5QYqpQ28eWj9nZkxpB1XMuHc6PfaEcUQtRSpcB/YJJSpqneKnZjv+8siaLzuJzISCtH1LqQ+6wNL7ucVmmyEiRv2rRG3cWFYDtZif0By6jDyyMr31OwS6OQ5FLuUV3T8BSRX+z7/tuAmPu/F+XVRgrkDEC02R28+NR4eduLeZin3h8lkgkDq424qL8/bbK4hgn0YolyssB8qi8fyZxWiR7TNugX51j7hD5RSY8jfLXq4qg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(377424004)(377454003)(24454002)(6306002)(6512007)(25786008)(66066001)(83506001)(97736004)(3660700001)(606005)(54896002)(4001350100001)(6246003)(8936002)(105586002)(5660300001)(122556002)(236005)(7906003)(53546003)(6506006)(7736002)(389900003)(39060400002)(6436002)(2900100001)(6486002)(38730400002)(8656002)(68736007)(77096006)(2950100002)(102836003)(4326007)(2906002)(54356999)(93886004)(50986999)(76176999)(229853002)(99286003)(101416001)(189998001)(92566002)(54906002)(81166006)(8676002)(106356001)(3280700002)(106116001)(81156014)(3846002)(86362001)(36756003)(53936002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 44fe5b57-84a4-4403-6e9e-08d456668f4a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; 
x-forefront-prvs: 0220D4B98D
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D4CAF7363040Cqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 12:23:05.5154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 12:29:43 -0000

--_000_D4CAF7363040Cqdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Kenny,

I am glad to see that you enjoyed the discussion more than what you planed =
for the time on your vacation.  We love crypto and the IETF!

From: "Paterson, Kenny" >
Date: Wednesday, February 15, 2017 at 8:46 AM
To: 'Quynh' >
Cc: Atul Luykx >, Yoav Nir >, IRTF CFR=
G >, "tls@ietf.org=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi Quynh,

I'm meant to be on vacation, but I'm finding this on-going discussion fasci=
nating, so I'm chipping in again.

On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) > wrote:

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir >
Cc: 'Quynh' >, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically=
 the same: they are practically zero.

I'm not clear what you mean by "practically" here.

As far as I know, such chance has not happened in history for any targeted =
search where the chance for hitting the target is 1 in 2^32.

They're clearly not the same as real numbers. And if we are being conservat=
ive about security, then the extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers ca=
n=92t improve their chance: no matter how much computational power the atta=
cker has.

A sufficiently powerful adversary could carry out an exhaustive key search =
for GCM's underlying AES key. So I'm not sure what you're claiming here whe=
n you speak of "absolute chance".

I described my point not in a best way, sorry. For key recovery, if an atta=
cker can do 2^96 AES operations, his chance of finding the key is 2^-32, bu=
t this chance will get improved if the attacker does more computation. On t=
he contrary, the chance for the distinguishing attack won=92t change with t=
he proposed data limit.


I don=92t understand why the number 2^-60 is your special chosen number for=
 this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for I=
NT-CTXT for a wide range of parameters covering both TLS and DTLS (where ma=
ny verification failures may be permitted). Then, since we're ultimately in=
terested in AE security, we would like to (roughly) match this for IND-CPA =
security, to get as good a bound as we can for AE security (the security bo=
unds for the two notions sum to give an AE security bound - see page 2 of t=
he "AE bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound mu=
ch lower than 2^-60 if the ultimate target is AE security. It just hurts th=
e data limits more without significantly improving AE security.

I just checked the paper. There is a small error I think. AES-GCM in TLS 1.=
3 is a prf. Under a given key, every input block or just one repeated block=
 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks assumin=
g the key has 128 bits of entropy. If there is a collision among the cipher=
text blocks, it does not mean anything because it does not say anything abo=
ut the plaintext blocks.



Finally, 2^-60 is not *our* special chosen number. We wrote a note that con=
tained a table of values, and it's worth noting that we did not make a spec=
ific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without ma=
king rekeying a frequent event. It's a continuing surprise to me that you a=
re pushing for an option that actually reduces security when achieving high=
er security does not seem to cause any problems for implementors.)

I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are =
all safe choices. If someone wants to rekey sooner (or often) for operation=
al reason or any other reason, that would be just fine. I just hope that we=
 don=92t have text which might imply that 2^-32 is not a safe choice.  In o=
ur guidelines, we basically indicate that 2^-32 or below is safe.



In your =93theory=94, 2^-112 would be in =93higher=94 security than 2^-60.

It certainly would, if it were achievable (which it is not for GCM without =
putting some quite extreme limits on data per key).

Cheers,

Kenny

I am going to propose another option and I hope that you and all other peop=
le will be happy with.

Thank you and Regards,
Quynh.


Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) >
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I=92m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
------
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
_______________________________________________
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

--_000_D4CAF7363040Cqdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <5ACDD6F01661D047B3EB2DC07E8FB180@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Kenny,







I am glad to see that you enjoyed the discussion more than what you pl=
aned for the time on your vacation.  We love crypto and the IETF! =
;









From: "Paterson, Kenny" &=
lt;Kenny.Paterson@rhul.ac.uk>

Date: Wednesday, February 15, 2017 =
at 8:46 AM

To: 'Quynh' <Quynh.Dang@nist.gov>

Cc: Atul Luykx <Atul.Luykx@esat.kuleuven.be>, Yoav Ni=
r <ynir.ietf@gmail.com>, I=
RTF CFRG <cfrg@irtf.org>,
 "tls@ietf.org" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hi Quynh,






I'm meant to be on vacation, but I'm finding=
 this on-going discussion fascinating, so I'm chipping in again. 



On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:










Hi Atul,







I hope you had a happy Valentine! 









From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 4:52 PM

To: Yoav Nir <ynir.ietf@gmail.com>

Cc: 'Quynh' <Quynh.Dang@nist.gov>, IRTF CFRG <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.=
org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)

















Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Because he wants to lower the security level. 














I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practi=
cally the same: they are practically zero.  











I'm not clear what you mean by "practically" here.














As far as I know, such chance has not happened in history for any targ=
eted search where the chance for hitting the target is 1 in 2^32. 













They're clearly not the same as real numbers. And if we are being cons=
ervative about security, then the extremes in your list are a long way apar=
t. 











And, 2^-32 is an absolute chance in this case meaning that all attacke=
rs can=92t improve their chance: no matter how much computational power the=
 attacker has.   










A sufficiently powerful adversary could carry out an exhaustive key search =
for GCM's underlying AES key. So I'm not sure what you're claiming here whe=
n you speak of "absolute chance". 












I described my point not in a best way, sorry. For key recovery, if an=
 attacker can do 2^96 AES operations, his chance of finding the key is 2^-3=
2, but this chance will get improved if the attacker does more computation.=
 On the contrary, the chance for
 the distinguishing attack won=92t change with the proposed data limit.&nbs=
p;














 







I don=92t understand why the number 2^-60 is your special chosen numbe=
r for this ?












This is a bit subtle, but I'll try to explain in simple terms. 





We can conveniently prove a bound of about this size (actually 2^-57) for I=
NT-CTXT for a wide range of parameters covering both TLS and DTLS (where ma=
ny verification failures may be permitted). Then, since we're ultimately in=
terested in AE security, we would
 like to (roughly) match this for IND-CPA security, to get as good a bound =
as we can for AE security (the security bounds for the two notions sum to g=
ive an AE security bound - see page 2 of the "AE bounds" note).&n=
bsp;







In view of the INT-CTXT bound there's no point pushing the IND-CPA bou=
nd much lower than 2^-60 if the ultimate target is AE security. It just hur=
ts the data limits more without significantly improving AE security. <=
/div>















I just checked the paper. There is a small error I think. AES-GCM in T=
LS 1.3 is a prf. Under a given key, every input block or just one repeated =
block 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks as=
suming the key has 128 bits of entropy.
 If there is a collision among the ciphertext blocks, it does not mean anyt=
hing because it does not say anything about the plaintext blocks.  

























Finally, 2^-60 is not *our* special chosen number. We wrote a note tha=
t contained a table of values, and it's worth noting that we did not make a=
 specific recommendation in our note for which row of the table to select.&=
nbsp;







(Naturally, though, we'd like security to be as high as possible witho=
ut making rekeying a frequent event. It's a continuing surprise to me that =
you are pushing for an option that actually reduces security when achieving=
 higher security does not seem to
 cause any problems for implementors.) 
















I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60=
 are all safe choices. If someone wants to rekey sooner (or often) for oper=
ational reason or any other reason, that would be just fine. I just hope th=
at we don=92t have text which might
 imply that 2^-32 is not a safe choice.  In our guidelines, we basical=
ly indicate that 2^-32 or below is safe. 
































In your =93theory=94, 2^-112 would be in =93higher=94 security than 2^=
-60. 











It certainly would, if it were achievable (which it is not for GCM wit=
hout putting some quite extreme limits on data per key). 







Cheers,







Kenny 


















I am going to propose another option and I hope that you and all other=
 people will be happy with. 







Thank you and Regards,


Quynh. 

























Quynh.  



















The original text 


recommends switching at 2^{34.5} input blocks, corresponding to a 

success probability of 2^{-60}, whereas his text recommends switching =
at 


2^{48} blocks, corresponding to a success probability of 2^{-32}.






Atul







On 2017-02-14 11:45, Yoav Nir wrote:




Hi, Quynh






On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.dang@nist.gov>


wrote:




Hi Sean and all,




Beside my suggestion at



I have a second suggestion below.




Just replacing this sentence: "




For AES-GCM, up to 2^24.5 full-size records (about 24 million) may

be


encrypted on a given connection while keeping a safety margin of


approximately 2^-57 for Authenticated Encryption (AE) security.


" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48=



(partial or full) input blocks may be encrypted with one key. For

other suggestions and analysis, see the referred paper above."



Regards,


Quynh.






I like the suggestion, but I=92m probably missing something pretty

basic about it.




2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or

(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10

blocks.




Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Thanks




Yoav








Links:


------



_______________________________________________


TLS mailing list























_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.iet=
f.org/mailman/listinfo/tls



















--_000_D4CAF7363040Cqdangnistgov_--


From nobody Thu Feb 16 11:10: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 1CC901294F8 for ; Thu, 16 Feb 2017 11:10:53 -0800 (PST)
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 DKcU2Zjb8QUZ for ; Thu, 16 Feb 2017 11:10:51 -0800 (PST)
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 4E5501294C6 for ; Thu, 16 Feb 2017 11:10:51 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id v23so22975544qtb.0 for ; Thu, 16 Feb 2017 11:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=aV6oEV5NJNCh7pya5diey9/XgEFY3Y1dWv2SpUwCF2M=; b=Sf3KFiLtlxFoQFH3Vzv4DRM/uXEXyAKrW7h303VclrbvdFMn03Fq4w0ohGTkiKZtWT E5gopNGNQe/Vj5jGjBoEFBFG7z5eHZivREGdY11YaBB9ahYdhPXEZEm/TIRMCQeAfvNX QvOAcj50Uu9g36KsnexACSeaGN+pA/TBNnNNA=
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 :content-transfer-encoding:message-id:references:to; bh=aV6oEV5NJNCh7pya5diey9/XgEFY3Y1dWv2SpUwCF2M=; b=Z65D2cMwswCfAiT8ZaElchvnD0iNnO00kmyXZab1+Pmp4ooQKl1rCF6a8YTyWId7ds OPbvroI/S6eVP1qOk9M2bG4Dgd4rkY6Q59bckr0xmfF4UXGn7RGZ7rLH2mLUaf1THBMo SFU2FfnsQmtFL0ZVdVPI0cCS53e5V1p1842QlKq8eyOHk0KT4HzEULpsZ/T6hsK5Ja99 FJFtZyKilusuuQ5oDdIGguwKJv+39q1VgVzl+FiiYGqH/7iZtCgNUxeYz3k5/j+1yoTR D5zOEc3DGz58Hwi5bfaRojNKKBHMjsdZu6ZrZigjrP7MSuAARLwLOHv+BYti3ZIBKgvv 7cwg==
X-Gm-Message-State: AMke39kZCaRC729f+AK6gHHDwKnBO3jxwNiAFNoDclfPwRlrwf/fZqPLn70CVNvCZX9u/g==
X-Received: by 10.200.40.38 with SMTP id 35mr3634694qtq.216.1487272249910; Thu, 16 Feb 2017 11:10:49 -0800 (PST)
Received: from [172.16.0.92] ([96.231.219.116]) by smtp.gmail.com with ESMTPSA id n42sm4953811qtn.58.2017.02.16.11.10.48 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:10:48 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: <148724536629.15905.11891893610273518899.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 14:10:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <148724536629.15905.11891893610273518899.idtracker@ietfa.amsl.com>
To: "" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-12.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 19:10:53 -0000

I=E2=80=99m about hit the button to forward this to Stephen.  After =
Stephen=E2=80=99s AD review there will be two IETF LCs, one for this =
draft and one to uplift RFC 5289 from informational to standards track.

spt=20

> On Feb 16, 2017, at 06:42, internet-drafts@ietf.org wrote:
>=20
>=20
> 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.
>=20
>        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-12.txt
> 	Pages           : 32
> 	Date            : 2017-02-16
>=20
> 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.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-12
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-12
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Thu Feb 16 11:33: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 DFB3D12955E for ; Thu, 16 Feb 2017 11:33:46 -0800 (PST)
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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 LvMNq1MCBgcr for ; Thu, 16 Feb 2017 11:33:45 -0800 (PST)
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 26D67129653 for ; Thu, 16 Feb 2017 11:33:45 -0800 (PST)
Received: by mail-wr0-x22e.google.com with SMTP id z61so18556755wrc.1 for ; Thu, 16 Feb 2017 11:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=fw2jktFOTSwYWkYtcPGQS13BqI8oauZo3a0+Xvpcc9Q=; b=ID6PGVxtjoWxu9B/gfGZTeClZQEATGGW5CC5hsKjTAT5JtIBFHNaTEI4Yzi911DhFh qMpZXHaytKRRWx1t9c4IDnxGgkwcjsTq8h/LNhrfsJPwMPcNrNw1AGTkT4yCuNbJmn93 xpZHnEpKlgT5dk5xpjl/oUX2Cy21T0ADGMrao=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=fw2jktFOTSwYWkYtcPGQS13BqI8oauZo3a0+Xvpcc9Q=; b=hMsCosDY7p3OBrYUTLJQ9gRgBwxMFvimIyLvrZdYVoMwvLThSsKn2ng0v36rP4iJ8l KvxKhHqKkEygLBraFZZ85P37y0HDkxL7LKvClnSR5uvyXy3wmlYOJFTjhe7MA04+lr8U 4JsGzyGvmHF83AqQOVT0fnQplEu5nbE7zeIV/STJ8Lc72h1j7/D66lBqteSU4483gqNZ 6X1y8OG+M0sxegUFQ0I0KAKtnW1ij58bhAiRXHcjYvSYYTibEFVgnqI/yTwzjPZfas4n YcG8+wol69K3ynfXVwWWO7Ev5X1ZdGRWITaNG1ul7LFS+kj8JMgpt7QwwvcGabGl8y94 qd/A==
X-Gm-Message-State: AMke39lDa/GNKG7Mo/e7NEFv/U//0A2vWFVO0jgjkL0GJENoHwMTQMaCIF0dRavCklmJbg==
X-Received: by 10.223.131.99 with SMTP id 90mr3791850wrd.146.1487273623585; Thu, 16 Feb 2017 11:33:43 -0800 (PST)
Received: from [192.168.1.120] ([156.218.58.77]) by smtp.gmail.com with ESMTPSA id v128sm1464652wmv.2.2017.02.16.11.33.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:33:42 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner 
In-Reply-To: 
Date: Thu, 16 Feb 2017 21:33:39 +0200
Message-Id: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 19:33:47 -0000

--Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 15 Feb 2017, at 19:25, Martin Thomson  =
wrote:
>=20
> On 16 February 2017 at 04:20, Yoav Nir  wrote:
>> No, not really, but TLS is not just the web, and there are =
connections that
>> last for a long time and transfer large amounts of data. Think =
datacenter
>> synchronization. At packet-sized records 24 million records amounts =
to 36
>> GB. That is considerably larger than a 4 GB software update I =
downloaded
>> over HTTPS a few years ago, but not out of the ballpark.
>=20
> I realize that's going to require updates pretty often (once you open
> up the CWND), but I don't think that it is frequent enough to be a
> concern.
>=20
> I well know that HTTP gets used at these volumes more often than
> people realize.  I'd rather recommend ChaCha for those niche uses
> though if the rate was sufficiently high.

I agree with Yoav Nir here, it's certainly not a niche use* and one's =
implementation should not be forced to use a certain cipher mode if =
there would be better options (e.g. because -- as pointed out earlier -- =
hardware support is available).

* We'll all agree that most of the TLS traffic is made up by HTTPS =
requests, still, there are many other uses and we design protocols not =
just for the web. That's W3C.

Aaron


--Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

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

iQIcBAEBCgAGBQJYpf6UAAoJEOTbZJL9ubXVaBoQAIOmxMA1AwJ8CJTdqugN+jUS
t65bY6qAJA0trFn+aQy/U3HAAZ8GF5QfoYqKlenUI5t7M9Hh392yIp81DahEfa0E
f/n1YRWM+oxiwRpxM0QYHI9DEcseexwW4A9JIoByj4aNay/yhLazMSzv6bfJ6sMS
V2DC+64VbfyPAGLZbD4dsyWsL4JYigm347bN13Iw5LqNqK6M0t7J26o3iUp5wISl
BW8LSeTn3R354y7junwBk9sMbJCOcutREYHRzj2rgyfwbth+A+oi66xkeVY7nuXH
ImjlBVMugVhs59wnwH6AAdoqVl6Ky9/+8Jc+bPNROnlziaHprx67wvhQeM6FkbUn
CXWs/ShYgsptAYh60GsNFEgcgdT0Vzb508y0Ga+xC6NzQ8o5p5+4jEouWcFIEcHo
DHIPgo1Ds8hs86tVrgrR6Zkub0canTmU4rHv+M3ypl9UQbD/twnqPt68t+h3LkVf
yfZCKTrUiz5t4PLKnQvJyR2zYCZ3G4yBGeAzcwIBQTHmjQTulJGjKOqhHJMsizdM
4B03obkE08w3Y+Oot+CcrwLbhpi7AvedOmDESW8l2APanElLv6Uo/KAsw6K3+gS3
WjKaQtMv1Z6RqBIKGcViT+3wg4quvrZvcwgwXK73lVRZmyLsDLsOpnvOZSNBtJBg
Dc9iA3OMOsgZj4IN2rLx
=UNkw
-----END PGP SIGNATURE-----

--Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4--


From nobody Thu Feb 16 11:51: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 DB04E129524 for ; Thu, 16 Feb 2017 11:51:30 -0800 (PST)
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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 iOa7qO9PO1tF for ; Thu, 16 Feb 2017 11:51:29 -0800 (PST)
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 82B94128E18 for ; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
Received: by mail-wr0-x22e.google.com with SMTP id c4so18835066wrd.2 for ; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=RP4xmjiRaKg7T4jJ97gb2pPn4Ltw9WKeNIyOX3mryIg=; b=Af4dCvKReirZmYe9Qg7O37V4D39sHCQ6eGwmA+sD6v1px8L4p6R1GJpzPF3r9zvr0t SOqW22TOQboo8oISjcYbJ3wke0cY+XFGK2ROQ67OSNfZoroqxT0OZQ8amvuoz36L9aEw NXxy7Mtdc9T6++Xjz5PSzaVFnFAUUdwv7+2Tc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=RP4xmjiRaKg7T4jJ97gb2pPn4Ltw9WKeNIyOX3mryIg=; b=C6vIKgPlX2ta/yJ5R0FfVG3JIKR4CL9Bso8zgFpnb2OZRg67KvWxu/bzKNDG4xk2Tb 5FRkhU+Yy0WIs0F+WEiHwB/y+5uNlX6Yn1GJ5aNxs2JndprgYQt0+WjejmOpAmR5RsMf YZNrWwZi/m6QB7SXzWhAZkY4CoQ3AfNs2yiFo7D9raLZwvYiobsxKq/Guhf56okx6Wmx Ut4m3hZXU9Mb0F3qb7jLam7rpXXdrCULtCdQGczOB2P16S2/NE2RzBLJ1nsSawATgnRz Uek2ACS5LWAPgCiBKWS5+6qtlAkrLGPh5m+lAdxrZjPRFVvWtnxqa/LFVyqOM7DNYG4M SPig==
X-Gm-Message-State: AMke39lQC26yEUC21ThEqCZp35G7/LpGKdvfEhbodonRog1P4PBFxjhIqqvWSeLXzbB5/w==
X-Received: by 10.223.179.87 with SMTP id k23mr4226551wrd.32.1487274686969; Thu, 16 Feb 2017 11:51:26 -0800 (PST)
Received: from [192.168.1.120] ([156.218.58.77]) by smtp.gmail.com with ESMTPSA id c202sm1492730wmd.10.2017.02.16.11.51.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:51:26 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner 
In-Reply-To: 
Date: Thu, 16 Feb 2017 21:51:22 +0200
Message-Id: <8EEF5E9A-FFCD-44F9-9A68-920EDC4C9FA7@azet.org>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>             
To: "Dang, Quynh (Fed)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 19:51:31 -0000

--Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed)  =
wrote:
>=20
> Hi Kenny,
>=20
> I am glad to see that you enjoyed the discussion more than what you =
planed for the time on your vacation.  We love crypto and the IETF!
>=20
> From: "Paterson, Kenny" 
> Date: Wednesday, February 15, 2017 at 8:46 AM
> To: 'Quynh' 
> Cc: Atul Luykx , Yoav Nir =
, IRTF CFRG , "tls@ietf.org" =

> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs =
(#765/#769)
>=20
>> Hi Quynh,
>>=20
>> I'm meant to be on vacation, but I'm finding this on-going discussion =
fascinating, so I'm chipping in again.
>>=20
>> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)  =
wrote:
>>=20
>>> Hi Atul,
>>>=20
>>> I hope you had a happy Valentine!
>>>=20
>>> From: Atul Luykx 
>>> Date: Tuesday, February 14, 2017 at 4:52 PM
>>> To: Yoav Nir 
>>> Cc: 'Quynh' , IRTF CFRG , =
"tls@ietf.org" 
>>> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" =
PRs (#765/#769)
>>>=20
>>>>> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
>>>> Because he wants to lower the security level.
>>>=20
>>> I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are =
practically the same: they are practically zero.
>>=20
>> I'm not clear what you mean by "practically" here.
>=20
> As far as I know, such chance has not happened in history for any =
targeted search where the chance for hitting the target is 1 in 2^32.
>=20
>> They're clearly not the same as real numbers. And if we are being =
conservative about security, then the extremes in your list are a long =
way apart.
>>=20
>>> And, 2^-32 is an absolute chance in this case meaning that all =
attackers can=92t improve their chance: no matter how much computational =
power the attacker has.
>>=20
>> A sufficiently powerful adversary could carry out an exhaustive key =
search for GCM's underlying AES key. So I'm not sure what you're =
claiming here when you speak of "absolute chance".
>=20
> I described my point not in a best way, sorry. For key recovery, if an =
attacker can do 2^96 AES operations, his chance of finding the key is =
2^-32, but this chance will get improved if the attacker does more =
computation. On the contrary, the chance for the distinguishing attack =
won=92t change with the proposed data limit.

Maybe I don't comprehend what you're trying to propose - but why change =
this paragraph then?

Coming from an HPC background: It seems to be that with frequent =
rekeying the chance of successfully performing an exhaustive search =
attack is -- even for the most advanced adversary -- so slim that we do =
not need to worry about that. In reality this is a cost-for-computation =
tradeoff that no one is going to invest in if there're more practical =
ways to attack (e.g. HUMINT/bad OPSEC, steal a private key, intrude a =
given network etc.) given the resources and thus money/power needed.

>=20
>>=20
>>> I don=92t understand why the number 2^-60 is your special chosen =
number for this ?
>>=20
>> This is a bit subtle, but I'll try to explain in simple terms.
>>=20
>> We can conveniently prove a bound of about this size (actually 2^-57) =
for INT-CTXT for a wide range of parameters covering both TLS and DTLS =
(where many verification failures may be permitted). Then, since we're =
ultimately interested in AE security, we would like to (roughly) match =
this for IND-CPA security, to get as good a bound as we can for AE =
security (the security bounds for the two notions sum to give an AE =
security bound - see page 2 of the "AE bounds" note).
>>=20
>> In view of the INT-CTXT bound there's no point pushing the IND-CPA =
bound much lower than 2^-60 if the ultimate target is AE security. It =
just hurts the data limits more without significantly improving AE =
security.
>=20
> I just checked the paper. There is a small error I think. AES-GCM in =
TLS 1.3 is a prf. Under a given key, every input block or just one =
repeated block 2^35 times, their ciphertext blocks are 2^35 random =
128-bit blocks assuming the key has 128 bits of entropy. If there is a =
collision among the ciphertext blocks, it does not mean anything because =
it does not say anything about the plaintext blocks.
>=20
>=20
>>=20
>> Finally, 2^-60 is not *our* special chosen number. We wrote a note =
that contained a table of values, and it's worth noting that we did not =
make a specific recommendation in our note for which row of the table to =
select.
>>=20
>> (Naturally, though, we'd like security to be as high as possible =
without making rekeying a frequent event. It's a continuing surprise to =
me that you are pushing for an option that actually reduces security =
when achieving higher security does not seem to cause any problems for =
implementors.)
>=20
> I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 =
are all safe choices. If someone wants to rekey sooner (or often) for =
operational reason or any other reason, that would be just fine. I just =
hope that we don=92t have text which might imply that 2^-32 is not a =
safe choice.  In our guidelines, we basically indicate that 2^-32 or =
below is safe.

...

>=20
>=20
>>=20
>>> In your =93theory=94, 2^-112 would be in =93higher=94 security than =
2^-60.
>>=20
>> It certainly would, if it were achievable (which it is not for GCM =
without putting some quite extreme limits on data per key).
>>=20
>> Cheers,
>>=20
>> Kenny
>=20
> I am going to propose another option and I hope that you and all other =
people will be happy with.

I'd strongly suggest that any changes made to this text are as clear as =
possible to non-mathematicians/cryptographers. Years of dealing with TLS =
implementation and protocol vulnerabilities tell us that uncertain =
wording and missing, clear, explanation for certain choices in standards =
have caused real-world security problems. It seems to me that the =
general consensus is that option A is preferable anyhow.

Aaron


--Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

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

iQIcBAEBCgAGBQJYpgK6AAoJEOTbZJL9ubXVsJEQANBLO8lUu6DeslzpstBMWPvF
hywZbI38GH+4tYNZxJsH6vhAgAQawaaCt7ex7MpiPSA1hezT+rPZIJbDZt+K2kKx
M5g9nsqJoXzbLKxgbs/HERGU+3RSuC55XZhT6W9D5AuBFtuieLqPkQwadGvJbWyv
ITlFKPQu8ocMaTXWhjiUZ2fQlX3IMw7xkxPgO4tI7btyRr2D/jCmFHLckxLlp+If
A6omkKmTcDPyWaMymXLEYFC5RA1/dTazzEJiqxTlfHwllCDmOWfCOcMJKtgizY92
/UznpTtAnIoqqCL7oJ24aWbqjCUtTjLP5Ovd4yzwtR9f46nvhufJQ3vIMly/LgHi
IN6RkJn22nTIzN0u0RJq+sibKIhBa1X2zEka8Zdav+s0nF6E7LQc3agtxW77VKl3
U0OS+ybJ+SQu+dFth2l5VgUUqKxidksFpaxXY3AK/YRSLy4XnIVR7gx8Cv8e0cmG
Xqft4+6Sl/T9UTTHhPtFoU9dk8yH7ISfyd/8X6w9r7mYHIQxWeDrhTmu3ZF2LiNn
7VVlhmKCtXDU9OtQB5B4YYTQLyFMF8bUR87CHNn7/UZtVs7ZJkk7gs0Oy9HbqZST
SrM1+ocrhC+7BgrHZCe/YiZgRT5Xrsx8Ns9xHygpKdptx41ozReSCjpX9tE6DfRN
i+WAEa9q5j4F5TghjJH0
=nMe+
-----END PGP SIGNATURE-----

--Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9--


From nobody Fri Feb 17 08:58: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 91E2112951D for ; Fri, 17 Feb 2017 08:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCU43w4nxJqW for ; Fri, 17 Feb 2017 08:58:35 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D673B1294FB for ; Fri, 17 Feb 2017 08:58:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 588EBBEB5 for ; Fri, 17 Feb 2017 16:58:32 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23xZ1LOSwXhw for ; Fri, 17 Feb 2017 16:58:32 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BD3F8BE77 for ; Fri, 17 Feb 2017 16:58:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487350712; bh=HLjJgWOJ06NRKC8H62PMRdYgbitW3Rwyw2ykyZGrq3w=; h=To:From:Subject:Date:From; b=c0sbZtvf7tmbiMImaHvAtHAreSeTFAC/seiLTvt8kvWgT7ehjJ35cPipf482ewMba S7F58kLrSIUGMPyvIt3rMe/0pB7k9OjLyEspOhrksuuYwuAcEp7sm+okMl0cpYZv/f U5AXo7vgZhmh0+lQURXMtdxMXyNFVV0bbjKam2T0=
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Fri, 17 Feb 2017 16:58:31 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VG4EdKDE66wp7Sdi2RP23WCmCAO6rNV7h"
Archived-At: 
Subject: [TLS] AD review of draft-ietf-tls-rfc4492bis-12.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 16:58:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--VG4EdKDE66wp7Sdi2RP23WCmCAO6rNV7h
Content-Type: multipart/mixed; boundary="Wx5QckcxOmCAufKVUACjt3rTHJJVn963X";
 protected-headers="v1"
From: Stephen Farrell 
To: "tls@ietf.org" 
Message-ID: 
Subject: AD review of draft-ietf-tls-rfc4492bis-12.txt

--Wx5QckcxOmCAufKVUACjt3rTHJJVn963X
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

I've had a read of this and asked for IETF LC to start.

My comments below can be handled with any other IETF LC
comments.

Thanks,
S.

- Bits of this are fairly complex reading, given that ECC
isn't trivial and nor are the changes nor how they were done
to keep some things more or less backwards compatible. It'd
help I think if we could say something more about
implementation status in the shepherd write-up.

- abstract: doesn't this need to say that this obsoletes
RFC4492 in the abstract text. (Yes, PITA formalities, I
know:-)

- 5.1.1: "Note that other specifications have since added
other values to this enumeration." Could/should we reference
those others? I don't care, but someone will ask and it'd be
good to have the answer in the archive if it's "no, and
here's why..."

- 5.1.1: Is this text still correct: "secp256r1, etc:
Indicates support of the corresponding named curve or class
of explicitly defined curves." Do we need to say there that
we're ditching explicitly defined curves?

- 5.2: Is this still right, given the deprecation of
compressed points earlier? " Note that the server may include
items that were not found in the client's list (e.g., the
server may prefer to receive points in compressed format even
when a client cannot parse this format: the same client may
nevertheless be capable of outputting points in compressed
format)."

- 5.3: Doesn't this need a change: "...unless the client has
indicated support for explicit curves of the appropriate
type"? Maybe more change is needed in that para as well?

- section 6: Do we still need the *_NULL_* suites?

- Just checking, I assume this is down to editing history
but what happened to TBD1 and TBD2?


--Wx5QckcxOmCAufKVUACjt3rTHJJVn963X--

--VG4EdKDE66wp7Sdi2RP23WCmCAO6rNV7h
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iQEcBAEBCAAGBQJYpyu3AAoJEC88hzaAX42ikiEIAJ6nG9ilQvMItu7UCaFfuDtJ
1tmd1pSDqiDSKNqCBrGgTC7VR5xwkF4Wml09kTAInPOHMAs/4WOzgOg7btD0dwgC
MWZTE6GQg+L9zqVF/oVsgPS3NnjVkgOU8OP6PefxmEyOqe9aIBjyT1iXWyvqm4bc
NINkcNI5WCwqZEwcl5TusOdOUUJDxpU8HtBEJ+qFjOYvOjLRQoYQDXzkBb+E6PWA
CdD96g2w1cnRZU/t0LG0O3/i3iSncVsc0oIG/WB1idAMquXwQyrIEQsjGXN4N5yk
9Hlyst6DhwKC9fkSZk+qQ17vmMfG8OccuxIQEA23ZB+2O5aRJt2+QF6EyOrt7rM=
=YHeA
-----END PGP SIGNATURE-----

--VG4EdKDE66wp7Sdi2RP23WCmCAO6rNV7h--


From nobody Fri Feb 17 09:00: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 D7D47129488 for ; Fri, 17 Feb 2017 09:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2rXVwLpT8Dj for ; Fri, 17 Feb 2017 09:00:32 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642C31289C4 for ; Fri, 17 Feb 2017 09:00:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A4934BEB5 for ; Fri, 17 Feb 2017 17:00:30 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypFwVUipg5n6 for ; Fri, 17 Feb 2017 17:00:30 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1A788BE77 for ; Fri, 17 Feb 2017 17:00:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487350830; bh=4WJpWy2cMcShSB+jnTkiRdP5wCTGPOkil+RbnvnHC4Y=; h=Subject:References:To:From:Date:In-Reply-To:From; b=G7o9ID9qQ1ct7Sw8wRY3i2/9D2a6CaELKQyul2x6DB230JMAYJNA20uvO18UAMYRU SN0Hj83wgErvAbau0ifFxjHSqQRzf7y6Uiaknp0VOQEprqfjCBTAKdco0cj51e/9YO yic6gtCtdA9JimWEtB77CfZkCxTT44s4XyMPC12Q=
References: <148735040735.19992.5678820892795925914.idtracker@ietfa.amsl.com>
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Forwarded-Message-Id: <148735040735.19992.5678820892795925914.idtracker@ietfa.amsl.com>
Message-ID: 
Date: Fri, 17 Feb 2017 17:00:29 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <148735040735.19992.5678820892795925914.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="THkvsslCVufFHMvMaBbaFSii5AQr3jFka"
Archived-At: 
Subject: [TLS] Fwd: Last Call: Uplifting RFC5289 from informational to proposed standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 17:00:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--THkvsslCVufFHMvMaBbaFSii5AQr3jFka
Content-Type: multipart/mixed; boundary="SmV5lvKTebumIU7L4Txipv9jRhqkiUP0t";
 protected-headers="v1"
From: Stephen Farrell 
To: "tls@ietf.org" 
Message-ID: 
Subject: Fwd: Last Call: Uplifting RFC5289 from informational to proposed
 standard
References: <148735040735.19992.5678820892795925914.idtracker@ietfa.amsl.com>
In-Reply-To: <148735040735.19992.5678820892795925914.idtracker@ietfa.amsl.com>

--SmV5lvKTebumIU7L4Txipv9jRhqkiUP0t
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


FYI,
S.

-------- Forwarded Message --------
Subject: Last Call: Uplifting RFC5289 from informational to proposed
standard
Date: Fri, 17 Feb 2017 08:53:27 -0800
From: The IESG 
Reply-To: ietf@ietf.org
To: IETF-Announce 


The IESG has received a request from an individual participant to make
the following status changes:

- RFC5289 from Informational to Proposed Standard
    (TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
Counter Mode (GCM))

The supporting document for this request can be found here:

https://datatracker.ietf.org/doc/status-change-uplifting-rfc5289-to-ps/

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-03-17. 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.

The affected document can be obtained via
https://datatracker.ietf.org/doc/rfc5289/

IESG discussion of this request can be tracked via
https://datatracker.ietf.org/doc/status-change-uplifting-rfc5289-to-ps/ba=
llot/





--SmV5lvKTebumIU7L4Txipv9jRhqkiUP0t--

--THkvsslCVufFHMvMaBbaFSii5AQr3jFka
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iQEcBAEBCAAGBQJYpywuAAoJEC88hzaAX42iWK4H/jgethGELc+T4DxdjbJswl/E
MQNAxDj6cM+1Hiy00PvGXMPPf1BDLXVcW8M+Jz2pqse9GYwtITNFsW2L0pS+bh0a
JuhFzgwaa+fR7guaVEJa/SgQpSNdw2oWM66v/8HDLYqits66rNeO9tGLkjKZ+33N
HDipsov58nQrr6LBc3kbdCR8WvcTElCJqwK0n9qx3cJgg5XagEjofDCO7KnFy/8z
6qP1o0uY8FcSgiSw/2D1dUZ3/jW8iFT2PFD6BUUA1qJKMx7Tv+9iOv+qn+3xfRTk
l48qy4qaoTOEfBoi7LHxVSDBSMqAE9JwCr2f44pwKkQo/eSLw3+fJCx3DU+YsI0=
=wXaN
-----END PGP SIGNATURE-----

--THkvsslCVufFHMvMaBbaFSii5AQr3jFka--


From nobody Fri Feb 17 09:08:26 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 F268C1294C1; Fri, 17 Feb 2017 09:08:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <148735130097.19968.11100505451210007707.idtracker@ietfa.amsl.com>
Date: Fri, 17 Feb 2017 09:08:20 -0800
Archived-At: 
Cc: tls-chairs@ietf.org, tls@ietf.org, draft-ietf-tls-rfc4492bis@ietf.org
Subject: [TLS] Last Call:  (Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: ietf@ietf.org
List-Id: "This is the mailing list 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, 17 Feb 2017 17:08:21 -0000

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
   Security (TLS) Versions 1.2 and Earlier'
   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-03-03. 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 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) (Informational - IRTF Stream)
    rfc7748: Elliptic Curves for Security (Informational - IRTF Stream)
These are already be listed in the acceptable Downref Registry.



From nobody Fri Feb 17 14:44: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 38D5C129C40 for ; Fri, 17 Feb 2017 14:44:46 -0800 (PST)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=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 RcnluAFmSfCj for ; Fri, 17 Feb 2017 14:44:45 -0800 (PST)
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 2E216129C4C for ; Fri, 17 Feb 2017 14:44:44 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id s186so57266913qkb.1 for ; Fri, 17 Feb 2017 14:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=uRMixgChiuYJNDaWNCktOqQ9/zKU5z5aYnTMLdQ1a6M=; b=k1FzLsTSsxlRkHStCW5M253ln6DZ0iSv46Uwvnq1A6FjH0JLWXK5o7dWwfPYyCz0V8 JYaqki31OD8fXVgTyVVKkiipoOSGCjsmm3DlZBdmbOuWWtJhGJ9Y6RZtqzYVoGhfCpBx hlsNZdCqQSoGH3bpa+aLk18wi4uRMjLge1pJQ=
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=uRMixgChiuYJNDaWNCktOqQ9/zKU5z5aYnTMLdQ1a6M=; b=iRP1kmx/UDjKwXwR0Q4MsgjR2XGmAlqwChDSKEQnSc3J5BE6txMBb+1HONG/xSBsRD kBm0l8b5hMSuq+cMobW4XSIv18/Wjv3cvEtQiq2Ck1Pt+XIpRhzKyJVn30FoKOjRY/g2 uqip6XlU42vWs9wWbpSw5XZVokYN3iD2fsgzd13KBvdiGHp2l2mfeevFjEVwfiv+d7jk R5EvHoRBgIDZCaravxkfO1zf3Tg2A76cNCe2/MEUSUGKdx0OpkPLJYyV4i6oL484D24N RPRM3DqXLx61MCGlUPZZblnexN/4NhYoaEWeNFF7yslSEUjH/Q+vDwpq9vkVFCfUrzV/ f1HA==
X-Gm-Message-State: AMke39mJMbaaNcUWXjjMCkBoVv1VwXhaPIpe6FBiasQh3iHBzg6n5z/mI1EO0/M677eIPTHzd2iaNPP98ePwOJty
X-Received: by 10.55.22.74 with SMTP id g71mr9597212qkh.40.1487371483044; Fri, 17 Feb 2017 14:44:43 -0800 (PST)
MIME-Version: 1.0
From: David Benjamin 
Date: Fri, 17 Feb 2017 22:44:32 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11474584e5c00c0548c1a874
Archived-At: 
Subject: [TLS] ecdh_ prefix in draft-ietf-tls-rfc4492bis-12
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 22:44:46 -0000

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

This is a minor comment and purely aesthetic thing. Apologies for the
lateness in noticing. Hopefully it's not too late:

In TLS 1.3, we dropped the "ecdh_" prefix on ecdh_x25519 and ecdh_x448 when
we split signatures from NamedCurve/Group. The documents should probably
match in naming one way or another. I think plain x25519 and x448 is
tidier. X25519 already denotes the ECDH function, as opposed to curve25519
which is the curve.

David

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


This is a minor comment and purely=
 aesthetic thing. Apologies for the lateness in noticing. Hopefully it'=
s not too late:

In TLS 1.3, we dropped the "ecdh_" pref=
ix on ecdh_x25519 and ecdh_x448 when we split signatures from NamedCurve/Gr=
oup. The documents should probably match in naming one way or another. I th=
ink plain x25519 and x448 is tidier. X25519 already denotes the ECDH functi=
on, as opposed to curve25519 which is the curve.

Davi=
d


--001a11474584e5c00c0548c1a874--


From nobody Fri Feb 17 18:31: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 9929B1295F7 for ; Fri, 17 Feb 2017 18:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 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, T_HK_NAME_DR=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 nYi3m_oNWBv8 for ; Fri, 17 Feb 2017 18:31:30 -0800 (PST)
Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by ietfa.amsl.com (Postfix) with ESMTP id 74279129449 for ; Fri, 17 Feb 2017 18:31:29 -0800 (PST)
Received: from host86-133-224-58.range86-133.btcentralplus.com ([86.133.224.58]:15148 helo=[192.168.1.64]) by relay00.mail.eu.clara.net (relay.clara.net [81.171.239.30]:10465) with esmtpa (authdaemon_plain:drh) id 1ceuo1-0007wo-1U  for tls@ietf.org (return-path ); Sat, 18 Feb 2017 02:31:26 +0000
To: tls@ietf.org
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi>
From: Dr Stephen Henson 
Message-ID: <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk>
Date: Sat, 18 Feb 2017 02:31:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 02:31:32 -0000

On 08/02/2017 21:17, Ilari Liusvaara wrote:
> On Wed, Feb 08, 2017 at 07:34:16PM +0000, Timothy Jackson wrote:
>> I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with
>> RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS
>> apply only to the signatures that can be used for signing handshakes or
>> does it apply to the entire certificate chain as well? I ask because while
>> I think the latter may have been the intent I have not found anything that
>> indicates the former is not actually what the RFCs require.
>>
>> The relevant section of RFC4056 reads:
>>
>> 7.4.2 Server Certificate
>> …
>> Note that there are certificates that use algorithms and/or algorithm
>>    combinations that cannot be currently used with TLS.  For example, a
>>    certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
>>    SubjectPublicKeyInfo) cannot be used because TLS defines no
>>    corresponding signature algorithm.
>>
>> I don’t see anything here that restricts which signatures can be used on
>> the certificates themselves. Is that accurate? If so, then I think the
>> relevant restrictions are not in TLS RFCs at all, but rather are in RFCs
>> such as 4055, 4056, and 5756. These RFCs allow RSASSA-PSS. Is it
>> therefore permissible to have a CA that is signed with RSASSA-PSS with
>> TLS 1.0, 1.1, or 1.2.
>>
>> Is this what was intended?
> 
> My interpretation:
> 
> If client includes RSA-PSS codepoints in its signature_algorithms,
> then:
> 
> - The server handshake signature MAY be signed using RSA-PSS in TLS
>   1.2 or later. Yes, 1.2, not 1.3.
> - The certificate chain MAY contain certificates signed with RSA-PSS
>   in any TLS version (however, the salt length must match hash length).
> 
> In converse case:
> 
> - The server MUST NOT sign handshake using RSA-PSS in any TLS
>   version
> - The certificate chain SHOULD NOT contain certificates signed with
>   RSA-PSS in any TLS version.
> 

Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
certificates too?

For example could a TLS 1.2 server legally present a certificate containing an
RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
a certificate contain an RSASSA-PSS key?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.


From nobody Sat Feb 18 02:01: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 3AF421293E4 for ; Sat, 18 Feb 2017 02:01:46 -0800 (PST)
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 jlG_89hxw41m for ; Sat, 18 Feb 2017 02:01:45 -0800 (PST)
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 D6976129405 for ; Sat, 18 Feb 2017 02:01:44 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id u25so63345300qki.2 for ; Sat, 18 Feb 2017 02:01:44 -0800 (PST)
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=bCbf+bMH3PaxlF9EZxnwB0XLL7ezRAn6aPppVqS1Ts8=; b=kLXj8Zrwmpfy7NwQcLTIDDck2GH+T55ysmRR2fdKbqJmtubTo3wbyuiRwz7eN4Qk07 Nm0YaWuXTZETNTHwEFVuAIoZnYO4ONi8bfxExyhzkrIlApmokYNNaeURzMdrTPZQ9rYB bjKMuLuXDSF1YFp9qri3xjHri0GqneNsavHXsyG8RXlEmUpy4V9jomGwHlmD+03k9Mht CxqiIPdjteSDhZiqpEBvAtXryhUiVhzUpEZEWqJB5ALOZTXpN7qrAIsuhmMGohYiaSwy QRP0Z/wGmIXXo30FQnnWoyZd8cL5EU4HSxTzybgAlGHNTLQG8KmhzcHoVrBKjtdwN9iR Oqug==
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=bCbf+bMH3PaxlF9EZxnwB0XLL7ezRAn6aPppVqS1Ts8=; b=NP4S5yJ2+NQPHRo6ruW13wI4iUqK/fAWO3LHKUWws9kW2o3OHVRvx/ihrJ5vC+J/N7 xevq8cA6Ctki0V88mQlMpSMSQObzOMqe0RHSGLt2gMnd15cc28pim5wDvjhGo6xc/S0B KMzW3YHWXwZp5j6PK0Z44RP3vdqa9epMpQJg0cNfy4cH874loJmhyqAdNlagTgOl1SM2 iMWe1VYrvD6Z5N3a0S48hc/yIuiBaoN5T/0RAcyE1giYotOm62+t2hotS/TgUmTBxT8E +Oz36yyv4c8Wb4J25NhoPZ+NuYzc83vbkwSI7WH4+vjImbHKrhclGK2bfr+Z5EHsCwpF NoOg==
X-Gm-Message-State: AMke39kFY+JZ9vNdLu77vL1hUTJ5jN2iXrZ9zoTBax5USq6dx9NkupqeJimLp+4n2KrKFOFfwK0C5lrJUIdF4w==
X-Received: by 10.233.235.66 with SMTP id b63mr12273705qkg.144.1487412104029;  Sat, 18 Feb 2017 02:01:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sat, 18 Feb 2017 02:01:43 -0800 (PST)
In-Reply-To: <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk>
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk>
From: Martin Thomson 
Date: Sat, 18 Feb 2017 21:01:43 +1100
Message-ID: 
To: Dr Stephen Henson 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 10:01:46 -0000

On 18 February 2017 at 13:31, Dr Stephen Henson
 wrote:
> could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
> a certificate contain an RSASSA-PSS key?

NSS, when configured to do so, will do just that.  I wouldn't
recommend it right now, but it is legal.  Actually, if you offer
support for validating PSS and end up negotiating 1.2, then you should
be prepared to receive PSS signatures.  It's a wee gotcha in the 1.3
spec.


From nobody Sat Feb 18 05:01: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 A76931294EE for ; Sat, 18 Feb 2017 05:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=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 fl2LmqNDIR-M for ; Sat, 18 Feb 2017 05:01:45 -0800 (PST)
Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id 693FD1294E1 for ; Sat, 18 Feb 2017 05:01:45 -0800 (PST)
Received: from host86-133-224-58.range86-133.btcentralplus.com ([86.133.224.58]:51482 helo=[192.168.1.64]) by relay03.mail.eu.clara.net (relay.clara.net [81.171.239.33]:10465) with esmtpa (authdaemon_plain:drh) id 1cf4dv-0001kI-BD  (return-path ); Sat, 18 Feb 2017 13:01:40 +0000
To: Martin Thomson 
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> 
From: Dr Stephen Henson 
Message-ID: <14d2a8f5-8c63-853e-b883-b52c47a1fd5c@drh-consultancy.co.uk>
Date: Sat, 18 Feb 2017 13:01:36 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 13:01:47 -0000

On 18/02/2017 10:01, Martin Thomson wrote:
> On 18 February 2017 at 13:31, Dr Stephen Henson
>  wrote:
>> could a TLS 1.2 server legally present a certificate containing an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
>> a certificate contain an RSASSA-PSS key?
> 
> NSS, when configured to do so, will do just that.  I wouldn't
> recommend it right now, but it is legal.  Actually, if you offer
> support for validating PSS and end up negotiating 1.2, then you should
> be prepared to receive PSS signatures.  It's a wee gotcha in the 1.3
> spec.
> 
> 

The reason I wasn't sure about this is that for TLS 1.2 the server certificate
key algorithm is associated with a ciphersuite. So for example the "RSA" in
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 would previously refer to the OID
rsaEncryption (1 2 840 113549 1 1 1) if PSS is included in signature algorithms
it could also refer to id-RSASSA-PSS.

Similarly for client certificates there is the ClientCertificateType rsa_sign
though RFC5246 just says "a certificate containing an RSA key".

I'd be curious to know what other implementations do. I suggest we make this
possibility clear in the spec, along with the salt length in certificate
signatures previously discussed. Otherwise it isn't inconceivable that some will
reject id-RSASSA-PSS keys in end entity certificates in TLS 1.2.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.


From nobody Sat Feb 18 08:26: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 3BAAA12952F for ; Sat, 18 Feb 2017 08:26:07 -0800 (PST)
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 sOwpWew88qex for ; Sat, 18 Feb 2017 08:26:05 -0800 (PST)
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 9AE8A12946F for ; Sat, 18 Feb 2017 08:26:05 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BD4DC7A32F1; Sat, 18 Feb 2017 16:26:04 +0000 (UTC)
Date: Sat, 18 Feb 2017 16:26:04 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20170218162604.GB13889@mournblade.imrryr.org>
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list 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, 18 Feb 2017 16:26:07 -0000

On Sat, Feb 18, 2017 at 02:31:19AM +0000, Dr Stephen Henson wrote:

> > If client includes RSA-PSS codepoints in its signature_algorithms,
> > then:
> > 
> > - The server handshake signature MAY be signed using RSA-PSS in TLS
> >   1.2 or later. Yes, 1.2, not 1.3.
> > - The certificate chain MAY contain certificates signed with RSA-PSS
> >   in any TLS version (however, the salt length must match hash length).
> > 
> > In converse case:
> > 
> > - The server MUST NOT sign handshake using RSA-PSS in any TLS
> >   version
> > - The certificate chain SHOULD NOT contain certificates signed with
> >   RSA-PSS in any TLS version.
> > 
> 
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
> 
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
> a certificate contain an RSASSA-PSS key?

Isn't an RSA public key independent of the signature algorithms it
might be employed with?  If the EE cert has an RSA key, and RSA-PSS
is not negotiated, can't the peer (client or server) just sign with
PKCS#1?  So the same EE cert would then be valid for either PSS or
PKCS#1?  Or have I missed the memo on how PSS works with EE certs?

As for the signatures in the X.509 chain itself, the "SHOULD NOT"
above just means that we have a non-PSS chain to offer, then we
offer that, but if PSS is all we have, then present that chain.

Fundamentally, X.509 verification lies outside of TLS, and it is
not the job of TLS to second-guess the X.509 stacks on either end.
The peers can provide hints about preferred/supported algorithms,
but in the case of X.509 these are not hard constraints.  The X.509
algorithm hints in TLS are about increasing the chances of
interoperability, and not excluding unadvertised codepoints.

-- 
	Viktor.


From nobody Sat Feb 18 10:22: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 30D37129598 for ; Sat, 18 Feb 2017 10:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=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 W3gUSJ2AqprW for ; Sat, 18 Feb 2017 10:22:31 -0800 (PST)
Received: from claranet-outbound-smtp09.uk.clara.net (claranet-outbound-smtp09.uk.clara.net [195.8.89.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C0129571 for ; Sat, 18 Feb 2017 10:22:30 -0800 (PST)
Received: from host86-133-224-58.range86-133.btcentralplus.com ([86.133.224.58]:10022 helo=[192.168.1.64]) by relay09.mail.eu.clara.net (relay.clara.net [81.171.239.39]:10465) with esmtpa (authdaemon_plain:drh) id 1cf9eM-0003Tq-T7  for tls@ietf.org (return-path ); Sat, 18 Feb 2017 18:22:27 +0000
To: tls@ietf.org
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> <20170218162604.GB13889@mournblade.imrryr.org>
From: Dr Stephen Henson 
Message-ID: <81fccbab-f1e2-3c13-de28-192317503f9f@drh-consultancy.co.uk>
Date: Sat, 18 Feb 2017 18:22:23 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170218162604.GB13889@mournblade.imrryr.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 18:22:33 -0000

On 18/02/2017 16:26, Viktor Dukhovni wrote:
> On Sat, Feb 18, 2017 at 02:31:19AM +0000, Dr Stephen Henson wrote:
> 
>>
>> For example could a TLS 1.2 server legally present a certificate containing an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
>> a certificate contain an RSASSA-PSS key?
> 
> Isn't an RSA public key independent of the signature algorithms it
> might be employed with?  If the EE cert has an RSA key, and RSA-PSS
> is not negotiated, can't the peer (client or server) just sign with
> PKCS#1?  So the same EE cert would then be valid for either PSS or
> PKCS#1?  Or have I missed the memo on how PSS works with EE certs?
> 

The most commonly deployed certificates containing RSA keys use rsaEncryption (1
2 840 113549 1 1 1). For those the key can be used for PKCS#1 and PSS.

There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With that
OID the key can only be legally used for PSS (with possible additional
restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable for
TLS before 1.3 as the signature was always PKCS#1. As a result very few such
certificates have been seen in the wild, but (as mentioned in other threads)
they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory algorithm).

My question was whether this implied TLS 1.2 implementations (that include PSS
in the signature algorithms extension) must support them too.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.


From nobody Sat Feb 18 11:25: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 02C051294BF for ; Sat, 18 Feb 2017 11:25:25 -0800 (PST)
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 StC7Ifcp7C3r for ; Sat, 18 Feb 2017 11:25:23 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4F129415 for ; Sat, 18 Feb 2017 11:25:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id EEBE51D75E; Sat, 18 Feb 2017 21:25:20 +0200 (EET)
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 euIKf6bujH1o; Sat, 18 Feb 2017 21:25:20 +0200 (EET)
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 96DF728A; Sat, 18 Feb 2017 21:25:20 +0200 (EET)
Date: Sat, 18 Feb 2017 21:25:16 +0200
From: Ilari Liusvaara 
To: Dr Stephen Henson 
Message-ID: <20170218192516.GA11531@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> <20170218162604.GB13889@mournblade.imrryr.org> <81fccbab-f1e2-3c13-de28-192317503f9f@drh-consultancy.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <81fccbab-f1e2-3c13-de28-192317503f9f@drh-consultancy.co.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 19:25:25 -0000

On Sat, Feb 18, 2017 at 06:22:23PM +0000, Dr Stephen Henson wrote:
> On 18/02/2017 16:26, Viktor Dukhovni wrote:
> > On Sat, Feb 18, 2017 at 02:31:19AM +0000, Dr Stephen Henson wrote:
> > 
> >>
> >> For example could a TLS 1.2 server legally present a certificate containing an
> >> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
> >> a certificate contain an RSASSA-PSS key?
> > 
> > Isn't an RSA public key independent of the signature algorithms it
> > might be employed with?  If the EE cert has an RSA key, and RSA-PSS
> > is not negotiated, can't the peer (client or server) just sign with
> > PKCS#1?  So the same EE cert would then be valid for either PSS or
> > PKCS#1?  Or have I missed the memo on how PSS works with EE certs?
> > 
> 
> The most commonly deployed certificates containing RSA keys use rsaEncryption (1
> 2 840 113549 1 1 1). For those the key can be used for PKCS#1 and PSS.
> 
> There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With that
> OID the key can only be legally used for PSS (with possible additional
> restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable for
> TLS before 1.3 as the signature was always PKCS#1. As a result very few such
> certificates have been seen in the wild, but (as mentioned in other threads)
> they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory algorithm).
> 
> My question was whether this implied TLS 1.2 implementations (that include PSS
> in the signature algorithms extension) must support them too.

The behaviour of implementation I have been writing in regards to
RSA-PSS:

- Only the 3 TLS 1.3 variants of RSA-PSS are supported. Including in
  1.2 and certificates.
- When using RSA-PSS for SKE signature, the ciphersuite signature
  algorithm is set to RSA.
- Ciphersuite signature algorithm is ignored on receipt.
- RSA-PSS SKE signatures are recognized from hash=8, algoritm=4, 5 or
  6 in DigitallySigned algorithm. The hash is determined from the
  algorithm number.
- RSA-PSS certificate signatures are recognized by exact match to
  precomposed algorithmidentifier values.
- RsaEncryption keys can be used to validate RSA-PKCS#1 v1.5 and
  RSA-PSS signatures.
- RSA-PSS keys can be used to validate RSA-PSS only, not RSA-PKCS#1
  v1.5.
- Normally, any server RSA keys need to be RsaEncryption type, but
  it is possible to force RSA-PSS key by some tricks..
- If client indicated support for both RSA-PKCS#1 v1.5 and RSA-PSS
  and RSA key is selected, RSA-PSS is preferred.


Nearly all of this just falls from the TLS 1.3 support. The only
version-specific part is knowing to set RSA certificate algorithm if
RSA-PSS was chosen (and this is controlled by one bitmask)..


-Ilari


From nobody Sun Feb 19 14:32: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 223421295D6 for ; Sun, 19 Feb 2017 14:32:30 -0800 (PST)
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 v6H8X7as8XMv for ; Sun, 19 Feb 2017 14:32:27 -0800 (PST)
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 A93B21295C5 for ; Sun, 19 Feb 2017 14:32:27 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id k15so74765811qtg.3 for ; Sun, 19 Feb 2017 14:32:27 -0800 (PST)
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=VJa4V7U6X4YQuJ2V+KD8TXAU4mUSNizTL6yvWbqpdf0=; b=LqSCsC0ScCIiSTiBFZ+3NS5065ghkVN5SRazYxy+pJp8B2c29OLI0xfcS7hjLjjwQo 4jgJo7tq9H5lzBvGHZhH/ZJCqwEIi3FyJo6kq6N/KpJVkhw2SDaF+QkHKlIJyouk8TOh YYEPQ7R2ctEzlDgZiYlqTOFw1UCXbrXMWuDKV9QiQF6Bz6hm79hIl0xxh1/dd99KUOCY zK152y4nzhRUd9we6mWe3tejILCfbM+47nJQyalvXf3uE8pJ8iMXDiRHDrOsyToYo23C WhTSzgSHpGiH1vXOcQkd+HDkd4DUsLeHAKnFIeOx3NBhZoKoLxACIg8z6+Dzo7Dgxi4j yswQ==
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=VJa4V7U6X4YQuJ2V+KD8TXAU4mUSNizTL6yvWbqpdf0=; b=fWk9kV3Ai/WWGLgqP8QFEE0+wjkWdM/6f1tvMqPKG8L0C2qcv+m40eBebSAG0ECKTZ OnuEC4wxABkRTAI7fsBzXxSEr2EIa8kBsxZksTo8sAcAh7WjrYNanCBSJ7IAyGJj5lOG RDTOk6AmW7EB3a2wW+EEe4lXCIYBT00IDhR/rRzTmB7XXXoeyzrVrX1ZAYEX8ImRm1/q 1VyJqWN+QKvNjN0pjPHa14/IV2aWXSq+gXAaADzUipKRsUtJXYieCQTyMpmxe6rvPPe1 1P8uJ5KuFNa0+gJpAAjbBL3JmtI9gaCOFQhyElqm4Xkn6szHca3uTmkwHoo7zTHXT/J2 afiw==
X-Gm-Message-State: AMke39kZVLL2LvleEFsEQqSFiQLZGojj79yidJ97gpy6ENNF4ahQnbEycZmHA18Wu1TRwV/BjS/zEXkQIdCkAA==
X-Received: by 10.237.35.84 with SMTP id i20mr19247412qtc.247.1487543546854; Sun, 19 Feb 2017 14:32:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 19 Feb 2017 14:32:26 -0800 (PST)
In-Reply-To: <20170218192516.GA11531@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> <20170218162604.GB13889@mournblade.imrryr.org> <81fccbab-f1e2-3c13-de28-192317503f9f@drh-consultancy.co.uk> <20170218192516.GA11531@LK-Perkele-V2.elisa-laajakaista.fi>
From: Martin Thomson 
Date: Mon, 20 Feb 2017 09:32:26 +1100
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Feb 2017 22:32:30 -0000

On 19 February 2017 at 06:25, Ilari Liusvaara  wrote:
> - Only the 3 TLS 1.3 variants of RSA-PSS are supported. Including in
>   1.2 and certificates.
> - When using RSA-PSS for SKE signature, the ciphersuite signature
>   algorithm is set to RSA.
> - Ciphersuite signature algorithm is ignored on receipt.
> - RSA-PSS SKE signatures are recognized from hash=8, algoritm=4, 5 or
>   6 in DigitallySigned algorithm. The hash is determined from the
>   algorithm number.
> - RSA-PSS certificate signatures are recognized by exact match to
>   precomposed algorithmidentifier values.
> - RsaEncryption keys can be used to validate RSA-PKCS#1 v1.5 and
>   RSA-PSS signatures.
> - RSA-PSS keys can be used to validate RSA-PSS only, not RSA-PKCS#1
>   v1.5.
> - Normally, any server RSA keys need to be RsaEncryption type, but
>   it is possible to force RSA-PSS key by some tricks..
> - If client indicated support for both RSA-PKCS#1 v1.5 and RSA-PSS
>   and RSA key is selected, RSA-PSS is preferred.

NSS does all of this too.  With the only difference being in server
configuration.  Server RSA keys are used for PKCS#1 and PSS if they
are of the rsaEncryption type, and RSA-PSS keys - as determined by the
OID in the certificate SPKI - are only used for PSS.


From nobody Mon Feb 20 03:40: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 43D391299B4 for ; Mon, 20 Feb 2017 03:40:08 -0800 (PST)
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 I78on5esO726 for ; Mon, 20 Feb 2017 03:40:07 -0800 (PST)
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 38279129456 for ; Mon, 20 Feb 2017 03:40:07 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B9BD48123A; Mon, 20 Feb 2017 11:40:07 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1KBe5OB010071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Feb 2017 06:40:07 -0500
From: Hubert Kario 
To: tls@ietf.org
Date: Mon, 20 Feb 2017 12:40:00 +0100
Message-ID: <1767089.u9DR7BEaTm@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.3 (Linux/4.9.9-100.fc24.x86_64; KDE/5.29.0; x86_64; ; )
In-Reply-To: <81fccbab-f1e2-3c13-de28-192317503f9f@drh-consultancy.co.uk>
References:  <20170218162604.GB13889@mournblade.imrryr.org> <81fccbab-f1e2-3c13-de28-192317503f9f@drh-consultancy.co.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart13778529.zoVhnuToA1"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 20 Feb 2017 11:40:07 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 11:40:08 -0000

--nextPart13778529.zoVhnuToA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Saturday, 18 February 2017 18:22:23 CET Dr Stephen Henson wrote:
> On 18/02/2017 16:26, Viktor Dukhovni wrote:
> > On Sat, Feb 18, 2017 at 02:31:19AM +0000, Dr Stephen Henson wrote:
> >> For example could a TLS 1.2 server legally present a certificate
> >> containing an RSASSA-PSS key for an appropriate ciphersuite? Similarly
> >> could a client present a certificate contain an RSASSA-PSS key?
> >=20
> > Isn't an RSA public key independent of the signature algorithms it
> > might be employed with?  If the EE cert has an RSA key, and RSA-PSS
> > is not negotiated, can't the peer (client or server) just sign with
> > PKCS#1?  So the same EE cert would then be valid for either PSS or
> > PKCS#1?  Or have I missed the memo on how PSS works with EE certs?
>=20
> The most commonly deployed certificates containing RSA keys use
> rsaEncryption (1 2 840 113549 1 1 1). For those the key can be used for
> PKCS#1 and PSS.
>=20
> There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With
> that OID the key can only be legally used for PSS (with possible addition=
al
> restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable
> for TLS before 1.3 as the signature was always PKCS#1. As a result very f=
ew
> such certificates have been seen in the wild, but (as mentioned in other
> threads) they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory
> algorithm).

sorry for the slight off-topic: how can you create such certificates with=20
openssl command line util?

=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
--nextPart13778529.zoVhnuToA1
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

iQIcBAABCgAGBQJYqtWQAAoJEJKo0bgB0vX1tmUP/1hkEu7N3dv6VnfVKqzSjRV1
ZJmJmooN5AQaVQTBkB8VAq1vtZVxwXZY8G3s2ubrIjfGtO8Ncd/Bz5GRxfqXDVu3
GdLW7cWSelwSmLlqKjhAWXHgR+L1joSW3WUgUHVGd4u43hoM+sM9VCszyiPDFKj/
Tfh6CxYPiVVO2VbGzqf3wWntZamO8RV7gt1VhzUz7qm0yPVQcZewHmbM+4KPgaFs
Ar90YPtnaeLMiRwvDo7SYkpSuGKrN3+3MwCZdHySfr2vMeR4tohd9x9KRMOjxjNL
7HUagGlOTodvo4HUzAzYbfr+jOlTqAIk++xb3NsJHJ6Fkkw/29jaGKXP2mH4dq/d
vYbLX6tLG065kO2pE/geegllC+Mhig054gGAT1PN/509nyE94ee87VQS4+jLbTEr
ELjQFQreMjpXGLCFOrqvpRh8954QoUukcgw5ydfVD7cXIYOyi2ENAi99Td2itiE3
4FRERu5A2SImUwM/Nn58Xz946Xbq7tFnY5BchDvP8Q6h4acYCFzPWePnlhUpR9M6
tMPgR5877mfkpdo20dbqCZ7vWIbneO11nDZDNw7L7GqUv6bjqhpWKTClaYVOzDiR
MXHB9Ds+FY/bygKjOEW3hyADmUu5JPBKj13YcBILR7RpFVz2XYuXLn3A4KjS+95H
gqqQ+1dwayN71pVGueHh
=TGTD
-----END PGP SIGNATURE-----

--nextPart13778529.zoVhnuToA1--


From nobody Tue Feb 21 02: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 465761298B5; Tue, 21 Feb 2017 02:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 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, 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 sz0NZiZtRsWQ; Tue, 21 Feb 2017 02:04:13 -0800 (PST)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 E2B2F1298AB; Tue, 21 Feb 2017 02:04:12 -0800 (PST)
Received: by mail-it0-x236.google.com with SMTP id d9so31825138itc.0; Tue, 21 Feb 2017 02:04:12 -0800 (PST)
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=dGhzq6gcGwHTF8vvXcEPs29ex7PUOjv2Hqeh7W7Z3+s=; b=hDrWywlxmIHEsawCqU7bbcZQbzNQJMH6S9fJszbCc/npmSKuGcVaajdEoOsOgVEiE+ qR7ZR5XSnrkP8HNPs2KJ2d1nqV8jz2gy/hxc3jO49gjqW+1JVPyS84i6N9ftEwxdP9Pd 8y/ZxxuLxqNH3R0ugLkNj+ZKUzkg2tiYUhmX/YACTkRPiTaMEswiIpkwql2USVdl3awg 7JnHtn8ekhU2AmayV578jhnRsgL3xI9tZE3t1U/23hSG5HjJhTghfDmWkUiz3IwsEp9x GqWp4p7dpvIffUHK/w8YQByEfJmGCnWVz/kknCXAY4fuWdrEutt6dp4mxJSXb+bQsrti bcrQ==
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=dGhzq6gcGwHTF8vvXcEPs29ex7PUOjv2Hqeh7W7Z3+s=; b=BdAdQiVC5xguQfWX8NuWYORU1fhFqj/BMoS9pEKCArYqGw9wHAbvaZW3RA7kxDtDzM c50wZ4z3FvHr4L2Qk086+SLp0hJWx56vC67GPd4gqXVFNxP66iUP+8mZ9e/FlWdiMgI+ 6M5Kzi4cK9aZ1WPTnqWLSxQBHdrcKuZRUzSxkSrdX7lBMo7c6MVUX6TBW0Bm+qOm42bP UuedQMaLGUaJg6+S0aOgT+88RePnzbTiX6ius8LvSUW+uhZgqE8X2sDKlb3SsEezNJYj UvTLqF1ouv5lyGRuXq7FbgDZM37isqlX3px5RwqBYpnpptZdwhBOTHxGYmfVdUO57X6i dB0A==
X-Gm-Message-State: AMke39m4rGjInx3fKwBdHv6MX7uJcNz5EwqMOVnl3Qpn5vmuJG4XuDPR8mFO5tFnCsGlazhvzKNeiXC2NSiR9A==
X-Received: by 10.107.138.96 with SMTP id m93mr23326879iod.22.1487671451916; Tue, 21 Feb 2017 02:04:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.28.203 with HTTP; Tue, 21 Feb 2017 02:03:31 -0800 (PST)
From: Mohit Batra 
Date: Tue, 21 Feb 2017 15:33:31 +0530
Message-ID: 
To: tls-chairs@ietf.org
Content-Type: multipart/alternative; boundary=001a113f19e26f1e7d054907807b
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] Typo error in TLS Working Group charter
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 10:04:14 -0000

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

Hello,

I just noticed a Typo error in TLS Working Group charter at
https://datatracker.ietf.org/wg/tls/charter/

The RFC number for TLS 1.2 is mentioned as:  RFC5346

However, the correct RFC number is:  RFC5246


Request to please correct the same.

-- 
Thanks & Regards,
Mohit Batra
IETF 95/98 fellow

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


Hello,

I just noticed a=C2=A0Typo error=
 in TLS Working Group charter at =C2=A0 https://datatracker.ietf.org/wg/tls/charter/



The RFC number for TLS 1.2 is mentioned as: =C2=
=A0RFC5346

=

However, the correct RFC number is:=C2=A0=
=C2=A0RFC5246


Request to pl=
ease correct the same.

-- 
Thanks & Regards,
Mohit Batra
IETF 95/98 fellow

<=
/div>



--001a113f19e26f1e7d054907807b--


From nobody Tue Feb 21 10:22: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 A98B51294B4 for ; Tue, 21 Feb 2017 10:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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, SPF_PASS=-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 fcQtCZQNrpZe for ; Tue, 21 Feb 2017 10:22:38 -0800 (PST)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 71821129543 for ; Tue, 21 Feb 2017 10:22:38 -0800 (PST)
Received: by mail-oi0-x232.google.com with SMTP id 2so32814587oif.0 for ; Tue, 21 Feb 2017 10:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=XiuuT8c6FLe46Ff5/O8693P1hqDjYMX27SjnwHXDnJU=; b=CUr13evtTiLx3ytHHbCBNf4ASBep8PxC35gcgKmMMkioynHDmWnoOkVqZhui/0Z7Ie kHDczXnWGi+p+h7LquXcJwSyRhesJT+JeQmXYVSvEWbDxXcRSDLD+Ki9ZHmPCqA/Txor M6WkrI3wLrGxX32qmD17huRvMGsoaPzmPwyZLrDPV1qlg3h4zbailYGnAQTkFElZcmFf QaEF1qpGHN1qJtgabhFscoZdYFMrc7g2swtvGLfI4dEHocQpqnwS2yzR7DgJxFJCVZ3j fcdcut9siJeLDms5/74nHH+CfqR4ZlymdSledukeFWeM9mRv3HDU8ic8AQzvvkGqKfw7 soqw==
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=XiuuT8c6FLe46Ff5/O8693P1hqDjYMX27SjnwHXDnJU=; b=V1lvVNtN/1sPIcSD2D2JgDKpYSxymC7knHYweU5DTReJIw2KtkSsKIBzw90yQsuVBH D+T4BG628Es1Imqz6+Pn1S6Ql6tciz78GwMgs1Ft8fhjyQ/XzuzqBXIY+zmVVn+HzMkS F8AtTX6I0ICa8ZZvJsYYxZ+VH0rvcDw8DbknIlfJlO8SG7c0eC7yJMhdd/ESwI2D0s2z gW2wIEmxPPcc+ngMoniQnDbCWEA8tU8zrrB3g3JbSxb/BwS83+GGgsZkTm6ddiJ/mpvS KPnnnWEKG8Scc13mcXqGxVPKSwImps/TTGHO9P7uxAObAuY+ijRltpvpDQgrSGHsCUD1 Lh4Q==
X-Gm-Message-State: AMke39lbUqpP45WHfAGVHnF3iM+Bj8NDF45IXRn4170INCXMkWWPAgd3WNfATkeA4pKX0wJSI3PoNeYQB5cyvQ==
X-Received: by 10.202.242.8 with SMTP id q8mr15228164oih.129.1487701357407; Tue, 21 Feb 2017 10:22:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.51.201 with HTTP; Tue, 21 Feb 2017 10:22:17 -0800 (PST)
From: Joseph Salowey 
Date: Tue, 21 Feb 2017 10:22:17 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c092820f0cbcd05490e76df
Archived-At: 
Cc: draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org
Subject: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 18:22:39 -0000

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

Here are the open issues for draft-ietf-tls-ecdhe-psk-aead

1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of
SHA384 like the other 256 bit cipher suites? (From Russ Housley)

2.  Since the security considerations mention passwords (human chosen
secrets) it should mention dictionary attacks. (From Russ Housley)

3.  Section 2 and 3 of the document contains more detail about TLS 1.3 than
necessary.

Section 2: This document only defines cipher suites for TLS 1.2, not TLS
1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
1.3 specification.

Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
section 4 that states:

"TLS 1.3 and above name, negotiate and support a subset of these cipher
suites in a different way."  (TLS 1.3 does not support
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384
and TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)

4. Section 3 should contain a bit more detail about relationship to 4492
bis and RFC 4279:

Something like the following may be enough.

"This messages and pre-master secret construction in this document are
based on [RFC4279].  The elliptic curve parameters used in in the
Diffie-Hellman parameters are negotiated using extensions defined in
[4492-bis]."

Thanks,

Joe

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


Here are the open issues for=C2=A0draft-ietf-tls-ecdhe-psk=
-aead

1.=C2=A0 Why does=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of SHA384 lik=
e the other 256 bit cipher suites? (From Russ Housley)

2.=C2=A0 Since the secu=
rity considerations mention passwords (human chosen secrets) it should ment=
ion dictionary attacks. (From Russ Housley)

3.=C2=
=A0 Section 2 and 3 of the document contains more detail about TLS 1.3 than=
 necessary. =C2=A0

Section 2: This document only d=
efines cipher suites for TLS 1.2, not TLS 1.2 or later.=C2=A0 A subset of e=
quivalent cipher suites is defined in the TLS 1.3 specification. =C2=A0

Section 3 and 4: Maybe replace the last 2 paragraphs =
with an addition to section 4 that states:

"T=
LS 1.3 and above name, negotiate and support a subset of these cipher suite=
s in a different way." =C2=A0(TLS 1.3 does not support=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_S=
HA384 and=C2=A0=
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)

4. Section 3 should contain a bit more detail about relationship to 4492 =
bis and RFC 4279:

Something like the following may=
 be enough. =C2=A0

=
"This messages and pre-master secret =
construction in this document are based on [RFC4279].=C2=A0 The elliptic cu=
rve parameters used in in the Diffie-Hellman parameters are negotiated usin=
g extensions defined in [4492-bis]."

Thanks,

Joe





--94eb2c092820f0cbcd05490e76df--


From nobody Tue Feb 21 22:42: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 5BDE9129665 for ; Tue, 21 Feb 2017 22:42:21 -0800 (PST)
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 p2orRFh1_iZh for ; Tue, 21 Feb 2017 22:42:20 -0800 (PST)
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 0D414129662 for ; Tue, 21 Feb 2017 22:42:20 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id n21so1637368qta.1 for ; Tue, 21 Feb 2017 22:42:20 -0800 (PST)
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=XdRpOz3tvpPUaCAQucHIVgjNuGyUfQVneTuyswhhYFs=; b=tEst35cty1w0XoFY5G+QkwKp+XqLn4eiOzJsKVencve43udC/Vhp16h7VLC1Qt7Rww 7tyiHIw0l0AK6OcO6GyzqLe8PXbKTx4fS2g4OnkMKvYPNJErUi/TsjiQUkOd8qImOI4e ZGabQGxgN4pYHEJBuHVuraiGrMduxyTFZkmrxAtnAUJjwlS/tLahh3LfUVSM5ZwNoX3a rmFQm3IMy8RUDtneRlwpJagaKAFocMD2xqOb9SB4Mq/J1UKtNvZlIds5PbVkUtlzxI/V yLiRkY9P0GqHwgpA/15fHFSK1l+yxzBwxsD2Vqjawt79pwPe2mcwtD/Uv4gwrYR7MPbj ZUUA==
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=XdRpOz3tvpPUaCAQucHIVgjNuGyUfQVneTuyswhhYFs=; b=g0ejo5NL3WucsP7UJ+D0wfisSt2lba62wuYEgMtRyZPjTMLv6Hc8vbfQNjMdD5Wk+X XnxBfUdzB/idjZ0qwoSvm6vgUaeFhxPR8u8VmMAMAELvK9odGMInYh2U4JII3Vb/gD2T gzD93esCgwzlXxqdlgNiA15cQNSPe4LdifnnVN3HIX0ERg+eShbQcpvk86jaMygVLJOe f743m8a/HlNzHS+ehRYpeeo/va71Eya/N51cBgv1oBskcznLSmp6MMKARDQt05zHGJPK /1EcD9ROnxG6tQ7qdurVa4LAPY2hkDHNEyLkjVyY7bk4Fy/1UEAhR8bnNf9KslkmSudX SA/g==
X-Gm-Message-State: AMke39nEqztGDOmvR08jCkfcoHFbjoIaXFlduJoVP7xuO/nA7weSt63t0MalBwRJMk5y6Rn0SW5REN121LvpYA==
X-Received: by 10.200.46.91 with SMTP id s27mr7329049qta.278.1487745739188; Tue, 21 Feb 2017 22:42:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Tue, 21 Feb 2017 22:42:18 -0800 (PST)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Wed, 22 Feb 2017 17:42:18 +1100
Message-ID: 
To: Joseph Salowey 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 06:42:21 -0000

On the interaction with TLS 1.3, we probably need a decision to be made:

1. strike TLS 1.3 from the document and only mention it in the way Joe
suggests, TLS 1.3 doesn't get the CCM suites (it already has the
equivalent of the GCM suites)

2. strike TLS 1.3 from the document, and add new TLS 1.3 CCM cipher
suites to TLS 1.3 proper

3. add new TLS 1.3 CCM cipher suites to the document

It seems like 1 is a no-go on the basis that this document wouldn't
exist if CCM suites weren't at least a little bit interesting.


On 22 February 2017 at 05:22, Joseph Salowey  wrote:
> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead
>
> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of
> SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>
> 2.  Since the security considerations mention passwords (human chosen
> secrets) it should mention dictionary attacks. (From Russ Housley)
>
> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3 than
> necessary.
>
> Section 2: This document only defines cipher suites for TLS 1.2, not TLS 1.2
> or later.  A subset of equivalent cipher suites is defined in the TLS 1.3
> specification.
>
> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
> section 4 that states:
>
> "TLS 1.3 and above name, negotiate and support a subset of these cipher
> suites in a different way."  (TLS 1.3 does not support
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)
>
> 4. Section 3 should contain a bit more detail about relationship to 4492 bis
> and RFC 4279:
>
> Something like the following may be enough.
>
> "This messages and pre-master secret construction in this document are based
> on [RFC4279].  The elliptic curve parameters used in in the Diffie-Hellman
> parameters are negotiated using extensions defined in [4492-bis]."
>
> Thanks,
>
> Joe
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Wed Feb 22 00:04: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 E8A0B129444 for ; Wed, 22 Feb 2017 00:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 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, 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 m57n5W-8o1ZA for ; Wed, 22 Feb 2017 00:04:16 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 035D0126B6D for ; Wed, 22 Feb 2017 00:04:15 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5113B496C24; Wed, 22 Feb 2017 08:04:15 +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 3B5A1496C20; Wed, 22 Feb 2017 08:04:15 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487750655; bh=HeBOKsYPFqsJvuwm7sXN9VcDxc38ssP+dMlbBx4PjoI=; l=273; h=From:To:CC:Date:References:In-Reply-To:From; b=brhfWG1dA3J2Vpj/YBW0oFtQ/Mchy3W/L8SZV61BRalhGhCntyH2cF6dsoPV1M19s /+0b2FKBine743Lrw7jIjXxl9f8/5UNkEzw6YsonWDa6HM32IE2jZgWC/HmvIsT79r a/ICIeLL0g0GvMmCr0Oy1QeCuIij1a5K6REeimXs=
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DE7971E095; Wed, 22 Feb 2017 08:04:14 +0000 (GMT)
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.1178.4; Wed, 22 Feb 2017 03:04:14 -0500
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.1178.000; Wed, 22 Feb 2017 03:04:14 -0500
From: "Salz, Rich" 
To: Martin Thomson , Joseph Salowey 
Thread-Topic: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
Thread-Index: AQHSjG+AlPI2FEigPUqrjf2oARXzl6F06JEA///CuVA=
Date: Wed, 22 Feb 2017 08:04:13 +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.40.144]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 08:04:17 -0000

Why not just say
	The CCM cipher suites are not (currently) defined for TLS 1.3

And leave it at that.  We're all quite proud of the fact, and deservedly so=
, that we only have three ciphers defined for TLS 1.3.  Let's try to hold t=
hat position as long as possible.



From nobody Wed Feb 22 03:43: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 49C19129702 for ; Wed, 22 Feb 2017 03:43:28 -0800 (PST)
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, 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 aWsjPvRpT897 for ; Wed, 22 Feb 2017 03:43:27 -0800 (PST)
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 BF6C31296FD for ; Wed, 22 Feb 2017 03:43:26 -0800 (PST)
Received: by mail-wm0-x243.google.com with SMTP id r18so1836749wmd.3 for ; Wed, 22 Feb 2017 03:43:26 -0800 (PST)
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=r9pzatW1nbykB5baNFXFxG3QWqkPEdwX0itYOQfsoiY=; b=YsJMvyml3jD4K8z+HdU4NnvVGSIyX0wTdtI/SI6SY7Zjw4EDm8ZynF0IaN22rVdJZj Y68YOQk1Y5/aVy8Hs5PTHh7cG15RALrLAFSBUvzCMRlGJB45Ww+VP/NJd4ryOB5A7BDq pWVka2gojtSlkipe8Ba+QKMnwlt1GTB3Fe+fAoJSUEeUJeZMocPsh3TUt1VaaHMczqSS yoHtNI2Y8hIF/+N4YYH7JT6LnisdH6nUWE1pABiNte/JmP14FtG8+Wt4LxLL2YfKAb/d DHKhWZhdJYV51UlDNVaP/jQYpTvzbte7qnJTCiIpcuElORJokBZx49AMdg/05LxOCH/I /RDw==
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=r9pzatW1nbykB5baNFXFxG3QWqkPEdwX0itYOQfsoiY=; b=k+GhOcrubYqBybzeaZIeSPoHFNNt28XT7kLqLOZVATMB04aiQMzPU6vJdxlI9i+PbT 8PEBOgYLCSu5UqRSbJ0iaEz9KcLjChVZn56VxZ/TLmd5ybfr5Z2km5bQIFqNe/PBiY8U uqy5YJ3bdMJ3/g9O2OwHuR+p4MPTnaqYOx4Z3NyF3hMdPwoOOfgmmb90TKAXFI6FSikL A04EBLUJEuWHxoNFEnPyw76pt/djYrEuDfvoaIkENSu5cFPG+PlcvdlDZnlus0gwdmy4 pRH7+mGdEa4W/ZvF+DrpmB9B4Ct6ZrnnIfQ1vwsN64B7xpc/XRpk/XzyYr5KoR3/qeQj NGIA==
X-Gm-Message-State: AMke39lbe2I5HxFvaz0K0JosepL8BGr8EmoSlcFaPc3AfkESEfBgbJadFa8JFYch6Vmhaw==
X-Received: by 10.28.30.12 with SMTP id e12mr2128293wme.125.1487763805248; Wed, 22 Feb 2017 03:43:25 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id b87sm1768417wmi.0.2017.02.22.03.43.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 03:43:24 -0800 (PST)
From: Yoav Nir 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF5FC6A0-5F9F-4324-A7C6-9CF83A336DCD"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 22 Feb 2017 13:43:21 +0200
In-Reply-To: 
To: Martin Thomson 
References:  
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 11:43:28 -0000

--Apple-Mail=_BF5FC6A0-5F9F-4324-A7C6-9CF83A336DCD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 22 Feb 2017, at 8:42, Martin Thomson  =
wrote:
>=20
> On the interaction with TLS 1.3, we probably need a decision to be =
made:
>=20
> 1. strike TLS 1.3 from the document and only mention it in the way Joe
> suggests, TLS 1.3 doesn't get the CCM suites (it already has the
> equivalent of the GCM suites)
>=20
> 2. strike TLS 1.3 from the document, and add new TLS 1.3 CCM cipher
> suites to TLS 1.3 proper

Wait, what am I missing?

=46rom appendix A.4 in TLS 1.3:

              +------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

So, how do we not have CCM in TLS 1.3 given that things like ECDHE and =
PSK are now orthogonal to ciphersuites?

Yoav=

--Apple-Mail=_BF5FC6A0-5F9F-4324-A7C6-9CF83A336DCD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 22 Feb 2017, at 8:42, Martin Thomson <martin.thomson@gmail.com> wrote:

On =
the interaction with TLS 1.3, we probably need a decision to be made:

1. strike TLS 1.3 from the document and only =
mention it in the way Joe
suggests, TLS 1.3 doesn't get =
the CCM suites (it already has the
equivalent of the GCM =
suites)

2. strike TLS 1.3 from the =
document, and add new TLS 1.3 CCM cipher
suites to TLS 1.3 =
proper

Wait, what am I missing?

=46rom appendix A.4 in TLS =
1.3:
              +------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

So, how do we not =
have CCM in TLS 1.3 given that things like ECDHE and PSK are now =
orthogonal to ciphersuites?

Yoav
=

--Apple-Mail=_BF5FC6A0-5F9F-4324-A7C6-9CF83A336DCD--


From nobody Wed Feb 22 09:12: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 ECC7612997E for ; Wed, 22 Feb 2017 09:12:04 -0800 (PST)
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 chDUvmtO2uzu for ; Wed, 22 Feb 2017 09:12:03 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD50129A5A for ; Wed, 22 Feb 2017 09:12:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 93F871F692; Wed, 22 Feb 2017 19:12:00 +0200 (EET)
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 hq5hi9gEiOjh; Wed, 22 Feb 2017 19:12:00 +0200 (EET)
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 5E44228A; Wed, 22 Feb 2017 19:12:00 +0200 (EET)
Date: Wed, 22 Feb 2017 19:11:56 +0200
From: Ilari Liusvaara 
To: "Salz, Rich" 
Message-ID: <20170222171156.GA31015@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: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 17:12:05 -0000

On Wed, Feb 22, 2017 at 08:04:13AM +0000, Salz, Rich wrote:
> Why not just say
> 	The CCM cipher suites are not (currently) defined for TLS 1.3
> 
> And leave it at that.  We're all quite proud of the fact, and
> deservedly so, that we only have three ciphers defined for TLS 1.3.
> Let's try to hold that position as long as possible.

Well, AES-128-CCM with 8 and 16 byte tags does exist in editor's
copy (0x1304 and 0x1305).

No AES-256-CCM tho.


-Ilari


From nobody Wed Feb 22 09:13: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 58D91129A71 for ; Wed, 22 Feb 2017 09:13:08 -0800 (PST)
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=unavailable 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 oHLCyIXK9Rhd for ; Wed, 22 Feb 2017 09:13:07 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12412940A for ; Wed, 22 Feb 2017 09:07:22 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1059A20006E for ; Wed, 22 Feb 2017 17:07:22 +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 EE4D720000F for ; Wed, 22 Feb 2017 17:07:21 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487783241; bh=IDymbQR6ijN3MazPMHiz62mWL7bEB++6zpcZHUJqurY=; l=2702; h=From:To:Date:From; b=jn0o9EfllTapDfN7VQ0gJN2gZaF5wxMHGzTbYCY0Ix9yqMe5flNn85PXTjivcU9i/ +x6F0xb1enTGHOGhg4lAaN186J6TRuLmFVrKdcDQr53cN4sTtFZz8sU2D0ranfroqQ 9uhpXBjYWnwx0fqw2sLnDpI25YLYXPgsk9apPSdE=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id D44F498085 for ; Wed, 22 Feb 2017 17:07:21 +0000 (GMT)
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.1178.4; Wed, 22 Feb 2017 12:07:21 -0500
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.1178.000; Wed, 22 Feb 2017 12:07:21 -0500
From: "Salz, Rich" 
To: "tls@ietf.org" 
Thread-Topic: stapling OCSP/CT for client cert?
Thread-Index: AdKNLg/Tt012psnqSOajEACnm0jpBQ==
Date: Wed, 22 Feb 2017 17:07:20 +0000
Message-ID: 
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.34.120]
Content-Type: multipart/alternative; boundary="_000_f4a5f57179384290859f8ff1afba73b0usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
Archived-At: 
Subject: [TLS] stapling OCSP/CT for client cert?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 17:13:08 -0000

--_000_f4a5f57179384290859f8ff1afba73b0usma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Any thoughts on being able to staple OCSP (or CT) data to a client cert onc=
e requested by the server?

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: RichSalz


--_000_f4a5f57179384290859f8ff1afba73b0usma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Any thoughts on being able to staple OCSP (or CT) da=
ta to a client cert once requested by the server?


 


--  


Senior Architect, Akamai Technologies


Member, OpenSSL Dev Team


IM: richsalz@jabber.at Twitter: RichSalz<=
/p>

 






--_000_f4a5f57179384290859f8ff1afba73b0usma1exdag1mb1msgcorpak_--


From nobody Wed Feb 22 09:23: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 021BC129A14 for ; Wed, 22 Feb 2017 09:23:36 -0800 (PST)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=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 S8bE3RUmckGJ for ; Wed, 22 Feb 2017 09:23:33 -0800 (PST)
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 66A6812985F for ; Wed, 22 Feb 2017 09:23:33 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id x35so8278800qtc.2 for ; Wed, 22 Feb 2017 09:23:33 -0800 (PST)
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=uxjSi13nio0hSSYcd+mYg3Qu66cen0XMyQaCDxSfKI8=; b=OnlWCfz6opU/bHQCsrgOO5SHsuPCZfrKHufAq95r3FYuQmzhJN7/TeTZfH2UYFD9ee 0do2E7nMlpBer7GrtgrfwdABWLcLYpiG0mTb8yw8+XPYjuuUjVvkFe/RuaURCdHCEfz+ Y0R6GYm3UTxFF/AhgThS9VNQB7ocWRYs/wMCk=
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=uxjSi13nio0hSSYcd+mYg3Qu66cen0XMyQaCDxSfKI8=; b=G54YWhzgREQhUUr3035M/NmW8JDOZjvGSi21PEi85O+U1gNcZpX1+s29rbzuPNQvlF RYGSDmjg8SNIl35/n83xlJNox8jnSSt5lfqv1z83HZdD7NWghIopkOI0s1ahy+gCNj0c eKH6eU76TjGDjagYAoLmRanF+woOTnXESmUWqpiiehLYpVp85ME2yOS2aVP1QPgQOv6c 8wxETcY/9kXQA+56qLlGt1JWEDP0B/wLg1es19pibuTZOwQ8mpzkiIKwPB1/V85yKeK/ 2VJMLB7R1Nl9i8prYiCiq6ATJduEX5IwU9Fl6YZbKuNeVX+MjqPDTy0bAYtKy3YkVHRQ XxCQ==
X-Gm-Message-State: AMke39kF2L7KHXaKikJdTwvyZWpEE1+3UVa06k4jZYPWwGykMA3m+bmwO7pdZFHmt+gt8nellU2bmkyP3e2qVVUl
X-Received: by 10.237.34.116 with SMTP id o49mr30339514qtc.122.1487784212328;  Wed, 22 Feb 2017 09:23:32 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: David Benjamin 
Date: Wed, 22 Feb 2017 17:23:22 +0000
Message-ID: 
To: "Salz, Rich" , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113e7bf67acb5a054921c1fb
Archived-At: 
Subject: Re: [TLS] stapling OCSP/CT for client cert?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 17:23:36 -0000

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

Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take
all of four characters to fix. See this table:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2

One of the nice things about using TLS-style extensions in
CertificateRequest is any ClientHello => (Server)Certificate extensions
naturally extend to CertificateRequest => (Client)Certificate extensions.

On Wed, Feb 22, 2017 at 12:13 PM Salz, Rich  wrote:

Any thoughts on being able to staple OCSP (or CT) data to a client cert
once requested by the server?



--

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz


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

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


Looks like TLS 1.3 al=
ready allows this for CT, though not OCSP. Would take all of four character=
s to fix. See this table:
=
https://tlswg.github.io/tls13-spec/#rfc.section.=
4.2

One of the nice things about using TLS-style extensions i=
n CertificateRequest is any ClientHello =3D> (Server)Certificate extensi=
ons naturally extend to CertificateRequest =3D> (Client)Certificate exte=
nsions.

On Wed, Feb 22, 2017 at 12:13 PM S=
alz, Rich <rsalz@akamai.com> wrote:
<=
blockquote class=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">










Any thoughts on being able to staple OCSP =
(or CT) data to a client cert once requested by the server?


=C2=A0


--=C2=A0 


Senior Architect, Akamai Technologies


Member, OpenSSL Dev Team


IM: richsalz@jabber.at Twitter: RichS=
alz


=C2=A0






_______________________________________________

TLS mailing list

TLS@i=
etf.org

https://www.ietf.org/mailman/listinfo/t=
ls




--001a113e7bf67acb5a054921c1fb--


From nobody Wed Feb 22 09:54: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 79EF912985F for ; Wed, 22 Feb 2017 09:54:08 -0800 (PST)
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 bHfRwFxtpiq2 for ; Wed, 22 Feb 2017 09:54:07 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 694F6129503 for ; Wed, 22 Feb 2017 09:54:07 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 05297496C3E; Wed, 22 Feb 2017 17:54:07 +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 D9652496C30; Wed, 22 Feb 2017 17:54:06 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487786046; bh=0Diy29y631h2Vxxc6kfujFpoWhzdbosnD/Tqtjnei78=; l=3888; h=From:To:Date:References:In-Reply-To:From; b=dG3rqKsSg+RrntV9uwEebRWwiHGy7n7sBTAo1dJ9dP7xXqlzIQkUT4z8EqiqC1eT0 zOUE3/zAMEkf3tqeWwYl1u82YwPT2REuoPxCPAInc228Asq/7gLFxDIxCsbCkyLRl1 K29yPdqpdxrMvB0iHOxsCvRe/eFUvk9U25p8Lwvg=
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C0F5198084; Wed, 22 Feb 2017 17:54:06 +0000 (GMT)
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.1178.4; Wed, 22 Feb 2017 12:54:06 -0500
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.1178.000; Wed, 22 Feb 2017 12:54:06 -0500
From: "Salz, Rich" 
To: David Benjamin , "tls@ietf.org" 
Thread-Topic: [TLS] stapling OCSP/CT for client cert?
Thread-Index: AdKNLg/Tt012psnqSOajEACnm0jpBQALDbgAAAluw1A=
Date: Wed, 22 Feb 2017 17:54:05 +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.34.120]
Content-Type: multipart/alternative; boundary="_000_eba1a242d77042b184d1b431adc934b5usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] stapling OCSP/CT for client cert?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 17:54:08 -0000

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

aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC84ODANCg0KSSBrbmV3IGl0
IHdhcyBlYXN5IHRvIGZpeCwgd2FzbuKAmXQgc3VyZSBpZiBmb2xrcyB3YW50ZWQgaXQuICBHaXZl
cyBtZSBhIHJlYXNvbiB0byBqb2luIHRoZSBjb250cmlidXRvcnMgbGlzdC4NClZlcnkgdXNlZnVs
IGluIHBlZXItdG8tcGVlciBzaXR1YXRpb25zLg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t
L3Rsc3dnL3RsczEzLXNwZWMvcHVsbC84ODAiPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMx
My1zcGVjL3B1bGwvODgwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBrbmV3IGl0IHdhcyBlYXN5IHRvIGZpeCwg
d2FzbuKAmXQgc3VyZSBpZiBmb2xrcyB3YW50ZWQgaXQuJm5ic3A7IEdpdmVzIG1lIGEgcmVhc29u
IHRvIGpvaW4gdGhlIGNvbnRyaWJ1dG9ycyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5WZXJ5IHVzZWZ1bCBpbiBwZWVyLXRvLXBlZXIgc2l0dWF0aW9ucy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_eba1a242d77042b184d1b431adc934b5usma1exdag1mb1msgcorpak_--


From nobody Wed Feb 22 12:04: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 BDC7E129ACE for ; Wed, 22 Feb 2017 12:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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=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 cw1bZIzbojCM for ; Wed, 22 Feb 2017 12:04:13 -0800 (PST)
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 71BDF129AC7 for ; Wed, 22 Feb 2017 12:04:13 -0800 (PST)
Received: by mail-yb0-x22e.google.com with SMTP id u130so3704110ybb.0 for ; Wed, 22 Feb 2017 12:04:13 -0800 (PST)
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=4ytmoBKE6Wq4/TzyAgwsigaOVJHGPVYMADbE+0EQ4oA=; b=fINBlhaymWvAj3bH+eZ65+F4cPTVg4x8swI5ZFyiaLNztWfMnzmI9Vd6QRJ+TjRWli 4hQVUeTEw3bsmPfO5wD2CJ5GhpME1Xa4ADvbn6pdRxB3LlimfB5Mj+jdzqvUnFUNPYNf sb+8VEb9rhlqE9pKjAIpGLMKzZTnRvs8IOISWANHwTTstcGdJm3vj0mG2m7tLyY8aTsq Rq5GvHpznTfuxpg49xitzTa90j/pUF9qyUspYM5O3L5db24vhv9ZFhoVOPk9QDkYcPOg eFLp1IOPQLW61/t8WfNh9Pj8FyJeWYhYzvMXB11X8HGmr+i1DEHsQF6gCa8V2t8Y/IRL oR0Q==
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=4ytmoBKE6Wq4/TzyAgwsigaOVJHGPVYMADbE+0EQ4oA=; b=Q4qm5NGMAaY6BtOcr+aylbCSs7Xj2sXgHrRe/GFqMn2vcqjxFqhBDn54ya8BI0izem miXRsKVnYsjQvOoGWoYGW25EWc/BpFGXHoJaTpYVcPGUJRyqcvkE7fHbPz1wOQRaU7s+ dQKgVd/TF9wHZ2IeLtZAUeWAxJMivCQvjbuvj9UphmMJLKtqm9DyFVAo6g3TTUunIAcW S773tigtrAv6n1qjRGEBdTADyNxnsuTUPMHrO6faVhPtznQ7ETyGcQNUsQb2SobNu8K/ 5iTBn5iwaGRWRYqo2pr8FiwxLYocsYTDKq0REA5a251xDhyeIoCAG3JZX/b5XPSchQH4 jDxw==
X-Gm-Message-State: AMke39l+hx/G5mNmg2pnIL7pxZz58+DOMQ98FdVzc1fhMV3+1x+imG+tqfUXPzI25G/UpKa44s7e1cIZIFgrRg==
X-Received: by 10.37.41.70 with SMTP id p67mr18945252ybp.147.1487793852566; Wed, 22 Feb 2017 12:04:12 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.37.49.9 with HTTP; Wed, 22 Feb 2017 12:03:41 -0800 (PST)
In-Reply-To: 
References: 
From: Hugo Krawczyk 
Date: Wed, 22 Feb 2017 15:03:41 -0500
X-Google-Sender-Auth: XiKFU8lFbmgUebnO7rcjgov3bpA
Message-ID: 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=94eb2c14e0b614d85f05492400df
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PR#875: Additional Derive-Secret Stage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 20:04:15 -0000

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

On Thu, Feb 9, 2017 at 4:15 PM, Eric Rescorla  wrote:

> I've just posted a pull request which slightly adjusts the structure of
> key derivation.
> PR#875 adds another Derive-Secret stage to the left side of the key ladde=
r
> between each pair of HKDF-Extracts. There are two reasons for this:
>
> - Address a potential issue raised by Trevor Perrin where an attacker
>   somehow forces the IKM value to match the label value for Derive-Secret=
,
>   in which case the output of HKDF-Extract would match the derived secret=
.
>   This doesn't seem like it should be possible for any of the DH variants
>   we are using, and it's not clear that it would lead to any concrete
>   attack, but in the interest of cleanliness, it seemed good to address.
>
> - Restore Extract/Expand parity which gives us some flexibility in
>   case we want to replace HKDF.
>

=E2=80=8BI want to stress, also as advise for future uses of HKDF, that a
recommended practice for HKDF is to always follow HKDF-extract with
HKDF-expand. That's how HKDF is defined and departing from it should be
done with utmost care. The issue raised by Trevor is an example of such
subtleties. In particular, note that HKDF-Extract does not carry a "info"
input while HKDF-Expand does, and such field is almost always essential for
key separation and to tie derived keys to some particular context.

Hugo


> I don't expect this change to be controversial and I'll merge it on Monda=
y
> unless I hear objections.
>
> Thanks,
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

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




On Thu, Feb 9, 2017 at 4:15 PM, Eric Rescorla <ekr@rtfm.co=
m> wrote:
=

I've just posted a pull request which slightly adjusts the structu=
re of key derivation.
PR#875 adds another Derive-Secret stage to =
the left side of the key ladder
between each pair of HKDF-Ext=
racts. There are two reasons for this:

- Address a=
 potential issue raised by Trevor Perrin where an attacker
=C2=A0=
 somehow forces the IKM value to match the label value for Derive-Secret,
=C2=A0 in which case the output of HKDF-Extract would match the de=
rived secret.
=C2=A0 This doesn't seem like it should be poss=
ible for any of the DH variants
=C2=A0 we are using, and it's=
 not clear that it would lead to any concrete
=C2=A0 attack, but =
in the interest of cleanliness, it seemed good to address.

- Restore Extract/Expand parity which gives us some flexibility in=

=C2=A0 case we want to replace HKDF.

=E2=80=8BI want to stress, also as advise for future=
 uses of HKDF, that a recommended practice for HKDF is to always follow HKD=
F-extract with HKDF-expand. That's how HKDF is defined and departing fr=
om it should be done with utmost care. The issue raised by Trevor is an exa=
mple of such subtleties. In particular, note that HKDF-Extract does not car=
ry a "info" input while HKDF-Expand does, and such field is almos=
t always essential for key separation and to tie derived keys to some parti=
cular context.

Hugo

I don't expect this change to be controversial and I'll merge it o=
n Monday
unless I hear objections.

Thank=
s,
-Ekr







_______________________________________________

TLS mailing list

TLS@ietf.org

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





--94eb2c14e0b614d85f05492400df--


From nobody Wed Feb 22 12:28: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 B6E4B129B0F for ; Wed, 22 Feb 2017 12:28:58 -0800 (PST)
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 Y9oRegSWn7sT for ; Wed, 22 Feb 2017 12:28:56 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF70129AE2 for ; Wed, 22 Feb 2017 12:28:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 96F3F1F76D; Wed, 22 Feb 2017 22:28:42 +0200 (EET)
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 tuHPPC2iYo1d; Wed, 22 Feb 2017 22:28:42 +0200 (EET)
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 205EF285; Wed, 22 Feb 2017 22:28:42 +0200 (EET)
Date: Wed, 22 Feb 2017 22:28:38 +0200
From: Ilari Liusvaara 
To: David Benjamin 
Message-ID: <20170222202838.GA31310@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: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] stapling OCSP/CT for client cert?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Feb 2017 20:28:58 -0000

On Wed, Feb 22, 2017 at 05:23:22PM +0000, David Benjamin wrote:
> Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take
> all of four characters to fix. See this table:
> https://tlswg.github.io/tls13-spec/#rfc.section.4.2
> 
> One of the nice things about using TLS-style extensions in
> CertificateRequest is any ClientHello => (Server)Certificate extensions
> naturally extend to CertificateRequest => (Client)Certificate extensions.

That got me to review the message assignments of extensions. I found
several problematic definitions:


1) Client_certificate_url (CH, EE):

This is related to client certificate, but it also has more
serious problem: It uses its own handshake type in way that
is seemingly ill-defined in context of TLS 1.3.


2) User_mapping (CH, EE):

This is pretty special in TLS 1.2, by being three-pass,
instead of the usual two-pass. It also has its own message
in TLS 1.2. How exactly is that supposed to work in TLS 1.3,
is the SupplementalData really supposed to become the first
message in client 2nd flight (that should be specified) or
is the message supposed to be chucked inside certificate
extension (which would need adding CT to message assignments
for the extension).


3) Cert_type (CH, EE):

This is related to either client or server certificate. However,
cert_type is older extension that was superceded by
client_certificate_type and server_certificate_type. Deprecate?


4) Client_certificate_type (CH, EE):

This extension is about client certificates, which would logically
imply assignment of CR, CT.

This comes rather important if there ever will be certificate type
that make sense to mix and match with X.509 certificates from client
context. E.g. Subcertificates implemented as certificate type.




-Ilari


From nobody Thu Feb 23 08:08: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 8C50B12995D for ; Thu, 23 Feb 2017 08:08:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=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 XEMkFldI91wB for ; Thu, 23 Feb 2017 08:08:53 -0800 (PST)
Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 54E1C12988C for ; Thu, 23 Feb 2017 08:08:52 -0800 (PST)
Received: from host86-136-170-66.range86-136.btcentralplus.com ([86.136.170.66]:15125 helo=[192.168.1.64]) by relay02.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1cgvwk-0003mp-8x  (return-path ); Thu, 23 Feb 2017 16:08:47 +0000
To: Eric Rescorla , "tls@ietf.org" 
References: 
From: Dr Stephen Henson 
Message-ID: <929120a9-96db-751f-abcc-2982d8640b62@drh-consultancy.co.uk>
Date: Thu, 23 Feb 2017 16:08:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [TLS] (no subject)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 16:08:55 -0000

On 09/02/2017 21:17, Eric Rescorla wrote:
> Hi folks,
> 
> We need to close on an issue about the size of the
> state in the HelloRetryRequest. Because we continue the transcript
> after HRR, if you want a stateless HRR the server needs to incorporate
> the hash state into the cookie. However, this has two issues:
> 
> 1. The "API" for conventional hashes isn't designed to be checkpointed
>    at arbitrary points (though PKCS#11 at least does have support
>    for this.)
> 2. The state is bigger than you would like b/c you need to store both
>    the compression function and the "remainder" of bytes that don't
>    fit in [0]
> 

Does the handling of Post-Handshake authentication pose a similar issue? That is
the need to keep the hash context of the handshake and then append additional
data to generate or check the CertificateVerify message?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.


From nobody Thu Feb 23 08:17: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 74164129864 for ; Thu, 23 Feb 2017 08:16:59 -0800 (PST)
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 iFG4oYK2ZVg7 for ; Thu, 23 Feb 2017 08:16:58 -0800 (PST)
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 C92B11299EB for ; Thu, 23 Feb 2017 08:16:57 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id p77so18924247ywg.1 for ; Thu, 23 Feb 2017 08:16:57 -0800 (PST)
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=7bg5ZYWNU0TMcZdHeJqG2vHFDhGpSD3OPePNNav4qjU=; b=vomur2vn+SghyCBFZQL8U+LKs7Vr2MhZ1k0jxitAETs05rrk6NILVZVwq61qEvtGuD STOt2VeYetfN5B55RRSecSy26nG5KkyYREOiKjQ+BNLtjbfxhPuVpFFrm47E0XORQwRm wmyYT0CouSBM6TCoSDhJNrWiW4ui7QG4EWjvRlPZ5em6tXghE5/HqqnZRb/+yavIU6s7 sVBL8a/cUKUxy5tPPjOSRZgc2QeU1rrAiJE5h5v0T7UqE/wPXrE/1mLclfOPkbrLMXQj qN0X8oszJ676jQ5WscN53vko6XbOfil1uVRmFeGSAvmfjjjgUlTnl8mnMe6yM9SdiQqN /wCg==
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=7bg5ZYWNU0TMcZdHeJqG2vHFDhGpSD3OPePNNav4qjU=; b=NKQxFAr7GFF3r8Z8O2biQc5Egt3ACvSAogVZVlbrm8Cl0y2RfcmH3OvlNP3GrbPvcU 4TBNSTFjhhJbbqHVCCk/G/0cX7Y4fvR+7HX982Nvt3gGSe0AKZBPOY+UwmZ3t7RResjU BKfPd5vj4/O77cGf3eK9UyYMyXqfQPEYbm+vdcCihEBp2sYvf+PSlN5j3qQuCnTEQWsC 4q1pximJnJqqarm0VFTveLZ2nimEc6OFQFrvd8J6/dergb2GdaEh1Els01CmxFvwyPez M9L8bc/6DVGXSGJuJGPBD5wJpfc/UnjYhFjxz7H/4rDPerISq2PSrBc1gXgGbPeY8G3+ HriQ==
X-Gm-Message-State: AMke39maY3b4ke17D2nhZuUTk3DiWRmeCeE6JDXc5IPgKBvCYyYA/8An3oKujJ9IN/1YZe0zHQi01yC/6cOzkg==
X-Received: by 10.129.137.129 with SMTP id z123mr30570944ywf.327.1487866617047;  Thu, 23 Feb 2017 08:16:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Thu, 23 Feb 2017 08:16:16 -0800 (PST)
In-Reply-To: <929120a9-96db-751f-abcc-2982d8640b62@drh-consultancy.co.uk>
References:  <929120a9-96db-751f-abcc-2982d8640b62@drh-consultancy.co.uk>
From: Eric Rescorla 
Date: Thu, 23 Feb 2017 08:16:16 -0800
Message-ID: 
To: Dr Stephen Henson 
Content-Type: multipart/alternative; boundary=94eb2c06bf382ed74f054934f19e
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] (no subject)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 16:16:59 -0000

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

On Thu, Feb 23, 2017 at 8:08 AM, Dr Stephen Henson <
lists@drh-consultancy.co.uk> wrote:

> On 09/02/2017 21:17, Eric Rescorla wrote:
> > Hi folks,
> >
> > We need to close on an issue about the size of the
> > state in the HelloRetryRequest. Because we continue the transcript
> > after HRR, if you want a stateless HRR the server needs to incorporate
> > the hash state into the cookie. However, this has two issues:
> >
> > 1. The "API" for conventional hashes isn't designed to be checkpointed
> >    at arbitrary points (though PKCS#11 at least does have support
> >    for this.)
> > 2. The state is bigger than you would like b/c you need to store both
> >    the compression function and the "remainder" of bytes that don't
> >    fit in [0]
> >
>
> Does the handling of Post-Handshake authentication pose a similar issue?
> That is
> the need to keep the hash context of the handshake and then append
> additional
> data to generate or check the CertificateVerify message?
>

It's a slight inconvenience, but not a real issue because you don't need to
send the state over the wire. So you just need a forkable hash
implementation, which you needed anyway because of the way the rest of the
hashing works.

-Ekr


> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
>

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




On Thu, Feb 23, 2017 at 8:08 AM, Dr Stephen Henson &l=
t;lists@dr=
h-consultancy.co.uk> wrote:
On 09/02/2017 21:17, Eric Rescorla wrote:

> Hi folks,

>

> We need to close on an issue about the size of the

> state in the HelloRetryRequest. Because we continue the transcript

> after HRR, if you want a stateless HRR the server needs to incorporate=


> the hash state into the cookie. However, this has two issues:

>

> 1. The "API" for conventional hashes isn't designed to b=
e checkpointed

>=C2=A0 =C2=A0 at arbitrary points (though PKCS#11 at least does have su=
pport

>=C2=A0 =C2=A0 for this.)

> 2. The state is bigger than you would like b/c you need to store both<=
br>
>=C2=A0 =C2=A0 the compression function and the "remainder" of=
 bytes that don't

>=C2=A0 =C2=A0 fit in [0]

>



Does the handling of Post-Handshake authentication pose a similar is=
sue? That is

the need to keep the hash context of the handshake and then append addition=
al

data to generate or check the CertificateVerify message?

It's a slight inconvenience, but not a real issue bec=
ause you don't need to send the state over the wire. So you just need a=
 forkable hash implementation, which you needed anyway because of the way t=
he rest of the hashing works.

-Ekr

<=
/div>



Steve.

--

Dr Stephen N. Henson.

Core developer of the=C2=A0 =C2=A0OpenSSL project: http://www.openssl.org/

Freelance consultant see: http://www.drh-consultancy.co.uk/

Email: shenson@drh-consult=
ancy.co.uk, PGP key: via homepage.





--94eb2c06bf382ed74f054934f19e--


From nobody Thu Feb 23 20:30: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 A1FCB129512 for ; Thu, 23 Feb 2017 20:30:36 -0800 (PST)
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 w_nYMoH65S4C for ; Thu, 23 Feb 2017 20:30:35 -0800 (PST)
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 24E7F12950E for ; Thu, 23 Feb 2017 20:30:35 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id s186so10142102qkb.1 for ; Thu, 23 Feb 2017 20:30:35 -0800 (PST)
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=d7vaest5aiLtU7695/9BDAZ7ziaUhiClA8YCTVelDLc=; b=RGe8+l+/j1ytotF7qKhm3Ni0l3UXijiRUm3PS6Jpl48yWq72mUllP8BpGJqH+5h8s2 qIS/rxL8EY05wUGaaEjLF1Jg2rZzy/pwzlhrn4MNQ286cnEDE6vXkICcZaBFFwMAWEzt KK3g1OBpv3D0G8vwEzqqt14oFoDKbq7IxFxfdCi0WDAeNYp5ECZOwPVSRmTnp7B1t8qG 5l0Rr4iHOGsOPztzrSXDBpvLFqRleZJy+5J1GzYDAVv4stJcFj7fAmvUSKMGH63pBTyf qNBcx0nimQMeJ8l6afS+KdHEAkNccQvD7yk69aOs9Mvs4ZbNlUtx3Plleim6VVlfywRE u2kA==
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=d7vaest5aiLtU7695/9BDAZ7ziaUhiClA8YCTVelDLc=; b=M6g1Il7Jtq3ewNyYIKN1VgXhcQmZc5H9x7aWj1+btf26ZvctUZKfM+xWeR0IXHzCBr Yf22L85dnkuzNP4reNIoRFD803d/t+E8orPLHv2Fcy82kAIEtjzQ3OLHBL3kfSXP5Hq/ SyEMW83iqGTCW+U1oepKQrw2dGnO/0IUc69FuayeJ+xVCKZJ5SyHmkikVyA/T6k5PH90 j4G7roy9GSc0LXqTpo7dxbzgzVNBDQd5e2pLOlWTcgyRj2/S65yjxKSWamzsG7SdA9sN jnZzPTtZUK25viS00ozJaRAYqUuj2owlikR1lpglupUE5XnDaAMjn02xiCjMA9r0VYvh 5mHg==
X-Gm-Message-State: AMke39nxXyqzwgQmHZ9f0h2VytzRxDaqu11w2Mym81D6lDGeiOTLRpXvicQQepDO9lPEiRna+Kc2/qRHeZSIwg==
X-Received: by 10.55.200.217 with SMTP id t86mr729800qkl.5.1487910634027; Thu, 23 Feb 2017 20:30:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Thu, 23 Feb 2017 20:30:33 -0800 (PST)
From: Martin Thomson 
Date: Fri, 24 Feb 2017 15:30:33 +1100
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 04:30:36 -0000

https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.

In short, the existence of an exporter secret threatens the forward
secrecy of any exported secret.  This is a problem for QUIC and is
likely to be a more general problem.

The proposed fix is small: separate exporters into two steps
(extract+expand) where the first step allows for separation based on
exporter type and the second on context.  That allows an endpoint to
keep separate secrets for each exporter type and discard those that it
no longer needs, thus gaining forward secrecy if it likes.


From nobody Thu Feb 23 21: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 80D3B12955C for ; Thu, 23 Feb 2017 21:01:43 -0800 (PST)
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 RtAMHUkdoGd9 for ; Thu, 23 Feb 2017 21:01:42 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 F0B3E129558 for ; Thu, 23 Feb 2017 21:01:41 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id r45so9305823qte.3 for ; Thu, 23 Feb 2017 21:01:41 -0800 (PST)
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=eu3ZBF/rU6H1yl3fCPAARcHombN8hyJ+NeRXrTMWtbY=; b=jCzXULhRxbNGhbFmN6b+8jomO2rZcOMNmKN8eYCKve+/mRCEU6jVpAgivDUvQqFWY0 lHBNXH7GXJi1nbKgYpWisAUHV2MX9ZyMwUp3b+DzKKyDBbHzQmgiY6RcEMIfofpdFksi D9AruNHCYhseHOLH49OzB/B0IK0+JpVGzog1w=
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=eu3ZBF/rU6H1yl3fCPAARcHombN8hyJ+NeRXrTMWtbY=; b=n6QOWHYC4hnj7YRaGA265Qv/oKE+RFyocyGNAIuWdgWMCa8xsphai8AwKYaH7YcQqq 2bB3/6eE8CcK3mGCEZDHzrT45RhYRZAwIxmK59LkXmHYPmNbZvGa0cWrTOpMQl6Gj0jV 83X5w0A2mAw+3pSxyIbKcNwV9hTAvOHKnfPslIMZuzHVvHMrNMJg22pyfxBGLdKx/kX1 N4IcWDSsVGPaJGa8CrazDFXe04Jige7imRyQvUNAodCY1IdkfPIG05vfgIiD7do6auHO h1U41jpFzY/867xOqVTp5TfGraov8NR5EdlQ9kj21OrjrmrifoGBcBSDVrv9YpZJa73P ls2w==
X-Gm-Message-State: AMke39nwEFn3bI0BQxYB2GKpvCgsSHflyrurXQG14kb6qDqGFSM8dTDIwPfALNMbulOU3A==
X-Received: by 10.200.41.73 with SMTP id z9mr760120qtz.137.1487912500963; Thu, 23 Feb 2017 21:01:40 -0800 (PST)
Received: from [172.16.0.92] ([96.231.229.68]) by smtp.gmail.com with ESMTPSA id 126sm4156308qkl.24.2017.02.23.21.01.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Feb 2017 21:01:39 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Fri, 24 Feb 2017 00:01:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AF5C160-23D2-4718-889D-F0663FD4FC14@sn3rd.com>
References: 
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 05:01:43 -0000

So this isn=E2=80=99t entirely novel right I mean we did something =
similar wrt other key schedules?

spt

> On Feb 23, 2017, at 23:30, Martin Thomson  =
wrote:
>=20
> https://github.com/tlswg/tls13-spec/pull/882 contains the longer =
description.
>=20
> In short, the existence of an exporter secret threatens the forward
> secrecy of any exported secret.  This is a problem for QUIC and is
> likely to be a more general problem.
>=20
> The proposed fix is small: separate exporters into two steps
> (extract+expand) where the first step allows for separation based on
> exporter type and the second on context.  That allows an endpoint to
> keep separate secrets for each exporter type and discard those that it
> no longer needs, thus gaining forward secrecy if it likes.
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Thu Feb 23 21:09: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 5533E129973 for ; Thu, 23 Feb 2017 21:09:42 -0800 (PST)
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, 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 OS2Vxo1JVC_2 for ; Thu, 23 Feb 2017 21:09:40 -0800 (PST)
Received: from lnx500.hrz.tu-darmstadt.de (lnx500.hrz.tu-darmstadt.de [130.83.156.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5C31294D1 for ; Thu, 23 Feb 2017 21:09:39 -0800 (PST)
Received: from smtp.tu-darmstadt.de (lnx504.hrz.tu-darmstadt.de [130.83.156.233]) by lnx500.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id v1O59a00011964 for ; Fri, 24 Feb 2017 06:09:37 +0100 (envelope-from guenther@cs.tu-darmstadt.de)
Received: from [173.164.156.6] (helo=[10.248.43.51]) by smtp.tu-darmstadt.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1ch88O-0004DQ-Il for tls@ietf.org; Fri, 24 Feb 2017 06:09:36 +0100
References: 
From: =?UTF-8?Q?Felix_G=c3=bcnther?= 
To: tls@ietf.org
Openpgp: id=2BAE4A6F7946461B700161B352AF0200D3F1700E; url=http://www.felixguenther.info/publickey.asc
Message-ID: <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de>
Date: Thu, 23 Feb 2017 21:09:34 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2017.2.24.50317
X-PMX-RELAY: outgoing
Archived-At: 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 05:09:42 -0000

Hi Martin,

just to clarify: you add an additional HKDF.Expand step, not
HKDF.Extract, right?

You mentioned extract in the email and PR text, but in code it's a
second expand---which makes sense, as only expand allows to add context
(here: label).

Cheers,
Felix

On 23/02/2017 20:30 -0800, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.
> 
> In short, the existence of an exporter secret threatens the forward
> secrecy of any exported secret.  This is a problem for QUIC and is
> likely to be a more general problem.
> 
> The proposed fix is small: separate exporters into two steps
> (extract+expand) where the first step allows for separation based on
> exporter type and the second on context.  That allows an endpoint to
> keep separate secrets for each exporter type and discard those that it
> no longer needs, thus gaining forward secrecy if it likes.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From nobody Thu Feb 23 21:38: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 53FD4129552 for ; Thu, 23 Feb 2017 21:38:35 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 a7MqqJIobBz5 for ; Thu, 23 Feb 2017 21:38:33 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 A77EA1294B7 for ; Thu, 23 Feb 2017 21:38:33 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id k4so8358995otc.0 for ; Thu, 23 Feb 2017 21:38:33 -0800 (PST)
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=EKTq9eA2A9NrU2GUrxWmmLy+hBv/6DXaKuE0HLGXNDg=; b=sPIY8NsV9ZWlfKSYWXPtnoObZ1Iw6JWQIQzhekkJ4gUXq2ffJ4iXamvPdpJ1w41fCJ +Agvm+rPpdzeT5b++JfISELX1+9iAITXpOgi5XJxTAElKsiRmwHeUJm7acTGoloB+Ntm koGB1v9w7S9Gw17u+JQ1vD4d1JO/K39o2ipx/rOOx4GlvmDujpPH7un6GAovZmVA3Zdu SSyvoJ2FtrO+ZzLr5NyLxvxl3U0CltWuEugRlke1Wh7OPKdRbbW7/6TixpfO+1/NxXLu BDOkoyRGY6u4bO44c4epPqZO+qFwHU2KdW7F3QGeEVDT1DzKysHOrrg94xSGPMnCL3v2 aYlg==
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=EKTq9eA2A9NrU2GUrxWmmLy+hBv/6DXaKuE0HLGXNDg=; b=VQOS1icr+Mnqk0b9FKNto81fgs0zVR09WywzrqdQDDxRTfqDJYsXw3ryiM+GBaf8ee M0bg8CuYFSrN7Jl9cVIoWPHH5F4e8IRA8wik85G8FQCgIqZB2d2iq88hYd6evQQu4mlk RKW0C3raiX4UCLXe0GhKoTExDH5PWxQ+j2erVMkARHuiBW/5FqFGTK4LEKNwrKFRCLeu xidhIHvq0VO7xl8/v5bgd9rKW7wQPO31gouJ5esGYfYmYQItzlh367ZUuwfF/djedOYB ZhYm5Te+++ivFD44BiW8rtRlS/jrhMdrbsYJINzkfESqsdTE431xzteqzglkQnEkCMxr cWbA==
X-Gm-Message-State: AMke39koOR67FMLItJ5vU8BVzV5tVijYqyv38puuvJtjUTDmdWztiy6WAlEymzyIJT3G/BnfjMZnAEtEe6U8ag==
X-Received: by 10.157.40.144 with SMTP id s16mr596350ota.146.1487914712977; Thu, 23 Feb 2017 21:38:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.47.210 with HTTP; Thu, 23 Feb 2017 21:38:12 -0800 (PST)
In-Reply-To: <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>
From: Joseph Salowey 
Date: Thu, 23 Feb 2017 21:38:12 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113de472ec69260549402354
Archived-At: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 05:38:35 -0000

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

The difference between what is defined in 1.3 and this document is the 256
bit CCM cipher suites.   The document does not specify cipher suites for
TLS 1.3.

Is it important for TLS 1.3 to have support for these cipher suites?

If it is then we either need to add the cipher suites to this document or
to TLS 1.3.  At this point I would like to minimize the changes to 1.3,  so
I'm advocating that if the AES-256-CCM ciphers are necessary we update the
current document instead of TLS 1.3.  If the cipher suites are not
important then we should remove them from the document.

There is also confusion on what hash function to use with AES-256-CCM (it
seems it should be SHA384).



On Wed, Feb 22, 2017 at 9:11 AM, Ilari Liusvaara 
wrote:

> On Wed, Feb 22, 2017 at 08:04:13AM +0000, Salz, Rich wrote:
> > Why not just say
> >       The CCM cipher suites are not (currently) defined for TLS 1.3
> >
> > And leave it at that.  We're all quite proud of the fact, and
> > deservedly so, that we only have three ciphers defined for TLS 1.3.
> > Let's try to hold that position as long as possible.
>
> Well, AES-128-CCM with 8 and 16 byte tags does exist in editor's
> copy (0x1304 and 0x1305).
>
> No AES-256-CCM tho.
>
>
> -Ilari
>

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


The difference between what is defined in 1.3 and this doc=
ument is the 256 bit CCM cipher suites. =C2=A0 The document does not specif=
y cipher suites for TLS 1.3. =C2=A0

Is it important for =
TLS 1.3 to have support for these cipher suites? =C2=A0

If it is then we either need to add the cipher suites to this documen=
t or to TLS 1.3.=C2=A0 At this point I would like to minimize the changes t=
o 1.3, =C2=A0so I'm advocating that if the AES-256-CCM ciphers are nece=
ssary we update the current document instead of TLS 1.3.=C2=A0 If the ciphe=
r suites are not important then we should remove them from the document. =
=C2=A0

There is also confusion on what hash functi=
on to use with AES-256-CCM (it seems it should be SHA384). =C2=A0



<=
div class=3D"gmail_quote">On Wed, Feb 22, 2017 at 9:11 AM, Ilari Liusvaara =
<ilariliusvaara@welho.com> wrote:
On Wed, Feb 22, 2017=
 at 08:04:13AM +0000, Salz, Rich wrote:

> Why not just say

>=C2=A0 =C2=A0 =C2=A0 =C2=A0The CCM cipher suites are not (currently) de=
fined for TLS 1.3

>

> And leave it at that.=C2=A0 We're all quite proud of the fact, and=


> deservedly so, that we only have three ciphers defined for TLS 1.3.
> Let's try to hold that position as long as possible.




Well, AES-128-CCM with 8 and 16 byte tags does exist in editor&=
#39;s

copy (0x1304 and 0x1305).



No AES-256-CCM tho.





-Ilari





--001a113de472ec69260549402354--


From nobody Thu Feb 23 21:40: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 B0D0012956F for ; Thu, 23 Feb 2017 21:40:21 -0800 (PST)
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 aiN1eLsjaVq4 for ; Thu, 23 Feb 2017 21:40:20 -0800 (PST)
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 569A0129552 for ; Thu, 23 Feb 2017 21:40:20 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id n127so10974797qkf.0 for ; Thu, 23 Feb 2017 21:40:20 -0800 (PST)
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=mr4ewaGYIGU5fwxoVoxJM0edcSocTRYImDeuYDF2dSQ=; b=Y6ifAAzRH5y4Y7/AlZJFkyIxXdT5JW2J2DFyIgOfq7TvtXwj38GUOd+vS35AbptD9D HFkqxN8DJxpr10Onvq3Rj9Z1At6xe/ScDz0ehbIUAR+QtrtDAg99xcV1hrqoS3RLGzJ6 iXWJOBkZLp+6Gv8R5G/dSQY4UGjrlibM1/TljPqiWmn0Hhrl2YRC0Om8P1/zdaT913Pj ghslwIIfWuSjeM0xGHrizXua/OXnT1STK+IyztN1otawPNTs/RKDClrzgZrrAETpjQoV 88qDswgGCDYdk2EtJhkBQFnOZo2cGm1DKwWR4c/dy1om2WgNrNFikBwnJFF3ZPv/r8Vj 4TvA==
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=mr4ewaGYIGU5fwxoVoxJM0edcSocTRYImDeuYDF2dSQ=; b=lqIdUP8nVpkUTyOdhodkH9iqc0EBkBoN9thhyxroLKrQ+8G9LUDwqhzKBCSfC6T3rS cuUHwmNCb6iXoA3/CwI8ceJ8na43jWv6kkzQpoTKhARRIAapideqEp8W5CWpbiH9Az9m RUvZaaZUxvX7x4Y6CjAwb46cGY3BC/Nyfl51m2Sd2NqZy7syMXYIlIMORa3IWPzQO89r RITrv8+ONfyFO+/WwCIL4wLCji5LMP+4LVPOLdh+1Jo6o9EWFx4UI4yJTPVQD5HzBlpY wH8Xhm1BjB1P5KMAp6Hu7ljbqg0uZ2LsFVfM/mLtTd7C3HAjyDvNAZ0GeJ1n/gFd6nds /5qg==
X-Gm-Message-State: AMke39m+pGWufNmIQKeks22h9rI0iPbv1lpT/cTpGmTgBcogz8l+bEfPzwU0lHVpov6cGHe6Dmoe+DqdTWDZeg==
X-Received: by 10.55.151.7 with SMTP id z7mr957132qkd.316.1487914819552; Thu, 23 Feb 2017 21:40:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Thu, 23 Feb 2017 21:40:19 -0800 (PST)
In-Reply-To: <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de>
References:  <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de>
From: Martin Thomson 
Date: Fri, 24 Feb 2017 16:40:19 +1100
Message-ID: 
To: =?UTF-8?Q?Felix_G=C3=BCnther?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 05:40:21 -0000

On 24 February 2017 at 16:01, Sean Turner  wrote:
> So this isn=E2=80=99t entirely novel right I mean we did something simila=
r wrt other key schedules?

I certainly hope it isn't novel.  I'm just applying the same
technique: keep independent keys independent.

On 24 February 2017 at 16:09, Felix G=C3=BCnther  wrote:
> just to clarify: you add an additional HKDF.Expand step, not
> HKDF.Extract, right?

Yes, you are right, I should have said expand.  You need to use expand
to get the label-based separation on type.

I don't know how I got confused about that.  If we need to maintain
extract and expand in pairs (as we have already been burned by), then
I will defer to cryptographers on that.


From nobody Thu Feb 23 23:52: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 14AD31295F4 for ; Thu, 23 Feb 2017 23:52:49 -0800 (PST)
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 ZHBfhj3zZObY for ; Thu, 23 Feb 2017 23:52:47 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c: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 848941295F2 for ; Thu, 23 Feb 2017 23:52:47 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id v77so8171389wmv.0 for ; Thu, 23 Feb 2017 23:52:47 -0800 (PST)
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=OUYnZhxfFd9d8kAXMr+EQpGr/YhqIf2GMntkWmVa6dY=; b=p3q8gVtjw0ka6aNApRkKDKJUC1xA9odsPW2xaRyHma44XqEF4vV+8HACeploXDLXdg fYa42v3Z00h1b+S/q5qJ/nD9KR6NbwbC56bM1hMqDn2IigtvqLaKgI3B1/NXryY+txVs a5H0kJi50KQDU9qoPPPLPH0E3UY7AemdJmSWHS9I+MakEXP9cjjs7QR9Oli9CeYZxPfk JCnhej+O2P7mY10Hd9bReGwcDFWTHwyXwX34bLdiWjAHZ/Rns0ch2EhnwI30DwCQTJDq 5VNvOsWFMLx9CTsvuADlyp5U9QkDu1d32kU8dT0DyQY1R6YrEb9OU2kLJ4tANuKxoedR kR2g==
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=OUYnZhxfFd9d8kAXMr+EQpGr/YhqIf2GMntkWmVa6dY=; b=n5OEuQrG+4xtW/5zlkn++QbcFewOYVwuoCRwT/AsZ9uF38JcRqFnoZuEVWsJSn8A5n dYpxA0T+rOtqQugGTw4QXInYLwStEfjN5yL1DgTQYhI+AYqAWr/olp8YyMT7FBBkFbat JXZOlrE3LENxtEmhibyS0aeSNI7/x3mQUZ2uz2Ia2jYmHh3z6Bz1AVwOuo6W1hKJx7iu XNlZT/WcQY/2nrSsskdStJ/Kipp0vTAYTbAJekbbogQjnOaminBs0DhkgOlyyMQYk2Jf Nn1obAQGNnqEjlHg1nRs9iec0BrZHeCiQvJkVAOtwsklQG+4FEWoJPdBMV5jRuLI6pOt AxFw==
X-Gm-Message-State: AMke39mzF3tXoAkgNLXCYsFzhJ/7fnhJXrLk6LaxmkTGl4wuwRWoGv0lIU0ln4L6n67cHw==
X-Received: by 10.28.6.210 with SMTP id 201mr1400668wmg.85.1487922765939; Thu, 23 Feb 2017 23:52:45 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 17sm9275031wru.16.2017.02.23.23.52.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 23:52:44 -0800 (PST)
From: Yoav Nir 
Message-Id: <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F45E1918-3D96-4AAE-B3E9-76534874B0C2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Fri, 24 Feb 2017 09:52:41 +0200
In-Reply-To: 
To: Joseph Salowey 
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi> 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 07:52:49 -0000

--Apple-Mail=_F45E1918-3D96-4AAE-B3E9-76534874B0C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 24 Feb 2017, at 7:38, Joseph Salowey  wrote:
>=20
> The difference between what is defined in 1.3 and this document is the =
256 bit CCM cipher suites.   The document does not specify cipher suites =
for TLS 1.3.
>=20
> Is it important for TLS 1.3 to have support for these cipher suites?
>=20
> If it is then we either need to add the cipher suites to this document =
or to TLS 1.3.  At this point I would like to minimize the changes to =
1.3,  so I'm advocating that if the AES-256-CCM ciphers are necessary we =
update the current document instead of TLS 1.3.

I=E2=80=99d like to push back on that. It=E2=80=99s literally adding one =
or two lines (do we need a 256-bit version with an 8-byte tag?) to a =
table in Appendix A.4. The alternative is to make this document apply to =
1.3.

Assuming 256-bit AES-CCM suites are needed, I think the better place to =
put them is in the TLS 1.3 document.

Yoav

--Apple-Mail=_F45E1918-3D96-4AAE-B3E9-76534874B0C2
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-----

iQEcBAEBCgAGBQJYr+ZKAAoJELhJCxUKWMyZGbMH+wVDk4UsUZSFjbvHeyruJmXD
mJzFUc6r9DfU7sPdXP1JZgc+5bZTkujrf4rZY10PlTIevPAUaeROSI/4NOIY7o78
KL5Tvfpf3NaGx/3jW/KWsPpt7r95RjaGpNd0xgAZjd3g3hXAOX2sy8ZOVykAKXtq
fFGyl3B8TH0UYAO8IEUD/Ka64L3HxmGObR7qvAaRv+94aHknjNt7mwbb2yce4LjY
ikjG605+o38Owl8bnCDHJmv20DdMUk+WED54X6XDtsJaMFFNn73Uc1dFCSmVuB3p
I4BF576t+CyJRCmKJXkJkAL0Y2N9/RAWI52dJy/gc1QwWbI75jf3Pji8bc9pYmo=
=kR+J
-----END PGP SIGNATURE-----

--Apple-Mail=_F45E1918-3D96-4AAE-B3E9-76534874B0C2--


From nobody Fri Feb 24 02:02: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 AD21D12956A for ; Fri, 24 Feb 2017 02:02:15 -0800 (PST)
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 HTYRGnC61Mky for ; Fri, 24 Feb 2017 02:02:13 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2B12949A for ; Fri, 24 Feb 2017 02:02:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 46F821D75E; Fri, 24 Feb 2017 12:02:10 +0200 (EET)
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 D1hCMC4WQoLu; Fri, 24 Feb 2017 12:02:06 +0200 (EET)
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 206EBC4; Fri, 24 Feb 2017 12:02:06 +0200 (EET)
Date: Fri, 24 Feb 2017 12:02:02 +0200
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20170224100201.GA10341@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de> 
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: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 10:02:16 -0000

On Fri, Feb 24, 2017 at 04:40:19PM +1100, Martin Thomson wrote:
> On 24 February 2017 at 16:01, Sean Turner  wrote:
> > So this isn’t entirely novel right I mean we did something similar wrt other key schedules?
> 
> I certainly hope it isn't novel.  I'm just applying the same
> technique: keep independent keys independent.

This technique seems to assume there is some fixed known set of exporter
labels that are used. Since if you don't know the full set, you need to
keep the master exporter secret around anyway.

> On 24 February 2017 at 16:09, Felix Günther  wrote:
> > just to clarify: you add an additional HKDF.Expand step, not
> > HKDF.Extract, right?
> 
> Yes, you are right, I should have said expand.  You need to use expand
> to get the label-based separation on type.
> 
> I don't know how I got confused about that.  If we need to maintain
> extract and expand in pairs (as we have already been burned by), then
> I will defer to cryptographers on that.

The creator of HKDF stated that HKDF should always be used with paired
extracts and expands and any derpartion from that should be done with
utmost care.


Both the existing design and this design fail this: Because exporter
secrets are of expanded type, you would need to extract them, and
derive-secret is expansion type operation.

Note that passing label as salt is definitely very bad idea, since you
will get trivial collisions due to how HKDF works internally. And
doing so even with hash might be a bad idea.



-Ilari


From nobody Fri Feb 24 06:07: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 41ECA1297CB for ; Fri, 24 Feb 2017 06:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 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, 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 doVXD9IECmg1 for ; Fri, 24 Feb 2017 06:07:21 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 91A451297AC for ; Fri, 24 Feb 2017 06:07:21 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 14F6016C788; Fri, 24 Feb 2017 14:07:21 +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 F2FDE16BE9A; Fri, 24 Feb 2017 14:07:20 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487945241; bh=6Bp6TB+qReeiBaMawGJvnKy5Qvn9clTQxI6nbYg25yE=; l=350; h=From:To:CC:Date:References:In-Reply-To:From; b=toiPNGTbaqsStMnev5ED9kVWsHySJ7xsE9puvz6V/wkAJQmxQw+S1lesKz8DWGouY WP6vGYmnT4nLnesehz0ynk+KXjz2x53FKgC25N2iuswezKOQo/rESoFRet1TraOeJj aeLRC269CNxq9zsSrSGg8Qcfd56HC54tLo2bHK3M=
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id D53D61E08C; Fri, 24 Feb 2017 14:07:20 +0000 (GMT)
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.1178.4; Fri, 24 Feb 2017 09:07:20 -0500
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.1178.000; Fri, 24 Feb 2017 09:07:20 -0500
From: "Salz, Rich" 
To: Yoav Nir , Joseph Salowey 
Thread-Topic: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
Thread-Index: AQHSjG+AlPI2FEigPUqrjf2oARXzl6F06JEA///CuVCAAO0yAIACYtYAgAAlk4CAABSvIA==
Date: Fri, 24 Feb 2017 14:07:19 +0000
Message-ID: <91c7562e92814e3a9ebb57dfa6c59610@usma1ex-dag1mb1.msg.corp.akamai.com>
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>  <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.com>
In-Reply-To: <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.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.33.176]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 14:07:24 -0000

PiBBc3N1bWluZyAyNTYtYml0IEFFUy1DQ00gc3VpdGVzIGFyZSBuZWVkZWQsIEkgdGhpbmsgdGhl
IGJldHRlciBwbGFjZSB0byBwdXQNCj4gdGhlbSBpcyBpbiB0aGUgVExTIDEuMyBkb2N1bWVudC4N
Cg0KVGhhdCdzIGEgcmVhbGx5IGJpZyBhc3N1bXB0aW9uLiA7KQ0KDQpJIHRoaW5rIHRoZSBidXJk
ZW4gaXMgb24gZm9sa3MgdG8gKnByb3ZlKiAoeWVhaCwgSSBrbm93KSB0aGF0IGFkZGl0aW9uYWwg
Y2lwaGVyIHN1aXRlcyBhcmUgbmVlZGVkLg0K


From nobody Fri Feb 24 06:55: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 61C6E129854 for ; Fri, 24 Feb 2017 06:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 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, 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 D0K61KYVeOB1 for ; Fri, 24 Feb 2017 06:55:32 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 682DE129697 for ; Fri, 24 Feb 2017 06:55:32 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E793943343E; Fri, 24 Feb 2017 14:55:30 +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 D693A43340C; Fri, 24 Feb 2017 14:55:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487948130; bh=gr7KHq8Gb+UHPZpnQ/khxJtP/tz7t/O2B8d69wCs3Jc=; l=308; h=From:To:CC:Date:References:In-Reply-To:From; b=OmgN8IWinQuirTX7RbYhJ/evNGJdjSLZwYuCeVW4q7FznOMLZaxh5a25dfkKmrchM lJvowoZGH2b256ZWEpsgQjZfqaHJLqOrs3vsc8EE9/aA0mI0Iaotr2OpexXZu1mAJC Dj1rM6ly8LORpT4jIsi+AOL1+BcmN9f3yWnNKgcA=
Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id CCE421FC88; Fri, 24 Feb 2017 14:55:30 +0000 (GMT)
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.1178.4; Fri, 24 Feb 2017 09:55:30 -0500
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.1178.000; Fri, 24 Feb 2017 09:55:30 -0500
From: "Salz, Rich" 
To: William Whyte 
Thread-Topic: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
Thread-Index: AQHSjG+AlPI2FEigPUqrjf2oARXzl6F06JEA///CuVCAAO0yAIACYtYAgAAlk4CAABSvIIAAYOOA//+sl6A=
Date: Fri, 24 Feb 2017 14:55:30 +0000
Message-ID: <92ffd8e65f444cfca784689198590b21@usma1ex-dag1mb1.msg.corp.akamai.com>
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>  <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.com> <91c7562e92814e3a9ebb57dfa6c59610@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.33.176]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 14:55:33 -0000

PiBUaGVyZSdzIGFuIGFyZ3VtZW50IHRoYXQgaXQncyB3b3J0aCBidWlsZGluZyBpbiBhIDI1Ni1i
aXQgY2lwaGVyIGZvciBxdWFudHVtIHJlc2lzdGFuY2UuIE5vdCBjbGVhciB0aGF0IEFFUy0yNTYg
aXMgdGhlIGJlc3QgMjU2LWJpdCBjaXBoZXIgdGhvdWdoLg0KDQpZZXMsIEkgZ2V0IHRoYXQuDQoN
CiJub3QgY2xlYXIiIGlzIGEgaGlnaGx5IHVuY29tcGVsbGluZyBhcmd1bWVudCwgdGhvLg0K


From nobody Fri Feb 24 08:48: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 AC0EC127735 for ; Fri, 24 Feb 2017 08:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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=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 f7RwCWcroX-g for ; Fri, 24 Feb 2017 08:48:03 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002: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 B6ECE1270B4 for ; Fri, 24 Feb 2017 08:48:03 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id d88so6639547ybi.0 for ; Fri, 24 Feb 2017 08:48:03 -0800 (PST)
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=AOH4WSNxfhmAQIHt5n7vvAKyA4lgCQOjQr2SzrP8NWQ=; b=OmedPecSGzXLd2x0OpJNioDjAPTn/SPOG6OP9VWu556qZWwPuVBMlD68mCKAPjXgNe bsRrIqEIT0r90y6y0mTLabYc4EoJIUK7qNelDDCb+ycl4BO7xUNL48SVq4ZOFhEfTfFK gDw3pwW7re7rxM4BS4DWpDGT2cmn74PcgsaDj7eBdrhXNX8xLUojTmw4UjZQ4IU5Pqi2 Q0phD3y0T8+OEt92vihTHsfzuicwX1ZARwodpkmY9MXVpoXivM1hC5X4LDz/DhaYC9rw m/TXr7sAb6M43qOvLcQQadNuOlp1K69WU/YGAY6r8yzwM0Y/kgRB9C5W8VaoBGWu+c/4 nvKg==
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=AOH4WSNxfhmAQIHt5n7vvAKyA4lgCQOjQr2SzrP8NWQ=; b=JoaorSVAdmiLCafIfT/p9euTuv67F8Cg1+IRKjEpsCUma8rLs1GPlnmEZsu61Wzt56 eoXIVR++M9Bf9opr9Q3wgaacNCpMSXJzUR/kbzKL6fziyVcNzQONMYiAzc5PlPXe2UVH dvcP7ZTjb8/MMI3W78GSOAatiD2M9UphvGfhTQYhOi6LnVcD+Pl6ywUfXgs/IL35rQmP yHtfrvoiBxtGjTlZKVhSZa5fVkz5VN9vVT/b3+4yaQdlDbjLmv9FaRCGlwxrTUDX89Xk M8h5Dh35VIOAT0fguMaeIn/GoL2SfPIpWfsKpIxADtulUbLVrM8h/8bwc1UcAAPU/COg +WMw==
X-Gm-Message-State: AMke39kaAPDawhGrxN7zOd+J12nECJOMTDIDSZiFT0gWTsXVy5cVSFTF1SGzIQ9nRfpq1Ri7VSOf7aiLeYWvoQ==
X-Received: by 10.37.45.37 with SMTP id t37mr2164985ybt.177.1487954882628; Fri, 24 Feb 2017 08:48:02 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.37.49.9 with HTTP; Fri, 24 Feb 2017 08:47:32 -0800 (PST)
In-Reply-To: 
References:  <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de> 
From: Hugo Krawczyk 
Date: Fri, 24 Feb 2017 11:47:32 -0500
X-Google-Sender-Auth: BFhmapWIRwQtBNrf7aaxUR5_hbQ
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=94eb2c1b0d5639534d0549497e76
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 16:48:05 -0000

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

Martin,

Which of these two derivation schemes are you proposing?
Are you assuming that all uses of the exporter_secret are known at the end
of
the handshake? If not, you still need to keep an exporter_secret beyond the
handshake.

Master Secret
      |
      |
      +-----> Derive-Secret(., "exporter master secret 1",
      |                     ClientHello...Server Finished)
      |                     =3D exporter_secret_1
      |
      +-----> Derive-Secret(., "exporter master secret 2",
                            ClientHello...Server Finished)
                            =3D exporter_secret_2

Or:

Master Secret
      |
      |
      +-----> Derive-Secret(., "exporter master secret",
                            ClientHello...Server Finished)
                            =3D exporter_secret
                                 |
                                 +-----> Derive-Secret(., "exporter secret
1",
                                 |                     what_exactly)
                                 |                     =3D exporter_secret_=
1
                                 |
                                 |
                                 +-----> Derive-Secret(., "exporter secret
2",
                                                       what_exactly)
                                                       =3D exporter_secret_=
2


(I wrote "what exactly" since I am not sure what do you plan to include
there.)

Regarding Ilari's comment on HKDF pairings, I have said that an Extract
operation needs to always be followed by an Expand operation, but an expand
operation may be followed by an expand operation. The point is that the
output
of Expand is (typically) intended as a key to another cryptographic
function.
Such function can be HKDF-Expand itself (which is just a specific
implementation
of a variable-length input/output PRF).

Thus, both of the above possible derivations are OK from the point of view
of HKDF.

Hugo


On Fri, Feb 24, 2017 at 12:40 AM, Martin Thomson 
wrote:

> On 24 February 2017 at 16:01, Sean Turner  wrote:
> > So this isn=E2=80=99t entirely novel right I mean we did something simi=
lar wrt
> other key schedules?
>
> I certainly hope it isn't novel.  I'm just applying the same
> technique: keep independent keys independent.
>
> On 24 February 2017 at 16:09, Felix G=C3=BCnther 
> wrote:
> > just to clarify: you add an additional HKDF.Expand step, not
> > HKDF.Extract, right?
>
> Yes, you are right, I should have said expand.  You need to use expand
> to get the label-based separation on type.
>
> I don't know how I got confused about that.  If we need to maintain
> extract and expand in pairs (as we have already been burned by), then
> I will defer to cryptographers on that.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


=
Martin,

Which of these two d=
erivation schemes are you proposing?
Are you assuming that all uses of th=
e exporter_secret are known at the end of
the handshake? If not, you stil=
l need to keep an exporter_secret beyond the
handshake.

Master S=
ecret
=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=
=A0 +-----> Derive-Secret(., "exporter master secret 1",
=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 ClientHello...Server Finished)
=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 =3D expo=
rter_secret_1
=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 +-----> De=
rive-Secret(., "exporter master secret 2",
=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 ClientHello...Server Finished)
=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 =3D exporter_se=
cret_2

Or:

Master Secret
=C2=A0 =C2=A0 =C2=A0 |<=
/div>
=C2=
=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 +-----> Derive-Secret(., &quo=
t;exporter master secret",
=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 ClientHello...Serv=
er Finished)
=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 =3D exporter_secret
=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|
<=
font face=3D"monospace, monospace">=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+-----> Derive-Secret(., "exporter secret 1",
=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 what_exactly)
=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 =3D exporter_secret_1
=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+-----> Derive-Secret(., "exp=
orter secret 2",
=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=A0wh=
at_exactly)
=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=3D exporter_=
secret_2


(I wrote "what exactly" since I am not =
sure what do you plan to include there.)

Regarding Ilari's com=
ment on HKDF pairings, I have said that an Extract
operation needs to a=
lways be followed by an Expand operation, but an expand
operation may be =
followed by an expand operation. The point is that the output
<=
div class=3D"gmail_default">of Expand i=
s (typically) intended as a key to another cryptographic function.=C2=A0
=
Such function can be HKDF-Expand itself (which is just a specific implement=
ation
of a variable-length input/output PRF).

Thus, both of the =
above possible derivations are OK from the point of view of HKDF.

=

Hugo

=


On Fri, Feb=
 24, 2017 at 12:40 AM, Martin Thomson <martin.thomson@gmail.com=
> wrote:
On 24=
 February 2017 at 16:01, Sean Turner <=
sean@sn3rd.com> wrote:

> So this isn=E2=80=99t entirely novel right I mean we did something sim=
ilar wrt other key schedules?



I certainly hope it isn't novel.=C2=A0 I'm just applying the=
 same

technique: keep independent keys independent.



On 24 February 2017 at 16:09, Felix G=C3=BCnther <guenther@cs.tu-darmstadt.de> wrote:

> just to clarify: you add an additional HKDF.Expand step, not

> HKDF.Extract, right?



Yes, you are right, I should have said expand.=C2=A0 You need to use=
 expand

to get the label-based separation on type.



I don't know how I got confused about that.=C2=A0 If we need to maintai=
n

extract and expand in pairs (as we have already been burned by), then

I will defer to cryptographers on that.




_______________________________________________

TLS mailing list

TLS@ietf.org

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





--94eb2c1b0d5639534d0549497e76--


From nobody Fri Feb 24 09:42: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 41F6C12943F for ; Fri, 24 Feb 2017 09:42:48 -0800 (PST)
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 BdwHGShnmBDO for ; Fri, 24 Feb 2017 09:42:22 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD71129445 for ; Fri, 24 Feb 2017 09:42:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 72B001F315; Fri, 24 Feb 2017 19:42:19 +0200 (EET)
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 uZ4SnRlH5adz; Fri, 24 Feb 2017 19:42:19 +0200 (EET)
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 34DFDC4; Fri, 24 Feb 2017 19:42:19 +0200 (EET)
Date: Fri, 24 Feb 2017 19:42:15 +0200
From: Ilari Liusvaara 
To: Hugo Krawczyk 
Message-ID: <20170224174215.GA13873@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de>  
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: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 17:42:48 -0000

On Fri, Feb 24, 2017 at 11:47:32AM -0500, Hugo Krawczyk wrote:
> Martin,
> 
> Which of these two derivation schemes are you proposing?
> Are you assuming that all uses of the exporter_secret are known at the end
> of
> the handshake? If not, you still need to keep an exporter_secret beyond the
> handshake.
> 
> Master Secret
>       |
>       |
>       +-----> Derive-Secret(., "exporter master secret 1",
>       |                     ClientHello...Server Finished)
>       |                     = exporter_secret_1
>       |
>       +-----> Derive-Secret(., "exporter master secret 2",
>                             ClientHello...Server Finished)
>                             = exporter_secret_2
> 
> Or:
> 
> Master Secret
>       |
>       |
>       +-----> Derive-Secret(., "exporter master secret",
>                             ClientHello...Server Finished)
>                             = exporter_secret
>                                  |
>                                  +-----> Derive-Secret(., "exporter secret
> 1",
>                                  |                     what_exactly)
>                                  |                     = exporter_secret_1
>                                  |
>                                  |
>                                  +-----> Derive-Secret(., "exporter secret
> 2",
>                                                        what_exactly)
>                                                        = exporter_secret_2
> 
> 
> (I wrote "what exactly" since I am not sure what do you plan to include
> there.)

I interpretted it to be something like follows:

Master secret
 + Derive-Secret(label="exporter master secret", context=ClientHello...ServerFinished)
    + Derive-Secret(label=EXPORTER-FOO, context=)
      + Derive-Secret(label="exporter", context=)
      + Derive-Secret(label="exporter", context=)
    + Derive-Secret(label=EXPORTER-BAR, context=)
      + Derive-Secret(label="exporter", context=)
      + Derive-Secret(label="exporter", context=)


But I don't know how useful that would be, as it requires knowing all
labels one is going to use (or one needs to keep EMS around anyway).


-Ilari


From nobody Fri Feb 24 09:59: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 92B0E129452 for ; Fri, 24 Feb 2017 09:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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, SPF_PASS=-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 b9JcBV3FTDqi for ; Fri, 24 Feb 2017 09:59:34 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 23B8E124281 for ; Fri, 24 Feb 2017 09:59:34 -0800 (PST)
Received: by mail-oi0-x235.google.com with SMTP id s205so14225203oif.3 for ; Fri, 24 Feb 2017 09:59:34 -0800 (PST)
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=22JJLewZp0jPgmCdpv41yg+71E2RcvcAemFB3EmOiPQ=; b=dA2+7LuSZR0MXp56BbQk9z5alq0wHNUDOa0Fjbu6JwmergAUkx2SG4A+NDL5vyl2sb Rb08sk6xAajqSur1FI9xg8XIcXOjnq3RHc7UsfRbprJeJ1jZm1w+IbVnA+RedsDFDEvX lr7MmSWKvPQqJhvlLrmRZxA+fY3z8SDqi0cplbzvHnckbTSu1fNF+kXBwm3lWsnjWRVh 7oBiRZ4l63VVCVv3jN14L/j2sXEH6i537MpT7jk1Aux+GBOIUgYjzjipE/O40kOtKh/E 5jPDTWjTCGbjLA8Un0LZQ5MRdEB5V0zJFtxqYoH86t4JbM4r/MST/+O0zFTxcGTyfsLq fWzQ==
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=22JJLewZp0jPgmCdpv41yg+71E2RcvcAemFB3EmOiPQ=; b=FxThmPWkU9hdRSZ5DHuKqPQNjERdaIdo8/PgkAhnmk8zN6SkuGZz6B7KGmtIA5Eqnt FhWGoItO2DSqS51l/JEAwtH0y4N2/PKmiVA/bYQpeIArIveEFNA7qIdjsFkWuSA57eBQ niKtl06DC2ju9EE0NK9ToFzwSwd4s9+HDY/hV2IcffwwBjqhek+Uyp7WEI1UpUEPrZIY J1ysGAvWMspwHcoPnKkeqKvDZ3mA8LsE3Q7CB/Faj0p+h4kjZKu7xW4QXd98QvMhVsF0 LzHKBiQ3VYDUL8za8dCkfNfvocLTsLwQOEmodtNiL2lRfq3bQJos+wlDiH6/DVJL1YFQ Imlw==
X-Gm-Message-State: AMke39mNo9zsCQMYDUomaQGCJxw+LwzQxvdCekUrU4tVHqhasiE+JFDjKuxQWVL7HE/1zACx0lR9LQ/9qESUjg==
X-Received: by 10.202.178.11 with SMTP id b11mr2326862oif.101.1487959173486; Fri, 24 Feb 2017 09:59:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.47.210 with HTTP; Fri, 24 Feb 2017 09:59:13 -0800 (PST)
In-Reply-To: 
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>  <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.com> <91c7562e92814e3a9ebb57dfa6c59610@usma1ex-dag1mb1.msg.corp.akamai.com>  <92ffd8e65f444cfca784689198590b21@usma1ex-dag1mb1.msg.corp.akamai.com> 
From: Joseph Salowey 
Date: Fri, 24 Feb 2017 09:59:13 -0800
Message-ID: 
To: William Whyte 
Content-Type: multipart/alternative; boundary=001a113cd284f9f09305494a7db1
Archived-At: 
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 17:59:35 -0000

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

TLS 1.3 currently has AES-256-GCM and ChaCha20-Poly1305 as 256-bit
ciphers.  AES-CCM ciphers are more oriented towards an IOT niche where CCM
is implemented for lower layer protocols.  I'm not sure if there are
implementations of AES-256-CCM or AES-256-CCM_8  in use.

Joe

On Fri, Feb 24, 2017 at 7:12 AM, William Whyte 
wrote:

> Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher
> as part of the core TLS 1.3 family of techniques, but I don't feel strongly
> that it should be AES-256. ChaCha?
>
> Cheers,
>
> William
>
> On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich  wrote:
>
>> > There's an argument that it's worth building in a 256-bit cipher for
>> quantum resistance. Not clear that AES-256 is the best 256-bit cipher
>> though.
>>
>> Yes, I get that.
>>
>> "not clear" is a highly uncompelling argument, tho.
>>
>
>

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


TLS 1.3 currently has AES-256-GCM and ChaCha20-Poly1305 as=
 256-bit ciphers.=C2=A0 AES-CCM ciphers are more oriented towards an IOT ni=
che where CCM is implemented for lower layer protocols.=C2=A0 I'm not s=
ure if there are implementations of AES-256-CCM or AES-256-CCM_8=C2=A0 in u=
se. =C2=A0

Joe
On Fri, Feb 24, 2017 at 7:12 AM, William Whyte =
<wwhyte@onboardsecurity.com> wrote:
Right. I fee l strongly that it'd =
be wise to bless a single 256-bit cipher as part of the core TLS 1.3 family=
 of techniques, but I don't feel strongly that it should be AES-256. Ch=
aCha?

Cheers,

William

On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich <rsalz=
@akamai.com> wrote:
&=
gt; There's an argument that it's worth building in a 256-bit ciphe=
r for quantum resistance. Not clear that AES-256 is the best 256-bit cipher=
 though.



Yes, I get that.



"not clear" is a highly uncompelling argument, tho.








--001a113cd284f9f09305494a7db1--


From wwhyte@onboardsecurity.com  Fri Feb 24 07:12: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 F22FB129C51 for ; Fri, 24 Feb 2017 07:12:40 -0800 (PST)
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, HTML_MESSAGE=0.001, 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=onboardsecurity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuL0LeLVR8PX for ; Fri, 24 Feb 2017 07:12:39 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c: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 613691296B0 for ; Fri, 24 Feb 2017 07:12:39 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id v186so16885971wmd.0 for ; Fri, 24 Feb 2017 07:12:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o8415lhJ8SAGpk/tiq7sCURHgUXdn6WHQcVsG5jeiIM=; b=TDWG01uF3pHQr1yP4dgv9eUCv1xcz+ZAnlRlpQvGMKuUu6DBhUoEiJHg++F+x6g4av Z+fOhtxv0Q1faXkNqxP5ougK1bk7ZdtKqpkU7SauT7ZcJR3i5/yNc0DyKKsvOSlHY+Ce sPHwKxDFLdf2Ek4EkGW/CZ0g6V/bzHyGi+EPs=
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=o8415lhJ8SAGpk/tiq7sCURHgUXdn6WHQcVsG5jeiIM=; b=WpP9Bvfu47nx83Skmgt3rya83R9K50QiMIi2xoLBeVQF4/KU4vNSSztb2isqKteXkQ 8x0/BaVRv4xifhfsjhp96xxVLBqqwoBSy5fdweznyRD8O+hZO5wg0XW10Nm5D6jgd1Gt oSZlsJVtCG0UKn4LRX71mPHkJZQN3GDK2lb7bqz3qVQtv5W5oDcqo3gbbDyL7947OUVH 1ArckyGKozZojpr7uWTEBaKlfr9/A2B8Hh3kM7IqJYD5btjxojYvn8S4G5t5HfgThI0D pCC1+cmxQqvVqhsn6rMsUiZGOaQj7OV3/F32LeDRChmHCjQ/rPj+/XHILmNiEG5Pnimd bC0A==
X-Gm-Message-State: AMke39kkC/7g87Q4qddrAcs4mIj1+N2lAeBgCTaSoG2gynbJCJoO7yzBROfukTg499sf1Jy/sS1KKGMLLaYlAw==
X-Received: by 10.28.144.135 with SMTP id s129mr3127437wmd.18.1487949157784; Fri, 24 Feb 2017 07:12:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.187.132 with HTTP; Fri, 24 Feb 2017 07:12:17 -0800 (PST)
In-Reply-To: <92ffd8e65f444cfca784689198590b21@usma1ex-dag1mb1.msg.corp.akamai.com>
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>  <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.com> <91c7562e92814e3a9ebb57dfa6c59610@usma1ex-dag1mb1.msg.corp.akamai.com>  <92ffd8e65f444cfca784689198590b21@usma1ex-dag1mb1.msg.corp.akamai.com>
From: William Whyte 
Date: Fri, 24 Feb 2017 10:12:17 -0500
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a1145ad88fe77a90549482894
Archived-At: 
X-Mailman-Approved-At: Fri, 24 Feb 2017 10:03:15 -0800
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 15:13:46 -0000

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

Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher
as part of the core TLS 1.3 family of techniques, but I don't feel strongly
that it should be AES-256. ChaCha?

Cheers,

William

On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich  wrote:

> > There's an argument that it's worth building in a 256-bit cipher for
> quantum resistance. Not clear that AES-256 is the best 256-bit cipher
> though.
>
> Yes, I get that.
>
> "not clear" is a highly uncompelling argument, tho.
>

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


Right. I fee l strongly that it'd be wise to bless a s=
ingle 256-bit cipher as part of the core TLS 1.3 family of techniques, but =
I don't feel strongly that it should be AES-256. ChaCha?

=

Cheers,

William

On Fri, Feb 24, 2017 at 9:55 AM, Sa=
lz, Rich <rsalz@akamai.com> wrote:
> There's an argument that it's worth=
 building in a 256-bit cipher for quantum resistance. Not clear that AES-25=
6 is the best 256-bit cipher though.



Yes, I get that.



"not clear" is a highly uncompelling argument, tho.





--001a1145ad88fe77a90549482894--


From wwhyte@onboardsecurity.com  Fri Feb 24 06:53: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 48ECE129854 for ; Fri, 24 Feb 2017 06:53:54 -0800 (PST)
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, HTML_MESSAGE=0.001, 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=onboardsecurity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcHl2Nqjorau for ; Fri, 24 Feb 2017 06:53:52 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 3667A129697 for ; Fri, 24 Feb 2017 06:53:52 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id r141so16417664wmg.1 for ; Fri, 24 Feb 2017 06:53:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zX9bLwGLCIm7u35fuSV/kpc+X5wkiKQMeSV1IS1fbcY=; b=gkMGmuM7ZvC5arn0e8OZyilYPoXT9JYsIIhROoCEMR6pLLzkcj6trRT3wdGspsn7G1 hVc2D+gp+JA1s0nuPjD5kwXmpSXlv3wYZXZahWpDZhJIFQu67dsk4M7XAoHFn1IARo0z 3aXGHYYz+Mz8qci4W+bMR2394k6OQ/qfAJtaQ=
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=zX9bLwGLCIm7u35fuSV/kpc+X5wkiKQMeSV1IS1fbcY=; b=NpwaykqJes4IU564v2tbVUDiyLJO1lHXgI32sJNQxoNIlAp5QyNBCBMgo5qvcBGAvk hqgHYd+7y5qE8OK5lx1cS/d1vRz/6qgHFD2jKMzLTKLRdgCY3mQ8lJjR8wMSi7luKgfk je0ldDBmKyy7E1QqUd2q9BhQZOholO/LAFYk/iqoe0PeRdPDS5deZYJKO9BfnFarmbNM bQG9rBDcAMhGfsF9vYPD2OLxxVAmT40kYlBg9f/kwLh8M8niOvwVcxz7hjif6isjbbb4 mDwjCXU9uQGNqlDOSP9P84WCW1HebQvYh6p6NYkrKIwUWfAVXAGVxghBEAb+Qwzolc7l C69w==
X-Gm-Message-State: AMke39kJAAbFZlnoTJBOR2FAtxUE8iuMtUOX8KH5h86gEA2XSAOpYLu5vjBzvkRntX1gkYQlLcWolNAFSqLGiw==
X-Received: by 10.28.91.209 with SMTP id p200mr2943264wmb.18.1487948030525; Fri, 24 Feb 2017 06:53:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.187.132 with HTTP; Fri, 24 Feb 2017 06:53:29 -0800 (PST)
In-Reply-To: <91c7562e92814e3a9ebb57dfa6c59610@usma1ex-dag1mb1.msg.corp.akamai.com>
References:    <20170222171156.GA31015@LK-Perkele-V2.elisa-laajakaista.fi>  <1CAE4CFE-2A9D-4A8D-93D4-2BA304894F96@gmail.com> <91c7562e92814e3a9ebb57dfa6c59610@usma1ex-dag1mb1.msg.corp.akamai.com>
From: William Whyte 
Date: Fri, 24 Feb 2017 09:53:29 -0500
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a11443ad8cdf26a054947e590
Archived-At: 
X-Mailman-Approved-At: Fri, 24 Feb 2017 10:03:16 -0800
Cc: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 15:14:05 -0000

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

There's an argument that it's worth building in a 256-bit cipher for
quantum resistance. Not clear that AES-256 is the best 256-bit cipher
though.

William

On Fri, Feb 24, 2017 at 9:07 AM, Salz, Rich  wrote:

> > Assuming 256-bit AES-CCM suites are needed, I think the better place to
> put
> > them is in the TLS 1.3 document.
>
> That's a really big assumption. ;)
>
> I think the burden is on folks to *prove* (yeah, I know) that additional
> cipher suites are needed.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


There's an argument that it's worth building in a =
256-bit cipher for quantum resistance. Not clear that AES-256 is the best 2=
56-bit cipher though.

William

On Fri, Feb 24, 2017 at 9:07 AM,=
 Salz, Rich <rsalz@akamai.com> wrote:
> Assuming 256-bit AES-CCM suites are needed=
, I think the better place to put

> them is in the TLS 1.3 document.



That's a really big assumption. ;)



I think the burden is on folks to *prove* (yeah, I know) that additional ci=
pher suites are needed.


______________________________=
_________________

TLS mailing list

TLS@ietf.org

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





--001a11443ad8cdf26a054947e590--


From nobody Sat Feb 25 06:28: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 8E0AA129FF6 for ; Sat, 25 Feb 2017 06:28:50 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 1_iq1RqJpXZH for ; Sat, 25 Feb 2017 06:28:43 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0139.outbound.protection.outlook.com [23.103.201.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15892129FE1 for ; Sat, 25 Feb 2017 06:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Od3Ef4DCLz8hNSHvVNx4JVtf0Mky28hWGoN9Y+UJaF0=; b=0euVVzJtewUt/61bEEikJmV8WCKJ2Oa0ELUIbJVpXQhm7dSBC0wapO/IC6WmZNUBAq7d1oh1a77edOWvSwmM9nn3avLVnnuG0r4DXOcaANKPRkl9hx1R0SBf4o/u3ZsSnwmt4nbs27mJ1nzmaFPJD4Q4kgirxQ5nxL0rRG0FNDA=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Sat, 25 Feb 2017 14:28:40 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0919.020; Sat, 25 Feb 2017 14:28:40 +0000
From: "Dang, Quynh (Fed)" 
To: Sean Turner , "" 
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1A==
Date: Sat, 25 Feb 2017 14:28:40 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.222.69]
x-ms-office365-filtering-correlation-id: f4717a3b-d5fa-4dc8-7c92-08d45d8a9830
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:aFdcPV0BTTlXJbSHfbMQU4d5FIcE57SmcmMXLypSaAfsDrXI2ss3tQGU4ehsxoiTtYPluFI9XNxIqqRWYlLo6hYl41Jw+JXst0MhQFbHAP5se+UJmUAWXQMp8y2qjZQpGuWJb3eXlDpJxYEziF3lKUwTabUsHoKYu5itf5FtA7y04OlyJXvr0mlOSqVdsd1qAjcAenEcqxmPM2g/yhD5sjEe+die/s/P9su4gXFMUc42cgHzFIQcSp6x+4UAOkGoezL0s9hWzVyio4/Wdi7DiOL/gQERAOqlPHlcfAItiiZFQGCAFFGAJ0CuaAGVLQJ9fDgHraDrJkasNdTOUewFbA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(20161123555025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; 
x-forefront-prvs: 02296943FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(189002)(199003)(377454003)(102836003)(5660300001)(3846002)(2950100002)(6116002)(81166006)(6436002)(6506006)(53936002)(19627405001)(7906003)(7696004)(74316002)(7736002)(229853002)(68736007)(2900100001)(8676002)(81156014)(8936002)(86362001)(97736004)(92566002)(54356999)(76176999)(50986999)(55016002)(99286003)(77096006)(38730400002)(105586002)(106116001)(53546006)(101416001)(106356001)(122556002)(6246003)(3280700002)(6606003)(606005)(4326007)(66066001)(2906002)(25786008)(189998001)(33656002)(3660700001)(236005)(9686003)(54896002)(6306002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2017 14:28:40.3925 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464
Archived-At: 
Cc: IRTF CFRG 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2017 14:28:50 -0000

--_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Sean, Joe, Eric and all,


I would like to address my thoughts/suggestions on 2 issues in option a.


1) The data limit should be addressed in term of blocks, not records. When =
the record size is not the full size, some user might not know what to do. =
When the record size is 1 block, the limit of 2^24.5 blocks (records) is wa=
y too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-bl=
ock records is the limit which still achieves the margin of 2^-60.


2) To achieve the margin of 2^-57 as the current text says, the limit numbe=
r should be 2^36 blocks.


Regards,

Quynh.


________________________________
From: Cfrg  on behalf of Sean Turner 
Sent: Friday, February 10, 2017 12:07 AM
To: 
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable










Hi Sean, Joe, Eric and all,







I would like to address my thoughts/suggestions on 2 issues in option a.=
 







1) The data limit should be addressed in term of blocks, not records. Wh=
en the record size is not the full size, some user might not know what to d=
o. When the record size is 1 block, the limit of 2^24.5 blocks (records) is=
 way too low unnecessarily for the
 margin of 2^-60.  In that case, 2^34.5 1-block records is the limit w=
hich still achieves the margin of 2^-60. 







2) To achieve the margin of 2^-57 as the current text says, the limit nu=
mber should be 2^36 blocks.







Regards,


Quynh. 












From: Cfrg <cfrg-bounc=
es@irtf.org> on behalf of Sean Turner <sean@sn3rd.com>

Sent: Friday, February 10, 2017 12:07 AM

To: <tls@ietf.org>

Cc: IRTF CFRG

Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" P=
Rs (#765/#769)

 







All,



We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, t=
hese limits have been discussed a couple of times and we need to resolve on=
ce and for all whether the TLS WG wants to:



a) Close these two PRs and go with the existing text [0]

b) Adopt PR#765 [1]

c) Adopt PR#769 [2]



Please indicate you preference to the TLS mailing list before Feb 17. =
 Note that unless there=92s clear consensus to change the text will remain =
as is (i.e., option a).



J&S



[0] 
https://tlswg.github.io/tls13-spec/#rfc.section.5.5

[1] 
https://github.com/tlswg/tls13-spec/pull/765

[2] 
https://github.com/tlswg/tls13-spec/pull/769

_______________________________________________

Cfrg mailing list

Cfrg@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg










--_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_--


From nobody Sun Feb 26 16:21: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 DDE5412987B for ; Sun, 26 Feb 2017 16:21:32 -0800 (PST)
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 CArFuu6dGpTq for ; Sun, 26 Feb 2017 16:21:31 -0800 (PST)
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 BC2A412984F for ; Sun, 26 Feb 2017 16:21:31 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id n127so75206509qkf.0 for ; Sun, 26 Feb 2017 16:21:31 -0800 (PST)
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=+UFiHaes1dnswrOxhIwJpKMB0N3hEjCSjfONXy5Tz1Q=; b=OzcZBvPQS5FT+hrgWW8/1syIdRj02Qw8JHgu2i3WtBM145ZNx7mnRxFDJ0jc+ky+OE jAzAoZIZmw/7TFIaxScLZ7Qo/bI9CrsxpW3Ehd4+hklX/HJcykBnldDlcopNMU3Iqvvq MylfkjnGocQUptgLtXXDFqFHwg4UA1ViaYk6CcGWJ4XbWr6ymPfKgqNKgafYl4ckRKRd B0AAIYD41+9rqw+YojLlqWPWMD5Kt5fXTCEj+ESqgp9lf62P+PmB/s77MRZgtCUn91Ue B4y9spCS8tH27J0lCB3LyHFyR0T4x0A37LH/hkwJyDrjam36SewgRt6bNZMXvfbByUvR M4Sg==
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=+UFiHaes1dnswrOxhIwJpKMB0N3hEjCSjfONXy5Tz1Q=; b=oxZZhUGKiWIAQPMLMrLPEUQuaf6ps7pEBgCNNRzIhrqtqVeb/zxwHHYXnCZXyRO+F5 k2YBxQ6YxuWph+aIfxZeD7bFJFvJheF/SMCDNoZWEcL6guSCZR4Q0cAPiXCxyg5wcCdN jq6vq9zJ5TCr3p9MjsTTRB9nJMFsoRHyf9v4Cqx+MgKHPbTuUd1F8zV2J3eT4S2rq3cC y4c149m1TwJAzcHVKAN3/5NStzLHc5Ikg2YQX2AnXcD0db4GMAHVv4jp61zD0RiwC2Pc P80+LKHmIGqrYMV/EMuaj29zgVxfyrdPdt0EUF2CDBo2v6EG8WcELCqDP14Je77UfExU oWsg==
X-Gm-Message-State: AMke39kww1RrtfX6eFuePEnDNsxI8hNvfJ2s0FwX3DbHCBAsPaUT7j3+I9VUzAhukf6EPVPfCS9M/Bh0GHW+nQ==
X-Received: by 10.200.3.214 with SMTP id z22mr14033636qtg.3.1488154890959; Sun, 26 Feb 2017 16:21:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 26 Feb 2017 16:21:30 -0800 (PST)
In-Reply-To: <20170224100201.GA10341@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de>  <20170224100201.GA10341@LK-Perkele-V2.elisa-laajakaista.fi>
From: Martin Thomson 
Date: Mon, 27 Feb 2017 11:21:30 +1100
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 00:21:33 -0000

On 24 February 2017 at 21:02, Ilari Liusvaara  wrote:
> This technique seems to assume there is some fixed known set of exporter
> labels that are used. Since if you don't know the full set, you need to
> keep the master exporter secret around anyway.

This is correct.  I assume here that many applications know the set of
exporters that they support, since each generally requires code.  This
would not be a TLS-stack responsibility, but an application-layer one.


From nobody Sun Feb 26 16:28: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 6B8B41299E1 for ; Sun, 26 Feb 2017 16:28:13 -0800 (PST)
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 EBVGZz8tPSQk for ; Sun, 26 Feb 2017 16:28:12 -0800 (PST)
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 D28CF129549 for ; Sun, 26 Feb 2017 16:28:08 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id s186so75245205qkb.1 for ; Sun, 26 Feb 2017 16:28:08 -0800 (PST)
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=o9wfkEafEPUwESlgmeUXCUpI3RJLbFmBloSFzg2KbMc=; b=PgKcyRD/ogdAIh09EjCMhgHpxwY0OsVnlsHxp++ekS9uZQrwekv/vpWQFq+4662yPt b+7zBrTkUoleVF/CuW2Ln+p9mxlVSs2m60FzSVWaF6oYa7I7tunH7WKyYUwv+A0X2nfF mr3abiP3mrncYA9fkK5lSWymeOfnBeGSYXIi4yOFzS1VRQ5HAilxq8SsLQyiCDFAkmPM J/oeDUVKtgi3Fu6hIROa4wojCxlVFzgTGnI0iFYo7b3Jot5p5FyoXN3HRiLFY/sv5Ii+ 9DMJTp5EeluWX86Hutc752jkiGkhieIbfuWqhT7gPepsGYkRs4DLwRnY0wKKLcz597T7 Bu5Q==
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=o9wfkEafEPUwESlgmeUXCUpI3RJLbFmBloSFzg2KbMc=; b=MyFKeg3AxKxVira+pQ+z8Xaf0/Pf4nTCrFWCXPPMjwNxM0P9Aggp/mA1YUtXIUzyj/ Hqtk8UQQhGDWrZt+QIqyFFh7yOuSS2/cKZC0uTGyM+eUe41AsQw02g+5EQB12oLNE4en 39zohiECgfygih7SS3FigK7fT4t9Pmnrg6QsriDz8EFKojVL1/n7t0ep5aIHb+vnWDW7 TmzWuTJ+wjLgy2EM3C0hR0ApW2RABB2Y1diBMY4TBKAQbDYE4dSMhGA2SAGDcF4moWj0 wfrEfkZiSslIkME0HzNl1uxtMJKcQWQ20P9hg+FX0FjdbL38pa9ThJ9zQtIgWRsuXua0 HgUg==
X-Gm-Message-State: AMke39mRDgsy6sxfMviUBtuNokKhKq+Ajap2ktPHpM41VDALIWYTuwf5wru1yoCnFQlVR5DHaV3cvq/46U3J9Q==
X-Received: by 10.200.39.200 with SMTP id x8mr13092575qtx.159.1488155287922; Sun, 26 Feb 2017 16:28:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 26 Feb 2017 16:28:07 -0800 (PST)
In-Reply-To: 
References:  <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de>  
From: Martin Thomson 
Date: Mon, 27 Feb 2017 11:28:07 +1100
Message-ID: 
To: Hugo Krawczyk 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 00:28:13 -0000

Hi Hugo,



On 25 February 2017 at 03:47, Hugo Krawczyk  wrote:
> Martin,
>
> Which of these two derivation schemes are you proposing?

I mean the latter of your two, where you have effectively three layers
of HKDF-Expand from the master secret.

master secret -> exporter secret
exporter secret + exporter type (label) -> specific exporter secret[label]
exporter secret[label] + context -> exporter value

(Just like what Ilari said.)

I think that is easier for implementation reasons to manage.
Splitting off from the master secret allows implementations to defer
some of the exporter-related processing and decisions until later.

> Are you assuming that all uses of the exporter_secret are known at the end of
> the handshake? If not, you still need to keep an exporter_secret beyond the
> handshake.

Yes, this is correct.  This assumes that you know the *type* of all
exporters you might support.  I think that this is a reasonable
assumption since each exporter relies on implementing a specification
for that exporter and having code for it.  For example, you might have
a list of supported exporters, for which you could derive the
intermediate value.

> Thus, both of the above possible derivations are OK from the point of view
> of HKDF.

Thanks.  I thought that it was OK, but having you confirm that makes
me much happier.


From nobody Mon Feb 27 23:06: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 7822A1294D5 for ; Mon, 27 Feb 2017 23:06:20 -0800 (PST)
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 Sc3J6xiUm84P for ; Mon, 27 Feb 2017 23:06:19 -0800 (PST)
Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 35CD21293F4 for ; Mon, 27 Feb 2017 23:06:19 -0800 (PST)
Received: by mail-ot0-x22c.google.com with SMTP id i1so2268019ota.3 for ; Mon, 27 Feb 2017 23:06:19 -0800 (PST)
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=9q6sWfmoGGqK8Ff2cu22ShnaYRFqjXMcFlhlKYdIeBc=; b=FFBdTyf+oagRcZ2rWnBCl/7+XFCYpxN0J69rD/jZb5CDemWUSkDboHYwMfIF1/dsUo /Pasf6nzFLgQ/jMBBZPijydaRZyUiLR1R7o0aHzbyZAzRthCKdvSbnFPn/9NUVHROBhr dhhy2hwPddOgGNbTqbu2HCOAN3ULnLQig13wqoBlI1wQykPbxQTxq+3MeOJl7CdywmoF UR4/fQDaYfeUz6Uz4uY9PUr/2zfgqP8x10vuCrGVCXe4wh0mMvtCRgGm8GqhqToNGu0j fJx3NA5bo0uElK/w4P6JfEvBHSU3bZdDaGvnEB+SPaSypdivDS1vFsGxqGK50Ddd2yQM k6Aw==
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=9q6sWfmoGGqK8Ff2cu22ShnaYRFqjXMcFlhlKYdIeBc=; b=oTYLy4aRELfIxTSWyiHfrdMdUEJk0SmXS7UH36ER+FC+qF/47qDNJgyh2p6aG3Ds4b xDt8ZVHU3iqF65uqLYI0g6JqHj3eqK22gFUQeqCrD4elm7AYrJY+ebFiQVHrNhbwM1AN c67uiidgBfBmdJW9RujcQsljGnCeRLZeYouZOS7a+xN1GzAXi+lajeqRj5t1ksZL9/hE q6l5TK6wju7KuXYjI2cXsdSQOaPtn9h08UUr3hiC9nrb/raCYnd38yqErcsEcPWB82r3 +gHI73hNvS1s131Rg/nrpTomVVC1p39ZR8hrHrnuXH4sbp0BiOe5eCmns4Avn0wEzEEU Y2Wg==
X-Gm-Message-State: AMke39k+XVtpjZrU1ZLf/8NnUaCfIh+lhIHdr8oxM8bD1HFrrkCoNKmNluX1Q+3qJ5TKRKkPCzHzvXpF2+RWCg==
X-Received: by 10.157.11.211 with SMTP id 77mr390822oth.14.1488265578312; Mon, 27 Feb 2017 23:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.27.72 with HTTP; Mon, 27 Feb 2017 23:06:17 -0800 (PST)
From: Kazuho Oku 
Date: Tue, 28 Feb 2017 16:06:17 +0900
Message-ID: 
To: "" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] TLS 1.3: HRR vs. resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2017 07:06:20 -0000

Hi,

I recall that we have had discussions about how we should combine HRR
and resumption.

My feeling is that combining the two is a needless complication.

Instead, I believe that when a client attempts to resume a session
using psk_dhe_ke, then it should use the named group that was used in
the previous handshake (i.e. the handshake the client used for
establishing the connection from which it obtained the session
ticket).

It might be beneficial to state such advise in the specification, and
that there is no need for server implementors to take care of
resumption in case when sending HRR. Having such a guideline might
reduce the chance of us creating a vulnerability.

-- 
Kazuho Oku