From nobody Fri Dec 1 00:49: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 33F81127333 for ; Fri, 1 Dec 2017 00:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4D68NziZggX for ; Fri, 1 Dec 2017 00:49:51 -0800 (PST) Received: from esa3.dyson.c3s2.iphmx.com (esa3.dyson.c3s2.iphmx.com [68.232.139.42]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C2E126B7E for ; Fri, 1 Dec 2017 00:49:50 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8731"; a="25662285" X-IronPort-AV: E=Sophos;i="5.45,344,1508799600"; d="scan'208";a="25662285" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa3.dyson.c3s2.iphmx.com with ESMTP; 01 Dec 2017 09:03:09 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id D7FF7FA10; Fri, 1 Dec 2017 07:32:50 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id CB50CFA02; Fri, 1 Dec 2017 07:32:50 +0000 (GMT) Received: from UK-MAL-CAS-03.dyson.global.corp (10.1.108.111) by UK-MAL-CAS-02.dyson.global.corp (10.1.108.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 1 Dec 2017 08:49:32 +0000 Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-CAS-03.dyson.global.corp ([10.1.108.111]) with mapi id 14.03.0319.002; Fri, 1 Dec 2017 08:49:32 +0000 From: Tony Putman To: Katriel Cohn-Gordon CC: "tls@ietf.org" Thread-Topic: [TLS] New Version Notification for draft-putman-tls-preshared-ecdh-00.txt Thread-Index: AQHTafzmFrjATNGI7ku1Z80A/CPnz6MtLWfwgAAReICAAO4lgA== Date: Fri, 1 Dec 2017 08:49:32 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC0B036464@UK-MAL-MBOX-02.dyson.global.corp> References: <151206123390.4809.15953787972366154379.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC0B0363F0@UK-MAL-MBOX-02.dyson.global.corp> <1512066683.2703229.1189737376.36787A76@webmail.messagingengine.com> In-Reply-To: <1512066683.2703229.1189737376.36787A76@webmail.messagingengine.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] New Version Notification for draft-putman-tls-preshared-ecdh-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 08:49:53 -0000 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Katriel Cohn-Gordon > If you add the fourth (static-static) DH, you should be protected > against poor generation of ephemeral keys. Thanks, this sounds like a good idea. It can be precomputed (and stored if all comms is to a single server) so it doesn't slow down the actual protocol exchange. = I added the two static public keys into the premaster calculation as they a= re included in the Session Id definition in [Kudla]. I wonder if I can replace= them with the static-static computation, which seems (to me) to offer the same protection. -- = Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. From nobody Fri Dec 1 06:51:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972E126C3D for ; Fri, 1 Dec 2017 06:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnyhOEreQg7m for ; Fri, 1 Dec 2017 06:51:47 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29C1126B71 for ; Fri, 1 Dec 2017 06:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1512139903; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=8134; bh=xbLxN6mqZJXH++57/dGr4vO12DqoiF5QZEL//fGxCm0=; b=JsfDc4BVE2yAedlI/VBK5ZJtJ9vjre2gaCHld2nFDNncU8sIK6tWX83izXiEc5y/ 3utnyR7iekTQ/6wf/6mPjAlaa4bB3FC49K3x+pJuGSX9959m4W1jERFXpe1YqXB9it0 79iTiwCgma+Tij8uu0HS25lpdUAqjQx0HsWNRqRI= Received: from [10.253.10.77] (72.23.5.194 [72.23.5.194]) by mx.zohomail.com with SMTPS id 1512139901098613.6164486861028; Fri, 1 Dec 2017 06:51:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Fri, 01 Dec 2017 09:47:45 -0500 From: R du Toit To: Message-ID: Thread-Topic: TLS 1.3 draft 22 middlebox interaction Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3594966701_747600041" X-ZohoMailClient: External Archived-At: Subject: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2017 14:51:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3594966701_747600041 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I want to provide some feedback that might be useful to the TLS WG: Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org is triggering an interesting failure in at least one middlebox. The middlebox in question supports TLS 1.3, but only drafts 18 through 21. The FF Nightly ClientHello supported_versions extension advertises support for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox then interprets as only advertising support for TLS 1.2, ignoring the 0x7f16 as if it is a "grease" value. The middlebox only perfoms protocol checks and does not actually modify anything - the session completes without any issues, which shows that the draft 22 middlebox measures are effective. FF Nightly then starts a resumed TLS 1.3 (draft 22) session that includes 0-RTT early data. The middlebox performs a protocol check on the ClientHello and determines that the client is trying to negotiate TLS 1.2 (per the logic of the first session). Shortly afterwards the 0-RTT AppData record arrives, which then triggers a protocol error in the middlebox. "D.3. 0-RTT backwards compatibility" of the draft 22 specification describes the problem, but in the context of "older server" bei ng "only supports up to TLS 1.2". This particular middlebox can also be thought of as "older" because it only supports TLS 1.3 drafts 18 through 21. Obviously the middlebox will soon have support for draft 22, but it does raise some questions: 1. I understand that some of these transition effects will go away as soon as draft support is replaced with actual 0x0304 support, but were 0-RTT sessions used in the recent TLS 1.3 middlebox resiliency experiments? The scenario above shows that some middleboxes might (by luck?) not break full TLS 1.3 sessions, but those same middleboxes might fail with subsequent 0-RTT early data. 2. Should middleboxes that understand the supported_versions extension get out of the loop immediately (as in ignore traffic after ClientHello) when it sees 0x7fNN, where NN is larger than the highest draft version supported by the middlebox? How would that be different from other "grease" values? I understand that this might just be a temporary measure until 0x7fXX goes away (hopefully soon!). 3. Is there a plan for phasing out draft support once TLS 1.3 is finalized as RFC? Servers can stop supporting 0x7fxx as soon as 0x0304 is ready, but what should a middlebox do if 0x7fxx is seen post RFC? --Roelof --B_3594966701_747600041 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I wan= t to provide some feedback that might be useful to the TLS WG:  Firefox= Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org is triggeri= ng an interesting failure in at least one middlebox.

 

The middlebox in question = supports TLS 1.3, but only drafts 18 through 21.  The FF Nightly Client= Hello supported_versions extension advertises support for T= LS 1.2 and TLS 1.3 (draft 22), which the middlebox then interprets as only a= dvertising support for TLS 1.2, ignoring the 0x7f16 as if it is a "grea= se" value.  The middlebox only perfoms protocol checks and does no= t actually modify anything - the session completes without any issues, which= shows that the draft 22 middlebox measures are effective.  FF Nightly = then starts a resumed TLS 1.3 (draft 22) session that includes 0-RTT early d= ata.  The middlebox performs a protocol check on the ClientHello and de= termines that the client is trying to negotiate TLS 1.2 (per the logic of th= e first session).  Shortly afterwards the 0-RTT AppData record arrives,= which then triggers a protocol error in the middlebox.   "D.= 3. 0-RTT backwards compatibility" of the draft 22 specification describ= es the problem, but in the context of "older server" being "o= nly supports up to TLS 1.2".  This particular middlebox can also b= e thought of as "older" because it only supports TLS 1.3 drafts 18= through 21.

 

Obviously the middlebox will soon have support for draft 22, but i= t does raise some questions:

 

1. I understand that some of these transition effe= cts will go away as soon as draft support is replaced with actual 0x0304 sup= port, but were 0-RTT sessions used in the recent TLS 1.3 middlebox resilienc= y experiments?  The scenario above shows that some middleboxes might (b= y luck?) not break full TLS 1.3 sessions, but those same middleboxes might f= ail with subsequent 0-RTT early data.

=  

2. Should middleboxes that understand the=  supported_versions extension get out of the loop immediate= ly (as in ignore traffic after ClientHello) when it sees 0x7fNN, where NN is= larger than the highest draft version supported by the middlebox?  How= would that be different from other "grease" values?   I= understand that this might just be a temporary measure until 0x7fXX goes aw= ay (hopefully soon!).

 

=

3. Is there a plan for phasing out draft support once TLS= 1.3 is finalized as RFC?  Servers can stop supporting 0x7fxx as soon a= s 0x0304 is ready, but what should a middlebox do if 0x7fxx is seen post RFC= ?

 

<= o:p> 

--Roelof

<= /html> --B_3594966701_747600041-- From nobody Fri Dec 1 07:18: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 D583E1293F3 for ; Fri, 1 Dec 2017 07:18:51 -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 WcE6f12ARfw4 for ; Fri, 1 Dec 2017 07:18:44 -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 C69B21293EE for ; Fri, 1 Dec 2017 07:18:43 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id g191so4147378ywe.7 for ; Fri, 01 Dec 2017 07:18:43 -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=567P87Ee+4zCJLbWd0ZyiLgVzNlxGEgh30j+GyyrO9w=; b=1x/UtIAccmIbmNQFle3eK1mZncxqWTucGg0faR3VssDASoUVwkPnSNaVJ4sopjuYFR o43zoq3w9zvEgg8Rq46t9dxaTd7Tg/EoPF8R+HAdRqb1fgU+AFFevyGIEnHlhMCV3rnZ oouWfHcbpFaKM/CvGLA8TyMvpxudJ3rgmZkmKKZC2C7bRipmU0GSwAaHkuyMm6H/DTih wZpvC2WUzlfB3SYdJkj1DP5If9sX0BF4jvOrRyuSAPLJs95dqMr8LrtMEJJLKGATlGOx EXF24ozMaFArhvNmWKPf9IRMnn84kf0hdUzbU3SReuaCL/kX6xI4idGDwl1E9apyEuUv LxSA== 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=567P87Ee+4zCJLbWd0ZyiLgVzNlxGEgh30j+GyyrO9w=; b=SHmqqQlYvkC0cxhMT3PTSdQCSxv4JICD+zRqgX0uSAF7RBwrcgUTIcYshsqKZeKZDo ENixiiukbL4pMl+h5SUPtSGGjR4q1J5aa025CitNDVUgmbNqrlIJ0WjPCO2581QWJ106 2RnJvzylwoVUDRitTxQFo4+eaK23baZdeJX3Sjn7yLKbpsw+PVz20zSK/tDpmJR+i12Z sVetZz7f2LOZxxqR2nYntTCUg/b88afvdXSTJDh0L9kiKUYszdv8Kc6nT6GShRvcxTav nNGw3b4l9eJyBsVGi0iKHtPKzHZgsZmd0gooITDRu59A6xtCm4mH7wN454GFFKrrwpuC 4kCA== X-Gm-Message-State: AJaThX4UJ83O4pIyefwMa5bv2/ZRatbsMmswW/ydsk8Hv0uBhTOguLQQ tTnlOkkiG8jKegUNA43IBvgg33zU8O4VmkrTDl+1M0rF X-Google-Smtp-Source: AGs4zMZxlWsfZnCJ/mIWMydzRbFj1KvKHlzef7s05gHXP9WoXPUEFjKqZmoh+MJOKShg7n5nCMkJgln7hXTb7vLVW9g= X-Received: by 10.129.222.9 with SMTP id k9mr4212769ywj.47.1512141522932; Fri, 01 Dec 2017 07:18:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 1 Dec 2017 07:18:02 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 1 Dec 2017 07:18:02 -0800 Message-ID: To: R du Toit Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403043d0488532b70055f48e221" Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2017 15:18:52 -0000 --f403043d0488532b70055f48e221 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 1, 2017 at 6:47 AM, R du Toit wrote: > I want to provide some feedback that might be useful to the TLS WG: > Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org > is triggering an interesting failure in at least one middlebox. > > > > The middlebox in question supports TLS 1.3, but only drafts 18 through > 21. The FF Nightly ClientHello *supported_versions* extension advertises > support for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox then > interprets as only advertising support for TLS 1.2, ignoring the 0x7f16 as > if it is a "grease" value. The middlebox only perfoms protocol checks and > does not actually modify anything - the session completes without any > issues, which shows that the draft 22 middlebox measures are effective. FF > Nightly then starts a resumed TLS 1.3 (draft 22) session that includes > 0-RTT early data. The middlebox performs a protocol check on the > ClientHello and determines that the client is trying to negotiate TLS 1.2 > (per the logic of the first session). Shortly afterwards the 0-RTT AppData > record arrives, which then triggers a protocol error in the middlebox. > "D.3. 0-RTT backwards compatibility" of the draft 22 specification > describes the problem, but in the context of "older server" being "only > supports up to TLS 1.2". This particular middlebox can also be thought of > as "older" because it only supports TLS 1.3 drafts 18 through 21. > > > > Obviously the middlebox will soon have support for draft 22, but it does > raise some questions: > > > > 1. I understand that some of these transition effects will go away as soon > as draft support is replaced with actual 0x0304 support, but were 0-RTT > sessions used in the recent TLS 1.3 middlebox resiliency experiments? The > scenario above shows that some middleboxes might (by luck?) not break full > TLS 1.3 sessions, but those same middleboxes might fail with subsequent > 0-RTT early data. > We haven't been testing that. I do expect to see some 0-RTT bustage, but falling back to a full handshake at that point isn't a security issue, and so can be handled in the conventional reconnect way. We (Firefox) also are looking at testing for middlebox compat explicitly and turning off features like 0-RTT and TFO (which we already see problems with) if needed. 2. Should middleboxes that understand the *supported_versions* extension > get out of the loop immediately (as in ignore traffic after ClientHello) > when it sees 0x7fNN, where NN is larger than the highest draft version > supported by the middlebox? How would that be different from other > "grease" values? I understand that this might just be a temporary measure > until 0x7fXX goes away (hopefully soon!). > First, they shouldn't look at #s. Second, it depends what kind if middlebox you are. If you're a protocol enforcing middlebox (ugh, these shouldn't exist) you should get out of the way. If you're a MITM device you should just negotiate a lower version. > 3. Is there a plan for phasing out draft support once TLS 1.3 is finalized > as RFC? Servers can stop supporting 0x7fxx as soon as 0x0304 is ready, but > what should a middlebox do if 0x7fxx is seen post RFC? > I would expect people to just signal the RFC version relatively shortly after RFC. That's what we (Firefox) plans to do. -Ekr > > > > --Roelof > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403043d0488532b70055f48e221 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <r@nerd.ninja> wrot= e:

I want to provide some feedback that might = be useful to the TLS WG:=C2=A0 Firefox Nightly TLS 1.3 (draft 22) sessions = to tls13.cryp= to.mozilla.org is triggering an interesting failure in at least one mid= dlebox.

=C2=A0

The middlebox in question supports TLS 1.3, but only dr= afts 18 through 21.=C2=A0 The FF Nightly ClientHello=C2=A0supported_vers= ions=C2=A0extension advertises support for TLS 1.2 and TLS 1.3 (dr= aft 22), which the middlebox then interprets as only advertising support fo= r TLS 1.2, ignoring the 0x7f16 as if it is a "grease" value.=C2= =A0 The middlebox only perfoms protocol checks and does not actually modify= anything - the session completes without any issues, which shows that the = draft 22 middlebox measures are effective.=C2=A0 FF Nightly then starts a r= esumed TLS 1.3 (draft 22) session that includes 0-RTT early data.=C2=A0 The= middlebox performs a protocol check on the ClientHello and determines that= the client is trying to negotiate TLS 1.2 (per the logic of the first sess= ion).=C2=A0 Shortly afterwards the 0-RTT AppData record arrives, which then= triggers a protocol error in the middlebox.=C2=A0=C2=A0 "D.3. 0-RTT b= ackwards compatibility" of the draft 22 specification describes the pr= oblem, but in the context of "older server" being "only supp= orts up to TLS 1.2".=C2=A0 This particular middlebox can also be thoug= ht of as "older" because it only supports TLS 1.3 drafts 18 throu= gh 21.

=C2=A0

Obviously the middlebox will soon have support for draft= 22, but it does raise some questions:

=C2=A0

1. I understand that som= e of these transition effects will go away as soon as draft support is repl= aced with actual 0x0304 support, but were 0-RTT sessions used in the recent= TLS 1.3 middlebox resiliency experiments?=C2=A0 The scenario above shows t= hat some middleboxes might (by luck?) not break full TLS 1.3 sessions, but = those same middleboxes might fail with subsequent 0-RTT early data.


We haven't been testing that. = I do expect to see some 0-RTT bustage, but falling back to a full handshake= at that point isn't a security issue, and so can be handled in the con= ventional reconnect way. We (Firefox) also are looking at testing for middl= ebox compat explicitly and turning off features like 0-RTT and TFO (which w= e already see problems with) if needed.


=

2. Should middleboxes that understand the=C2=A0= supported_versions=C2=A0extension get out of the loop immediate= ly (as in ignore traffic after ClientHello) when it sees 0x7fNN, where NN i= s larger than the highest draft version supported by the middlebox?=C2=A0 H= ow would that be different from other "grease" values?=C2=A0=C2= =A0 I understand that this might just be a temporary measure until 0x7fXX g= oes away (hopefully soon!).


First, they shouldn't look at #s. Second, it depends what kind if midd= lebox you are. If you're a protocol enforcing middlebox (ugh, these sho= uldn't exist) you should get out of the way. If you're a MITM devic= e you should just negotiate a lower version.

=C2= =A0

3. Is there a plan for phasing out draft= support once TLS 1.3 is finalized as RFC?=C2=A0 Servers can stop supportin= g 0x7fxx as soon as 0x0304 is ready, but what should a middlebox do if 0x7f= xx is seen post RFC?


I woul= d expect people to just signal the RFC version relatively shortly after RFC= . That's what we (Firefox) plans to do.

-Ekr

=C2=A0

=C2=A0<= /u>

--Roelof


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


--f403043d0488532b70055f48e221-- From nobody Fri Dec 1 08:35:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8D128A32 for ; Fri, 1 Dec 2017 08:35:09 -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, 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 (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 H3DFFbycZZnX for ; Fri, 1 Dec 2017 08:35:07 -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 BF06A126DCA for ; Fri, 1 Dec 2017 08:35:06 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id u10so13714874qtg.2 for ; Fri, 01 Dec 2017 08:35:06 -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=fJXiuNTC+7DOLowHNz+EuBroaw+apoIRscn8La75nlk=; b=Ki7bOLeuC6fJS9moPrck0+koT+C8RlvRKqs7m7pmVyBYMs7nOZWVXD2cdaqEERfyKT zMJBz6sMPmGvBiz6Q0brasESl+x4/28hCWpmZbU+ePqy66aTVeGlmyzX8t9EWGR/e05W j4lZjp1+0tGsFFrRlNrExSEwo06RdhEKZVv1k= 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=fJXiuNTC+7DOLowHNz+EuBroaw+apoIRscn8La75nlk=; b=MuM7D5cGBX8kf0IfEJ1ru239cA5j8lXX5TPeOhe2TWScqNPa4gfLKVWycnnNaPhoqN tiTTKLZWxWeMdRKv2GszSlZoL6vcxDfCNgwpM/mY6Lc+Nl9h/wMjt4JGD0u8FuUcw4ms aDnVld8JF5o5YLzhiqzSLpVbrUbiaZaMjbqyzDkHimmOcuTeGNsubkrTVP0FQaQW9XUV Jxs+RXUcKfCEYRXLR4qVE7DzH6MluFhHMbA5VyrQjjlU1x0pV9YNZ4SkMnz6EMjbrfnU D9pfARSwQeGh8b0U8La9rl8qSKf684QkZdS43XoYbIYM5T1JjLnyqZq60ouYhz3HjBh8 68xQ== X-Gm-Message-State: AKGB3mLrbqeLvdbm1VJvC6So68MUzKG/1hqynoawdno9dnMS4HZrtEFP D5ydYwzbY3NIE8ot3a2k82+1HSbzFj06yG1cUsBY X-Google-Smtp-Source: AGs4zMaS5b+a76YspUjHqcjCdoSenY+3jtVp2G8qF/mHxbG9M5aOrZQ3P71uCzFIdt0M5xza8YlbH4fOpN5+1TdY4eQ= X-Received: by 10.237.37.177 with SMTP id x46mr9848770qtc.76.1512146105551; Fri, 01 Dec 2017 08:35:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 01 Dec 2017 16:34:53 +0000 Message-ID: To: Eric Rescorla Cc: R du Toit , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113fe8b278f83f055f49f36e" Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2017 16:35:10 -0000 --001a113fe8b278f83f055f49f36e Content-Type: text/plain; charset="UTF-8" On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla wrote: > On Fri, Dec 1, 2017 at 6:47 AM, R du Toit wrote: > >> I want to provide some feedback that might be useful to the TLS WG: >> Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org >> is triggering an interesting failure in at least one middlebox. >> >> >> >> The middlebox in question supports TLS 1.3, but only drafts 18 through >> 21. The FF Nightly ClientHello *supported_versions* extension >> advertises support for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox >> then interprets as only advertising support for TLS 1.2, ignoring the >> 0x7f16 as if it is a "grease" value. The middlebox only perfoms protocol >> checks and does not actually modify anything - the session completes >> without any issues, which shows that the draft 22 middlebox measures are >> effective. FF Nightly then starts a resumed TLS 1.3 (draft 22) session >> that includes 0-RTT early data. The middlebox performs a protocol check on >> the ClientHello and determines that the client is trying to negotiate TLS >> 1.2 (per the logic of the first session). Shortly afterwards the 0-RTT >> AppData record arrives, which then triggers a protocol error in the >> middlebox. "D.3. 0-RTT backwards compatibility" of the draft 22 >> specification describes the problem, but in the context of "older server" >> being "only supports up to TLS 1.2". This particular middlebox can also be >> thought of as "older" because it only supports TLS 1.3 drafts 18 through 21. >> >> >> >> Obviously the middlebox will soon have support for draft 22, but it does >> raise some questions: >> >> >> >> 1. I understand that some of these transition effects will go away as >> soon as draft support is replaced with actual 0x0304 support, but were >> 0-RTT sessions used in the recent TLS 1.3 middlebox resiliency >> experiments? The scenario above shows that some middleboxes might (by >> luck?) not break full TLS 1.3 sessions, but those same middleboxes might >> fail with subsequent 0-RTT early data. >> > > We haven't been testing that. I do expect to see some 0-RTT bustage, but > falling back to a full handshake at that point isn't a security issue, and > so can be handled in the conventional reconnect way. We (Firefox) also are > looking at testing for middlebox compat explicitly and turning off features > like 0-RTT and TFO (which we already see problems with) if needed. > > > 2. Should middleboxes that understand the *supported_versions* extension >> get out of the loop immediately (as in ignore traffic after ClientHello) >> when it sees 0x7fNN, where NN is larger than the highest draft version >> supported by the middlebox? How would that be different from other >> "grease" values? I understand that this might just be a temporary measure >> until 0x7fXX goes away (hopefully soon!). >> > > First, they shouldn't look at #s. Second, it depends what kind if > middlebox you are. If you're a protocol enforcing middlebox (ugh, these > shouldn't exist) you should get out of the way. If you're a MITM device you > should just negotiate a lower version. > > > >> 3. Is there a plan for phasing out draft support once TLS 1.3 is >> finalized as RFC? Servers can stop supporting 0x7fxx as soon as 0x0304 is >> ready, but what should a middlebox do if 0x7fxx is seen post RFC? >> > > I would expect people to just signal the RFC version relatively shortly > after RFC. That's what we (Firefox) plans to do. > To answer your question more directly, as EKR noted above, post-RFC and pre-RFC, middleboxes should not behave differently for 0x0304, 0x7fxx, 0x1234, or 0x0305. If you did not terminate the connection, you don't get to parse variant-dependent fields. Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reign to change everything past the ServerHello again. Or perhaps we'll design a new cipher suite or extension that changes things. New capabilities may be signaled by the client anywhere in the ClientHello. Recall that past TLS 1.2 extensions have injected new messages in the handshake and changed the format of the Certificate message. Adding ECDHE and PSK cipher suites changed how ClientKeyExchange and ServerKeyExchange worked. Earlier drafts of TLS 1.3 completely changed the handshake. I started writing some text on version invariants to make these rules clearer. They were the assumed rules in TLS 1.2, but draft-22 reflects that the network did not honor them. I'll finish that up and make a PR. I do not believe writing this in text will be sufficient, but it is evidently necessary. TLS's versioning invariants are quite simple: if you are not terminating the TLS connection (i.e. the ClientHello was not produced by you), you MUST NOT process any message beyond the ClientHello. If you produced the ClientHello, you can reasonably expect to understand the response and can act as an endpoint does. Any middleware violating this invariant is non-compliant and at risk of breaking as endpoints and the protocol evolve. Alas, this was insufficiently GREASEd from SSL 3.0 through TLS 1.2, so we had to grandfather in existing violations via draft 22. Future violations, however, continue to be non-compliant and you should expect them to break, and quite rapidly as draft-22 shows we need more ideas in the vein of GREASE. David --001a113fe8b278f83f055f49f36e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 1,= 2017 at 10:18 AM Eric Rescorla <ekr@rtf= m.com> wrote:
On Fri, Dec 1, 201= 7 at 6:47 AM, R du Toit <r@nerd.ninja> wrote:

I want to provide some feedback that might b= e useful to the TLS WG:=C2=A0 Firefox Nightly TLS 1.3 (draft 22) sessions t= o tls13.crypt= o.mozilla.org is triggering an interesting failure in at least one midd= lebox.

=C2=A0

The middlebox in question supports TLS 1.3, but only dra= fts 18 through 21.=C2=A0 The FF Nightly ClientHello=C2=A0supported_versi= ons=C2=A0extension advertises support for TLS 1.2 and TLS 1.3 (draft 22= ), which the middlebox then interprets as only advertising support for TLS = 1.2, ignoring the 0x7f16 as if it is a "grease" value.=C2=A0 The = middlebox only perfoms protocol checks and does not actually modify anythin= g - the session completes without any issues, which shows that the draft 22= middlebox measures are effective.=C2=A0 FF Nightly then starts a resumed T= LS 1.3 (draft 22) session that includes 0-RTT early data.=C2=A0 The middleb= ox performs a protocol check on the ClientHello and determines that the cli= ent is trying to negotiate TLS 1.2 (per the logic of the first session).=C2= =A0 Shortly afterwards the 0-RTT AppData record arrives, which then trigger= s a protocol error in the middlebox.=C2=A0=C2=A0 "D.3. 0-RTT backwards= compatibility" of the draft 22 specification describes the problem, b= ut in the context of "older server" being "only supports up = to TLS 1.2".=C2=A0 This particular middlebox can also be thought of as= "older" because it only supports TLS 1.3 drafts 18 through 21.

=C2=A0

Obviously the middlebox will soon have support for draft 22, but= it does raise some questions:

<= /u>=C2=A0

1. I understand that some of the= se transition effects will go away as soon as draft support is replaced wit= h actual 0x0304 support, but were 0-RTT sessions used in the recent TLS 1.3= middlebox resiliency experiments?=C2=A0 The scenario above shows that some= middleboxes might (by luck?) not break full TLS 1.3 sessions, but those sa= me middleboxes might fail with subsequent 0-RTT early data.

=

We haven't been testin= g that. I do expect to see some 0-RTT bustage, but falling back to a full h= andshake at that point isn't a security issue, and so can be handled in= the conventional reconnect way. We (Firefox) also are looking at testing f= or middlebox compat explicitly and turning off features like 0-RTT and TFO = (which we already see problems with) if needed.

2. Sho= uld middleboxes that understand the=C2=A0supported_versions=C2=A0ext= ension get out of the loop immediately (as in ignore traffic after ClientHe= llo) when it sees 0x7fNN, where NN is larger than the highest draft version= supported by the middlebox?=C2=A0 How would that be different from other &= quot;grease" values?=C2=A0=C2=A0 I understand that this might just be = a temporary measure until 0x7fXX goes away (hopefully soon!).


First, they shouldn't = look at #s. Second, it depends what kind if middlebox you are. If you'r= e a protocol enforcing middlebox (ugh, these shouldn't exist) you shoul= d get out of the way. If you're a MITM device you should just negotiate= a lower version.

=C2=A0

3. Is there a plan for phasing out= draft support once TLS 1.3 is finalized as RFC?=C2=A0 Servers can stop sup= porting 0x7fxx as soon as 0x0304 is ready, but what should a middlebox do i= f 0x7fxx is seen post RFC?


I would expect people to just signal the RFC version relative= ly shortly after RFC. That's what we (Firefox) plans to do.
=

To answer your question more d= irectly, as EKR noted above, post-RFC and pre-RFC, middleboxes should not b= ehave differently for 0x0304, 0x7fxx, 0x1234, or 0x0305. If you did not ter= minate the connection, you don't get to parse variant-dependent fields.=

Someday the TLSWG will design TLS 1.4 which, like= TLS 1.3, has free reign to change everything past the ServerHello again. O= r perhaps we'll design a new cipher suite or extension that changes thi= ngs. New capabilities may be signaled by the client anywhere in the ClientH= ello. Recall that past TLS 1.2 extensions have injected new messages in the= handshake and changed the format of the Certificate message. Adding ECDHE = and PSK cipher suites changed how ClientKeyExchange and ServerKeyExchange w= orked. Earlier drafts of TLS 1.3 completely changed the handshake.

I started writing some text on version invariants to m= ake these rules clearer. They were the assumed rules in TLS 1.2, but draft-= 22 reflects that the network did not honor them. I'll finish that up an= d make a PR. I do not believe writing this in text will be sufficient, but = it is evidently necessary.

TLS's versioning in= variants are quite simple: if you are not terminating the TLS connection (i= .e. the ClientHello was not produced by you), you MUST NOT process any mess= age beyond the ClientHello. If you produced the ClientHello, you can reason= ably expect to understand the response and can act as an endpoint does.

Any middleware violating this invariant is non-compli= ant and at risk of breaking as endpoints and the protocol evolve. Alas, thi= s was insufficiently GREASEd from SSL 3.0 through TLS 1.2, so we had to gra= ndfather in existing violations via draft 22.

Futu= re violations, however, continue to be non-compliant and you should expect = them to break, and quite rapidly as draft-22 shows we need more ideas in th= e vein of GREASE.

David
--001a113fe8b278f83f055f49f36e-- From nobody Fri Dec 1 17: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 1047912943C for ; Fri, 1 Dec 2017 17:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HEmQo1KGD3x for ; Fri, 1 Dec 2017 17:51:32 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04olkn0826.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4c::826]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDDE12943D for ; Fri, 1 Dec 2017 17:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IW70WE82HbJ1XFL4B6PslCgepHe4ZGNyxj60T686+vA=; b=NwWXiI4xEj+wdHBuqaqoClNb/65JGXS+7OTSvZ4Y6BrwuU5eP3FMCTj5Xjc4p8sb05fiiAjJFEpgz/0avBcVAd7qPJM2D5NANF29XSvst7xs0/4qcF95HhjomvBxVvdcCaiuhgYTMga0VB4L1TNea8J4ZjvNDDuJNgLLdfI9FiX0o2+Hl4wfA4ytThbW8CP70H2gsf9OVOm17IglrIsmqNXcxoE8aCEn3h3GiMyO2NDFZVa0BAM8KM5sxyu8Zu+M79RdF+9WYYcDlnWmxJPv3Ko/tXWrwscqwYNERRxrSU8aDJGUUX9BT8evU5rO8vUJua2WFsv0T5NGiuNbvYGspg== Received: from SN1NAM04FT035.eop-NAM04.prod.protection.outlook.com (10.152.88.52) by SN1NAM04HT157.eop-NAM04.prod.protection.outlook.com (10.152.88.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Sat, 2 Dec 2017 01:51:14 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.88.55) by SN1NAM04FT035.mail.protection.outlook.com (10.152.88.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Sat, 2 Dec 2017 01:51:14 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0282.007; Sat, 2 Dec 2017 01:51:14 +0000 From: Yuhong Bao To: David Benjamin , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 draft 22 middlebox interaction Thread-Index: AQHTarPwCc0JmzJMxUiArZxt9jsP9KMumcAAgAAVeYCAAJtbkw== Date: Sat, 2 Dec 2017 01:51: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-incomingtopheadermarker: OriginalChecksum:313F44BD48402EC6F2F8AFDB875CCD6D10EDCBB1BECF00FBA303EDCEB8CD0C7A; UpperCasedChecksum:BEF129E6405BE6809D5B85105D45778E4227CF0BD7FB578DFDFC318BB4B4EF1B; SizeAsReceived:7375; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [mQY6V464mAErbViJqn0q03Oa2a054Qlyursxncn8Atu5ml2owpMW2jjz6WK2EK6t] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT157; 6:y6qAAIodHXLwyERU96WUyUp7TA55gam9phT4qgoZFtaOLV2kAu1iFHIo/htfrtjZFSXdJymrSnhvNUsNR6ZULKxpG22NGPWiXY/L6bse9vxX8VjfBZTcPwUjBU3sQ0MfbtcoeCL759sPOGrjjuUBjxMPUxcQ1a/fXAYTiVpEtVFuBgdG1d0gLyd7cFT8wIUXvx734UKWQ7Nzq0cLSrKNPSv/tCTOG72EYYuwCssEQ4zQL/qkduWCVUcx1knrYp4Ke63I1N9mF8hGjr8Xo64GbBUjcZ/KA1ilq4H+N072L0Dli5MTNJbC6Ysmgv62/mOChHnXaJWXDqi+/pCNkpvpm2gdkqFTlqU/RJh0E2IhB0M=; 5:qrXActF/zCKG1yi2xS7ml4M6OAuu539RPMS8Gg/+HlYuxxwphiDgALX/pESuWHiRkSrS7bbSKGuo6YwhvwrlzDQhlEBrZ6F8Lr0E27LOpeT037FpZy+gvIubEZBxsKtncW7bmb8tUr+sFWYc3Br9qcRm9vwLQ6392eHJSOMzoAo=; 24:/ivmgW9KmvJoyqVYVSwVP7vy/RM5HhT3HnLiqSeYYtsIxdaIxFgkNmhKgS5cM+ZsCNQ/qOizv1Z6LNOjQR7fWVbKBKkltZ8t1XaGt06zmmo=; 7:vG/9IDhFsgQ8XAt9hOs/5saNFSVJC9dH1t+YtBDmcOfLAm3o23Rrs4nsc1+jLldj9yCbeWSCwWlqMxelCJIQ/ly/gkkINQ5VnB2M7XdaUY0nGgfLPegL2PtcLBIqx2AIlpR749LXXW1YzlEhfUPG19CTEBU4uXrNSFIRr0CWreMlpo59p9Jdi90oZXGJDR6PCCqLdx2jNz5H3X7vK2Jh8BkjQWJ/EAbMRWvIcCmB8fOd6QfOi13UHH1mlOiXC+7A x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SN1NAM04HT157; x-ms-traffictypediagnostic: SN1NAM04HT157: x-ms-office365-filtering-correlation-id: a06584fd-1d1b-4676-896e-08d539272b95 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM04HT157; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN1NAM04HT157; x-forefront-prvs: 0509245D29 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT157; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: a06584fd-1d1b-4676-896e-08d539272b95 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2017 01:51:14.0052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT157 Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2017 01:51:35 -0000 I was talking about that arms race not that long ago. ________________________________________ From: TLS on behalf of David Benjamin Sent: Friday, December 1, 2017 8:34:53 AM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla > wrote: On Fri, Dec 1, 2017 at 6:47 AM, R du Toit > wrote: I want to provide some feedback that might be useful to the TLS WG: Firefo= x Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org is triggering an interesting failure in at least on= e middlebox. The middlebox in question supports TLS 1.3, but only drafts 18 through 21. = The FF Nightly ClientHello supported_versions extension advertises support= for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox then interprets as= only advertising support for TLS 1.2, ignoring the 0x7f16 as if it is a "g= rease" value. The middlebox only perfoms protocol checks and does not actu= ally modify anything - the session completes without any issues, which show= s that the draft 22 middlebox measures are effective. FF Nightly then star= ts a resumed TLS 1.3 (draft 22) session that includes 0-RTT early data. Th= e middlebox performs a protocol check on the ClientHello and determines tha= t the client is trying to negotiate TLS 1.2 (per the logic of the first ses= sion). Shortly afterwards the 0-RTT AppData record arrives, which then tri= ggers a protocol error in the middlebox. "D.3. 0-RTT backwards compatibil= ity" of the draft 22 specification describes the problem, but in the contex= t of "older server" being "only supports up to TLS 1.2". This particular m= iddlebox can also be thought of as "older" because it only supports TLS 1.3= drafts 18 through 21. Obviously the middlebox will soon have support for draft 22, but it does ra= ise some questions: 1. I understand that some of these transition effects will go away as soon = as draft support is replaced with actual 0x0304 support, but were 0-RTT ses= sions used in the recent TLS 1.3 middlebox resiliency experiments? The sce= nario above shows that some middleboxes might (by luck?) not break full TLS= 1.3 sessions, but those same middleboxes might fail with subsequent 0-RTT = early data. We haven't been testing that. I do expect to see some 0-RTT bustage, but fa= lling back to a full handshake at that point isn't a security issue, and so= can be handled in the conventional reconnect way. We (Firefox) also are lo= oking at testing for middlebox compat explicitly and turning off features l= ike 0-RTT and TFO (which we already see problems with) if needed. 2. Should middleboxes that understand the supported_versions extension get = out of the loop immediately (as in ignore traffic after ClientHello) when i= t sees 0x7fNN, where NN is larger than the highest draft version supported = by the middlebox? How would that be different from other "grease" values? = I understand that this might just be a temporary measure until 0x7fXX goe= s away (hopefully soon!). First, they shouldn't look at #s. Second, it depends what kind if middlebox= you are. If you're a protocol enforcing middlebox (ugh, these shouldn't ex= ist) you should get out of the way. If you're a MITM device you should just= negotiate a lower version. 3. Is there a plan for phasing out draft support once TLS 1.3 is finalized = as RFC? Servers can stop supporting 0x7fxx as soon as 0x0304 is ready, but= what should a middlebox do if 0x7fxx is seen post RFC? I would expect people to just signal the RFC version relatively shortly aft= er RFC. That's what we (Firefox) plans to do. To answer your question more directly, as EKR noted above, post-RFC and pre= -RFC, middleboxes should not behave differently for 0x0304, 0x7fxx, 0x1234,= or 0x0305. If you did not terminate the connection, you don't get to parse= variant-dependent fields. Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reign t= o change everything past the ServerHello again. Or perhaps we'll design a n= ew cipher suite or extension that changes things. New capabilities may be s= ignaled by the client anywhere in the ClientHello. Recall that past TLS 1.2= extensions have injected new messages in the handshake and changed the for= mat of the Certificate message. Adding ECDHE and PSK cipher suites changed = how ClientKeyExchange and ServerKeyExchange worked. Earlier drafts of TLS 1= .3 completely changed the handshake. I started writing some text on version invariants to make these rules clear= er. They were the assumed rules in TLS 1.2, but draft-22 reflects that the = network did not honor them. I'll finish that up and make a PR. I do not bel= ieve writing this in text will be sufficient, but it is evidently necessary= . TLS's versioning invariants are quite simple: if you are not terminating th= e TLS connection (i.e. the ClientHello was not produced by you), you MUST N= OT process any message beyond the ClientHello. If you produced the ClientHe= llo, you can reasonably expect to understand the response and can act as an= endpoint does. Any middleware violating this invariant is non-compliant and at risk of bre= aking as endpoints and the protocol evolve. Alas, this was insufficiently G= REASEd from SSL 3.0 through TLS 1.2, so we had to grandfather in existing v= iolations via draft 22. Future violations, however, continue to be non-compliant and you should exp= ect them to break, and quite rapidly as draft-22 shows we need more ideas i= n the vein of GREASE. David From nobody Sat Dec 2 06:55: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 581BB127076 for ; Sat, 2 Dec 2017 06:55:32 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VceF112__bU for ; Sat, 2 Dec 2017 06:55:29 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7B71200F3 for ; Sat, 2 Dec 2017 06:55:28 -0800 (PST) Received: from pc1 (dslb-088-070-244-147.088.070.pools.vodafone-ip.de [::ffff:88.70.244.147]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 02 Dec 2017 15:56:01 +0100 id 000000000000002E.000000005A22BF02.000023CD Date: Sat, 2 Dec 2017 15:55:25 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20171202155525.56580484@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2017 14:55:32 -0000 On Fri, 01 Dec 2017 09:47:45 -0500 R du Toit wrote: > The middlebox in question supports TLS 1.3, but only drafts 18 > through 21. The FF Nightly ClientHello supported_versions extension > advertises support for TLS 1.2 and TLS 1.3 (draft 22), Sorry, can you please name names here? In what universe does this make any sense? The middlebox shouldn't look at specific TLS versions. And it certainly shouldn't look at specific TLS 1.3 drafts. It should just leave the traffic alone. Doing anything of the form "we'll accept traffic of TLS version X, but not of any version unknown to us" is certain to cause breakage in the future. Whoever built this is harming the Internet, full stop. I really don't understand why there is such intransparency over this issue. Why can't we at least make clear who are the companies responsible for this nonsense? --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Sat Dec 2 08:46: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 17E8A128AB0 for ; Sat, 2 Dec 2017 08:46:34 -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 (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoXhajrZKoVP for ; Sat, 2 Dec 2017 08:46:32 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D61B1289B5 for ; Sat, 2 Dec 2017 08:46:32 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB2Gg2La028415; Sat, 2 Dec 2017 16:46:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=L9TZJzj7WE4nzIGHD6QskKiGoikV2Ugoa6C+zEvLFoQ=; b=AwhYeejOD5PdD9uS8bVotZlnL3oNqd7UOU1xylg4qH9lQhUXhIRnFd0Hc+AFHi0g8CMj 0PNMztVq1RB9GznSlnep3LEPB/u+0VkxjdBQsGRIA9oglKU1Jv9hPqHzqxEQFsiZko2t TvEHvOTI9CuJy4HUNUeyLlPRANSnhwfAodOTcs7aarYMqOV8Rx+uqCDKekHZ5sXFYeHc gESyXmc4x5NMaZAmIErk562DsSs7GDVUiLHC7aRhwFq4GiX0vfkQZ50neS2CT8oMqZmf GnZKkDDmXsxYf+NiRAPNbEscStyQoGYpCky4n6BFciFEH7jbcbDsNz6OIRSRcsJ6vX0b SA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2ekpnjs4dg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 02 Dec 2017 16:46:27 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vB2GkQ1v012288; Sat, 2 Dec 2017 11:46:26 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ekrcyh0cw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 02 Dec 2017 11:46:26 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 2 Dec 2017 11:46:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 2 Dec 2017 11:46:25 -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.1263.000; Sat, 2 Dec 2017 11:46:25 -0500 From: "Salz, Rich" To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 draft 22 middlebox interaction Thread-Index: AQHTarPv8WY7oriIB0GqXT1tAKFcTqMweZWAgAAe8oA= Date: Sat, 2 Dec 2017 16:46:24 +0000 Message-ID: <98AE612C-03E8-4A36-BA58-722FDC287FDC@akamai.com> References: <20171202155525.56580484@pc1> In-Reply-To: <20171202155525.56580484@pc1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.55] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712020247 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712020246 Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2017 16:46:34 -0000 4p6iIEkgcmVhbGx5IGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZXJlIGlzIHN1Y2ggaW50cmFuc3Bh cmVuY3kgb3ZlciB0aGlzDQogICAgaXNzdWUuIFdoeSBjYW4ndCB3ZSBhdCBsZWFzdCBtYWtlIGNs ZWFyIHdobyBhcmUgdGhlIGNvbXBhbmllcw0KICAgIHJlc3BvbnNpYmxlIGZvciB0aGlzIG5vbnNl bnNlPw0KICAgIA0KQWRhbSBMYW5nbGV5IHBvc3RlZCBzb21ldGhpbmcgdG8gdGhpcyBsaXN0IGF3 aGlsZSBiYWNrLCBidXQgSSBjYW7igJl0IGZpbmQgaXQsIHNvcnJ5Lg0KDQo= From nobody Sat Dec 2 10:10: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 2257A127286 for ; Sat, 2 Dec 2017 10:10:18 -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 4pS09BsOhjgf for ; Sat, 2 Dec 2017 10:10:16 -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 543A51200FC for ; Sat, 2 Dec 2017 10:10:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AA415300596 for ; Sat, 2 Dec 2017 13:10:15 -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 xC82tDXKsrI1 for ; Sat, 2 Dec 2017 13:10:14 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8F4CF300581 for ; Sat, 2 Dec 2017 13:10:14 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <332B60C8-9355-4743-B663-9FAB77C55282@vigilsec.com> Date: Sat, 2 Dec 2017 13:10:13 -0500 To: IETF TLS X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] External PSK with certificate-based authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2017 18:10:18 -0000 At the bottom of page 136, the current draft says: Note: TLS does not currently permit the server to send a certificate_request message in non-certificate-based handshakes (e.g., PSK). If this restriction were to be relaxed in future, the client's signature would not cover the server's certificate directly. However, if the PSK was established through a NewSessionTicket, the client's signature would transitively cover the server's certificate through the PSK binder. [PSK-FINISHED] describes a concrete attack on constructions that do not bind to the server's certificate (see also [Kraw16]). It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/ key-id pair with two different endpoints. Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server. [PSK-FINISHED] tells why it is not safe to do client authentication = after resumption. [Kraw16] says two things: (1) using a PSK from a previous handshake and = adding client authentication is not secure; and (2)does not work; and = the client signature must cover the public key. So, the final sentence in the quoted paragraph seems to be too broad. I = do not see why we forbid an external PSK and certificate-based = authentication in an initial handshake. I acknowledge that TLS 1.3 does = not support it, but I have been expecting an extension to be specified = to do just that once the TLS 1.3 base specification is finished. Russ From nobody Sat Dec 2 10:52: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 328ED128D0F for ; Sat, 2 Dec 2017 10:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdCJ_S4kSMtX for ; Sat, 2 Dec 2017 10:52:27 -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 464D4128CFF for ; Sat, 2 Dec 2017 10:52:27 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id p128so5230981yba.7 for ; Sat, 02 Dec 2017 10:52:27 -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=wccGVJ8Dkq3/IHlcrt5zQTguqNRL21DgqZQ3l7o1Uys=; b=TFzlOE6z92l28pEuYZ1geW4VD9kqNSm/jKRsqHkaOzXbdKTVNw574KEGZ3cKYnEe1k w2NN2WAQRhoKGypHIsy0mFEq0W8+HpODMcjCsDz1t93NNK3+B7gG7dqJdMCTrJCOiYaI 8ViLrMg1JxeIQpVr07hUam+CWA8Bny/X8AuCH8vfDwAeP2kIHmL3Q0BmPQJL9LWNGc5C evpmvJv80Tqnvr/+9W57Ru1bge/HN2MKrFsN290Hkm1sMLS5vDj5MDkUqyV0fLTwfDbC yES3MKeSO42YSu3QNP0mKyu0PyWgPpUyDZENEYd2snjYJoys8aEA0SgGkhRDKCswVkL0 cCvg== 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=wccGVJ8Dkq3/IHlcrt5zQTguqNRL21DgqZQ3l7o1Uys=; b=ZkyuUDDndS0+BE84N9mn0VVKUyHA6RHIpCDyj2rmSCv2K93Hf+toQ0S2R0sQ/Qj0jD zyF/GX3cArP8LS8nQMJ+iBiBpUEI4HDitrNAxOxx35GppqHFHig3dj0yzV7kc2tFq4uh 7FE79OxSrfOphXxuxi7fGDWns/9bsV9DEwVZxdL8FvRbBJB8KBikZMYc3WJcvKfgTfK8 +gLkL7tMdxu3m7iZWuKsRJ2FcvbCh/vdH3WsPr4TVhhrCo7dGnzsVxrJdi9eonBOc/7l SSkALwV9MLXdqU8UxUL8WcJ3MYd2Q8VUyl9A0KxKhPQ0o6rkrU08sgRiqaaoLZUG//Kx eoaA== X-Gm-Message-State: AKGB3mL6FQRv7rRNsaVFQ6bwuBtSS1VsJqhk6DIQoKhwtsOzCPIbaw3i ths8PzcDL53fDOZIkXTLGvKqZoVpy4Xyf6IJKdioFint X-Google-Smtp-Source: AGs4zMYYaQcJF+yAPoWXLVNenV1JhLHOFWj6VaW1qsuOxVUS1pJhwzjZ1Kp/+t+aS1yoDsUQnz65td8vHp0IPrA0LoY= X-Received: by 10.37.13.65 with SMTP id 62mr1077919ybn.416.1512240746366; Sat, 02 Dec 2017 10:52:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Sat, 2 Dec 2017 10:51:45 -0800 (PST) In-Reply-To: <332B60C8-9355-4743-B663-9FAB77C55282@vigilsec.com> References: <332B60C8-9355-4743-B663-9FAB77C55282@vigilsec.com> From: Eric Rescorla Date: Sat, 2 Dec 2017 10:51:45 -0800 Message-ID: To: Russ Housley Cc: IETF TLS Content-Type: multipart/alternative; boundary="001a11c01ee2809c21055f5ffc44" Archived-At: Subject: Re: [TLS] External PSK with certificate-based authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2017 18:52:29 -0000 --001a11c01ee2809c21055f5ffc44 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 2, 2017 at 10:10 AM, Russ Housley wrote: > At the bottom of page 136, the current draft says: > > Note: TLS does not currently permit the server to send a > certificate_request message in non-certificate-based handshakes > (e.g., PSK). If this restriction were to be relaxed in future, the > client's signature would not cover the server's certificate directly. > However, if the PSK was established through a NewSessionTicket, the > client's signature would transitively cover the server's certificate > through the PSK binder. [PSK-FINISHED] describes a concrete attack > on constructions that do not bind to the server's certificate (see > also [Kraw16]). It is unsafe to use certificate-based client > authentication when the client might potentially share the same PSK/ > key-id pair with two different endpoints. Implementations MUST NOT > combine external PSKs with certificate-based authentication of either > the client or the server. > > [PSK-FINISHED] tells why it is not safe to do client authentication after > resumption. > > [Kraw16] says two things: (1) using a PSK from a previous handshake and > adding client authentication is not secure; and (2)does not work; and the > client signature must cover the public key. > > So, the final sentence in the quoted paragraph seems to be too broad. I > do not see why we forbid an external PSK and certificate-based > authentication in an initial handshake. I acknowledge that TLS 1.3 does > not support it, but I have been expecting an extension to be specified to > do just that once the TLS 1.3 base specification is finished. > My view on this is that that's not a currently specified configuration. A future specification could of course relax that. If you wanted to submit a PR that said "absent some extension to the contrary" that would be fine, though I think that's implicit. -Ekr Russ > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c01ee2809c21055f5ffc44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 2, 2017 at 10:10 AM, Russ Housley <housley@vigilsec.com= > wrote:
At the bottom of p= age 136, the current draft says:

=C2=A0 =C2=A0Note: TLS does not currently permit the server to send a
=C2=A0 =C2=A0certificate_request message in non-certificate-based handshake= s
=C2=A0 =C2=A0(e.g., PSK).=C2=A0 If this restriction were to be relaxed in f= uture, the
=C2=A0 =C2=A0client's signature would not cover the server's certif= icate directly.
=C2=A0 =C2=A0However, if the PSK was established through a NewSessionTicket= , the
=C2=A0 =C2=A0client's signature would transitively cover the server'= ;s certificate
=C2=A0 =C2=A0through the PSK binder.=C2=A0 [PSK-FINISHED] describes a concr= ete attack
=C2=A0 =C2=A0on constructions that do not bind to the server's certific= ate (see
=C2=A0 =C2=A0also [Kraw16]).=C2=A0 It is unsafe to use certificate-based cl= ient
=C2=A0 =C2=A0authentication when the client might potentially share the sam= e PSK/
=C2=A0 =C2=A0key-id pair with two different endpoints.=C2=A0 Implementation= s MUST NOT
=C2=A0 =C2=A0combine external PSKs with certificate-based authentication of= either
=C2=A0 =C2=A0the client or the server.

[PSK-FINISHED] tells why it is not safe to do client authentication after r= esumption.

[Kraw16] says two things: (1) using a PSK from a previous handshake and add= ing client authentication is not secure; and (2)does not work; and the clie= nt signature must cover the public key.

So, the final sentence in the quoted paragraph seems to be too broad.=C2=A0= I do not see why we forbid an external PSK and certificate-based authentic= ation in an initial handshake.=C2=A0 I acknowledge that TLS 1.3 does not su= pport it, but I have been expecting an extension to be specified to do just= that once the TLS 1.3 base specification is finished.

My view on this is that that's not a currently specifie= d configuration. A future specification could of course relax that. If you = wanted to submit a PR that said "absent some extension to the contrary= " that would be fine, though I think that's implicit.
-Ekr



Russ



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

--001a11c01ee2809c21055f5ffc44-- From nobody Sun Dec 3 07:56: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 3AA641243FE for ; Sun, 3 Dec 2017 07:56:01 -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 eZ46X4-Bvkoe for ; Sun, 3 Dec 2017 07:55:58 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5B712009C for ; Sun, 3 Dec 2017 07:55:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DCD8D97B55; Sun, 3 Dec 2017 17:55: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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id UW7oHWRhw0mr; Sun, 3 Dec 2017 17:55:55 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2A3BF28E; Sun, 3 Dec 2017 17:55:53 +0200 (EET) Date: Sun, 3 Dec 2017 17:55:52 +0200 From: Ilari Liusvaara To: R du Toit Cc: tls@ietf.org Message-ID: <20171203155552.GA8097@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2017 15:56:01 -0000 On Fri, Dec 01, 2017 at 09:47:45AM -0500, R du Toit wrote: > I want to provide some feedback that might be useful to the TLS WG: > Firefox Nightly TLS 1.3 (draft 22) sessions to > tls13.crypto.mozilla.org is triggering an interesting failure in at > least one middlebox. > > Obviously the middlebox will soon have support for draft 22, but it > does raise some questions: Some rules are: If any of these happens, you are dealing with Undefined Behavior w.r.t. what is implemented, and the remainder of handshake can not be parsed, because it may have been altered in arbitrary ways. - The first client message is not of type 1 - The ClientVersion is not "SSL 3.x" (first byte in CH is not 3). - The first server message is not of type 2. - The ServerVersion is not known. - Any unknown extension is accepted by the server. - Unknown value is accepted in server extension. For example about just how devastating unknown extension can be, consider what the supported_versions from TLS 1.3-draft22 does... However, note that none of the above actually covers 0-RTT. This is because no earlier version envisioned anything like 0-RTT. In certain environments, it might make sense to require ClientHello to be parseable (e.g., for non-standard end-to-path signaling). There is much less reaso to try to parse ServerHello. > 1. [...]but were 0-RTT sessions used in the recent TLS 1.3 middlebox > resiliency experiments? The scenario above shows that some > middleboxes might (by luck?) not break full TLS 1.3 sessions, but > those same middleboxes might fail with subsequent 0-RTT early data. As noted elsewhere, 0-RTT failures are much less severe than full handshake failure. Dropping 0-RTT is not a security problem (in fact, might just be the opposite). It is at worst minor performance problem. But downgrading versions absolutely is a security problem. > 2. Should middleboxes that understand the supported_versions extension > get out of the loop immediately (as in ignore traffic after > ClientHello) when it sees 0x7fNN, where NN is larger than the highest > draft version supported by the middlebox? What are you doing trying to parse ClientHello? And more importantly, what are you doing trying to parse anything after that? > 3. Is there a plan for phasing out draft support once TLS 1.3 is > finalized as RFC? Servers can stop supporting 0x7fxx as soon as 0x0304 > is ready, but what should a middlebox do if 0x7fxx is seen post RFC? Well, speaking of the library I maintain, I do not have plans on dropping support for drafts. This includes support for draft-18 (e.g. Firefox 52 ESR). However, once TLS 1.3 hits RFC-ed-q, I plan on adding "draft-255" (TLS 1.3 final; 0x0304) and hardcoding FLAGS0_ENABLE_TLS13 to true. -Ilari From nobody Mon Dec 4 01:59: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 6AA321241F5 for ; Mon, 4 Dec 2017 01:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, 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 gRsbTda1BFcL for ; Mon, 4 Dec 2017 01:59:15 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 D190F124207 for ; Mon, 4 Dec 2017 01:59:14 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id h203so9133335vka.6 for ; Mon, 04 Dec 2017 01:59: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=+Iirouj5HzAL/B14no35q+kIJL80e/hyvm9TZiKi0Lo=; b=Qd3qwptYX2HdDZul4Cdjz9UBFxDwu7fW4ZClfK10qCQkeGKN9hcKcmby5v2bClz4PG 6jJpFSrdqCvmVaRfkePRoxx2WgkzzDy1AzplCFv6VrXuEZld6MQ3IBc5Bwhw5eBeE8To PmrQ6VWme/ykDzWk4Ux3KOFwh2y8McAy7WEWjZMLmUEUm8KdpU8X0PfbIzwfNtErgTj1 y2c9YMZ+Ci/bL8MOYVwTSKePVeQAepXCIqzC5YxBBd5yYXr9Tv1HPPgktwisDLjv3R5b lJUWJkg59H/RVM5w8zriT/uqqwZFvBL1+yvOfJyH9VcxbZLjH8abbjEJkn77jmII4LQa bj+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=+Iirouj5HzAL/B14no35q+kIJL80e/hyvm9TZiKi0Lo=; b=Hp98h/KWS66YOaQQzOI1fG4QdLKqDXStUEj1frKN9flZvitPaIDO54W2UbadYyC7iV +KO/M1+6XygEqJTAnn/Py4NjdcoBNi2TFOezyUjtbBmCOs/7tdu5XqmMAjMGu8+EA5zj omCJ5jpHk0r9df4COKpQWK6/ZfujALH8Vnc8Nl05FebjFYrrQQe7J3Qlg+tXkVZqYEbm kHMqejRiaiyzCBzFrU/6dbV9dQNKsiodz93g+h+ATx/iMDOJ8NgdiBBPFGZzOi7jBNc4 dNZYQte9XC0bYT30u+rJRLBHHZxTf1XOD8DB9VYT3AYK/Z2KmVpwg70yzGx9GgrywW70 pUEA== X-Gm-Message-State: AKGB3mLFppVKnBgzQBL0+x7DDEmz5RDQns112naZ8IJ9cSWR+6TRZL9V n2+2xikSiLmS912Lc8Lrb9754EFw1XuoIV3ziFg= X-Google-Smtp-Source: AGs4zMbfnnNWSwObxFpuZ8zJyr3r8+Y/PsUCXeZ4XLFr9tEvKlzB9nbGJw8eW76QTevvY04YmDHw4MrDBVIXnvvM6Fs= X-Received: by 10.31.93.134 with SMTP id r128mr3311266vkb.143.1512381553899; Mon, 04 Dec 2017 01:59:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.59.206 with HTTP; Mon, 4 Dec 2017 01:59:13 -0800 (PST) In-Reply-To: References: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi> From: Alex C Date: Mon, 4 Dec 2017 22:59:13 +1300 Message-ID: To: Yuhong Bao Cc: Andrei Popov , Peter Saint-Andre , Eric Rescorla , "tls@ietf.org" , Tapio Sokura Content-Type: multipart/alternative; boundary="94eb2c09306248fd5b055f80c51f" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2017 09:59:17 -0000 --94eb2c09306248fd5b055f80c51f Content-Type: text/plain; charset="UTF-8" The obvious problem with randomly adding fake versions is you have to have a way of ensuring they won't conflict with *real* future versions - and whatever pattern you decide upon in order to do that, middleboxes will use that pattern to filter out fake versions, and fail as soon as you present one with a real future version (i.e. TLS 1.4). Can I also suggest adding a section about expected middlebox behaviour to TLS 1.3? That way there is a reasonable chance that TLS 1.4 won't face the same issues. (Or can I do that myself? I'm not really familiar with the process, sorry) On Sat, Nov 25, 2017 at 8:21 AM, Yuhong Bao wrote: > That only applies to the ClientHello. > > ________________________________________ > From: Andrei Popov > Sent: Wednesday, November 22, 2017 11:22:23 AM > To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla > Cc: tls@ietf.org; Tapio Sokura > Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness > > The idea was for the client to randomly add non-existent TLS versions to > supported_versions. > Presumably, this will exercise the extensibility joint and prevent it from > becoming unusable. > > I'm not convinced this new approach will help, but we know the old one > required fallbacks every time a new protocol version was introduced. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao > Sent: Wednesday, November 22, 2017 11:04 AM > To: Peter Saint-Andre ; Eric Rescorla > Cc: tls@ietf.org; Tapio Sokura > Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness > > They are basically doing a supported_versions extension with only one > entry in the ServerHello. > The problem with future middleboxes should be obvious. > > ________________________________________ > From: Peter Saint-Andre > Sent: Wednesday, November 22, 2017 11:02:39 AM > To: Yuhong Bao; Eric Rescorla > Cc: tls@ietf.org; Tapio Sokura > Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness > > On 11/22/17 11:16 AM, Yuhong Bao wrote: > > The problem is not TLS 1.3, the problem is future versions of TLS. > > Would you mind explaining that in more detail? > > Peter > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls& > data=02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d531db > dbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C636469742719473989&sdata=fCAZVB8XHK3IJQAoSf% > 2FUwSDlHYiy2tm0WBktCGS%2BPW8%3D&reserved=0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c09306248fd5b055f80c51f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The obvious problem with randomly adding fake version= s is you have to have a way of ensuring they won't conflict with rea= l future versions - and whatever pattern you decide upon in order to do= that, middleboxes will use that pattern to filter out fake versions, and f= ail as soon as you present one with a real future version (i.e. TLS 1.4).
Can I also suggest adding a section about expected middleb= ox behaviour to TLS 1.3? That way there is a reasonable chance that TLS 1.4= won't face the same issues.
(Or can I do that myself? I'm= not really familiar with the process, sorry)

On Sat, Nov 25, 2017 at 8:21 AM, Yuho= ng Bao <yuhongbao_386@hotmail.com> wrote:
That only applies to the ClientHello.

________________________________________
From: Andrei Popov <Andrei= .Popov@microsoft.com>
Sent: Wednesday, November 22, 2017 11:22:23 AM
To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness

The idea was for the client to randomly add non-existent TLS versions to su= pported_versions.
Presumably, this will exercise the extensibility joint and prevent it from = becoming unusable.

I'm not convinced this new approach will help, but we know the old one = required fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre <stpeter@stp= eter.im>; Eric Rescorla <ekr@rtfm= .com>
Cc: tls@ietf.org; Tapio Sokura <tapio.sokura@iki.fi>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

They are basically doing a supported_versions extension with only one entry= in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre <stpeter@s= tpeter.im>
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&da= ta=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757= f08d531dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469742719473989&sdata=3DfCAZVB8XHK3IJQAoSf%2FUwSDlHYiy= 2tm0WBktCGS%2BPW8%3D&reserved=3D0

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

--94eb2c09306248fd5b055f80c51f-- From nobody Mon Dec 4 04:04: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 E442B12714F for ; Mon, 4 Dec 2017 04:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_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 ibdKEcWpkW-K for ; Mon, 4 Dec 2017 04:04:09 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D27127011 for ; Mon, 4 Dec 2017 04:04:09 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id t204so6533900ywe.9 for ; Mon, 04 Dec 2017 04:04:09 -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=WuWZrITAOTEfSh6GZKZHcJ8jIbaemH6P/gM+gvde/YU=; b=Rvqn0PllfmuPRkrAMp0kjTY7b4Ml43REBFhac/kv5Z/NgjW4CGDs4lGRFHbkJhwnD2 VvM0Djmzd+X1LURTH03Ix+5YMQC9g1kvmVo/J80JIDarava2FtYn1AgM3E+63p7TCVgZ RBnHmPnfJRx/sHunJIjYjsliakmqnzyHsUsGLU1/E95in+izMLgJBlfdgpGxGUZ5Wb/h rTZ2V23rlVmXzFgOE5fHJBITbm5oH3INYPX3FhhiAaOPRYMQfKvvTpCnPnwVRfJDnpqp Nqjo89ET2MN2OYUYx68lCJuUn2I6Zu+F3gQHgibnZucNKd1b5E+MaezoI0EnqVJLfBVF 7sFg== 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=WuWZrITAOTEfSh6GZKZHcJ8jIbaemH6P/gM+gvde/YU=; b=TV0JKHndsda8s9UKszBQUnxSnHcF8rLKMy9JJjERrcAHxK7w9rTT/Po66KcRJbs47P OIbb+AVJhzymWFSAvpFwngSjkFhRe3K019zFQuuxpPhAkrqvg6hm2dg7Ld8hOYLJ/kLm G1qyYvDFth+kccX7os8CP4DgmraeZ5cRBx0Wy1k7ZTtjIuRHEnPnHZYPLdZg3idDXuTu Vrcl4rktGVGH+wAvLwbioCIQdVuiS+kTX6qtnhb0Bx7Nq5hBdAWqtg3gYiw6ZCezfFCn Tlb6rrpFi8fodTHcbz/CxU7jfjXT4ReCBP20ZBVrCSZDrqThk5qAc4bPKlj3KSFYypAM iw1g== X-Gm-Message-State: AJaThX65rpBKsGZvMf09yxWiKVcWuj4CPippxOwT0CXYsuPtcNjEI5Ca Bajkhf6dAhJ4Zb1/YUdVzmxp1alD6GQ91zoytLvnQw== X-Google-Smtp-Source: AGs4zMZA7TfoAec9sqN86ojiSd69eoKEA29CNUi/U1y4E6iaOUJXFkksBIESmpPm7VXBS7fwybRnnjIR3vIDtEl1bAU= X-Received: by 10.129.154.22 with SMTP id r22mr9348603ywg.296.1512389048229; Mon, 04 Dec 2017 04:04:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Mon, 4 Dec 2017 04:03:27 -0800 (PST) In-Reply-To: References: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi> From: Eric Rescorla Date: Mon, 4 Dec 2017 04:03:27 -0800 Message-ID: To: Alex C Cc: Yuhong Bao , Andrei Popov , Peter Saint-Andre , "tls@ietf.org" , Tapio Sokura Content-Type: multipart/alternative; boundary="94eb2c0bb4e8fb821e055f828329" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2017 12:04:12 -0000 --94eb2c0bb4e8fb821e055f828329 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 1:59 AM, Alex C wrote: > The obvious problem with randomly adding fake versions is you have to have > a way of ensuring they won't conflict with *real* future versions - and > whatever pattern you decide upon in order to do that, middleboxes will use > that pattern to filter out fake versions, and fail as soon as you present > one with a real future version (i.e. TLS 1.4). > > Can I also suggest adding a section about expected middlebox behaviour to > TLS 1.3? That way there is a reasonable chance that TLS 1.4 won't face the > same issues. > (Or can I do that myself? I'm not really familiar with the process, sorry) > > Yes, you can send a a PR at: https://github.com/tlswg/tls13-spec/ -Ekr > On Sat, Nov 25, 2017 at 8:21 AM, Yuhong Bao > wrote: > >> That only applies to the ClientHello. >> >> ________________________________________ >> From: Andrei Popov >> Sent: Wednesday, November 22, 2017 11:22:23 AM >> To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla >> Cc: tls@ietf.org; Tapio Sokura >> Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness >> >> The idea was for the client to randomly add non-existent TLS versions to >> supported_versions. >> Presumably, this will exercise the extensibility joint and prevent it >> from becoming unusable. >> >> I'm not convinced this new approach will help, but we know the old one >> required fallbacks every time a new protocol version was introduced. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao >> Sent: Wednesday, November 22, 2017 11:04 AM >> To: Peter Saint-Andre ; Eric Rescorla >> Cc: tls@ietf.org; Tapio Sokura >> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness >> >> They are basically doing a supported_versions extension with only one >> entry in the ServerHello. >> The problem with future middleboxes should be obvious. >> >> ________________________________________ >> From: Peter Saint-Andre >> Sent: Wednesday, November 22, 2017 11:02:39 AM >> To: Yuhong Bao; Eric Rescorla >> Cc: tls@ietf.org; Tapio Sokura >> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness >> >> On 11/22/17 11:16 AM, Yuhong Bao wrote: >> > The problem is not TLS 1.3, the problem is future versions of TLS. >> >> Would you mind explaining that in more detail? >> >> Peter >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=https%3A% >> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01% >> 7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d5 >> 31dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469 >> 742719473989&sdata=fCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS >> %2BPW8%3D&reserved=0 >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --94eb2c0bb4e8fb821e055f828329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2017 at 1:59 AM, Alex C <immibis@gmail.com> wrote:
The obvious problem with randomly adding fake versions is you hav= e to have a way of ensuring they won't conflict with real future= versions - and whatever pattern you decide upon in order to do that, middl= eboxes will use that pattern to filter out fake versions, and fail as soon = as you present one with a real future version (i.e. TLS 1.4).

=
Can I also suggest adding a section about expected middlebox behaviour= to TLS 1.3? That way there is a reasonable chance that TLS 1.4 won't f= ace the same issues.
(Or can I do that myself? I'm not really = familiar with the process, sorry)

<= /div>

Yes, you can send a a PR at:
https://github.com/tlswg= /tls13-spec/

-Ekr
=C2=A0
On Sat, Nov 25, 2017 at= 8:21 AM, Yuhong Bao <yuhongbao_386@hotmail.com> wro= te:
<= div class=3D"gmail-h5">That only applies to the ClientHello.

________________________________________
From: Andrei Popov <Andrei.Popov@microsoft.com>
Sent: Wednesday, November 22, 2017 11:22:23 AM
To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
Cc: tls@ietf.org; Tap= io Sokura
Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness

The idea was for the client to randomly add non-existent TLS versions to su= pported_versions.
Presumably, this will exercise the extensibility joint and prevent it from = becoming unusable.

I'm not convinced this new approach will help, but we know the old one = required fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre <stpeter@stpeter.im>; Eric Rescorla <ekr@rtfm.com>
Cc: tls@ietf.org; Tap= io Sokura <tapi= o.sokura@iki.fi>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

They are basically doing a supported_versions extension with only one entry= in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre <stpeter@stpeter.im>
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tap= io Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=3D= 02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d5= 31dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469= 742719473989&sdata=3DfCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS%2BPW8%3D&reserved=3D0

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


--94eb2c0bb4e8fb821e055f828329-- From nobody Mon Dec 4 10:46:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE74012878D for ; Mon, 4 Dec 2017 10:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e73sFbR-bnLg for ; Mon, 4 Dec 2017 10:46:17 -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 69C52127B60 for ; Mon, 4 Dec 2017 10:46:17 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D14DFC058EC1; Mon, 4 Dec 2017 18:46:16 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-18.brq.redhat.com [10.40.200.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8B2EE5DA6D; Mon, 4 Dec 2017 18:46:16 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 04 Dec 2017 19:46:10 +0100 Message-ID: <6707938.yJ1mNgvnlj@pintsize.usersys.redhat.com> In-Reply-To: <98AE612C-03E8-4A36-BA58-722FDC287FDC@akamai.com> References: <20171202155525.56580484@pc1> <98AE612C-03E8-4A36-BA58-722FDC287FDC@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2110600.UYqQIIguTC"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 04 Dec 2017 18:46:16 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2017 18:46:19 -0000 --nextPart2110600.UYqQIIguTC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 2 December 2017 17:46:24 CET Salz, Rich wrote: > =E2=9E=A2 I really don't understand why there is such intransparency over= this > issue. Why can't we at least make clear who are the companies > responsible for this nonsense? > =20 > Adam Langley posted something to this list awhile back, but I can=E2=80= =99t find it, > sorry. =20 I haven't seen him mention any names either =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 115, 612 00 Brno, Czech Republic --nextPart2110600.UYqQIIguTC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAloll/IACgkQkqjRuAHS 9fW/cBAAgzvmJsxk6az2qVChIjC21Gupm9UCs5TVrmghL8OhR+fcWb6NzuIAEncc ipktcGlyjskOJf8KEyLwhrFWRcqpj7kFlnhsbwIlmKcMWDbJmBDY2UAlWvRqW1GF fO2ZxVccYCI9ITdq5cfU9Y5ECpTyFOOePOjVchoLzA0detwJQynfwRbh1fpiDZYu Ar+MA/mMHeDZj9UKjwAAnVKOQuTl4ysi6Q324tKor4N5QlMhrvTNp1VlCV1TvYHu PzVBtzIaAvtXPjpmf22pM4cvhZ6btxdTapzOOGgkh8L6KF9YiGtugThYspejSmNW tuvvdNaCc2t1R4iIHFK3GBiGGgw7OoaC+u37sghDDrzpy2WQ4SYH6++niqA4nPc2 6/Roi1oAixYSMu4CXgsE6qtC0cXFbiAeO80dIKFyUbe+pWvLZ/H0qhhWDxef1Zw6 sVgqnU8pP2mzUQ/xv/xIc+4LxQA6O+GtMcri3KADCejqW7lp+BDuVsmtuEaBvVM2 Rk1XPDIeBHRhTt44/jTNAIcKjdSUcwaL2oiIUwdfTvBC6+oRO3PaTLDjlDYWPxB9 yGFArHwZSrk6vGJLMZqcKhOu0+oEtppqbfF36iMwHeBR3N5NSNV8hw4PIxpHWRyi AwKw+xQ4J1GJr3LDtndt7tQLCiLhiE5x6jiN1tb9WOhDyLEqoMU= =fhtt -----END PGP SIGNATURE----- --nextPart2110600.UYqQIIguTC-- From nobody Mon Dec 4 10:53: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 2A46E126DCA for ; Mon, 4 Dec 2017 10:53:10 -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 (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Riv920NVD44Y for ; Mon, 4 Dec 2017 10:53:08 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60FF124B09 for ; Mon, 4 Dec 2017 10:53:08 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB4Ipw2G018181; Mon, 4 Dec 2017 18:53:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=OUl9Y97A8kuSceI7dN/123rqgXYIgMm/rJVQ1Y/DM9o=; b=A2YaSisrejqvSR/FHe/9/eRTu5VwKY0aJ3mOxGXG7bwbq+N6SGWjDsNgrziVgBCc3pv3 +U1sCaEy0pJ70DuRENAYV9uSogP5HXM7Lf4e79fMxRnCK9AAj1ne3QV52e72rR6kXE9z PQyiobgmvXy7ZHYo/H6OIew4Z9jvhdCgeNa/lHqDLm8U7xKPE03OEdFyovM/rV9qzolt CzP4OeEvWc/xpawe6Tic2p8KXAoNjuJSI/qKz8XF9qBkh9MVVDbSnhRqp/r/0uh8exUY ggyx5QUMeEIqn2aH20WHtRoSFM1CYqsUS9ZJ3Rjx4F90Ndg1hGS8R1QA+3bL2qxLB+el 2A== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2ekpp46tf0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2017 18:53:02 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vB4IpBVR025351; Mon, 4 Dec 2017 13:53:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ekrd0nfq1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2017 13:53:01 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 4 Dec 2017 13:52:59 -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.1263.000; Mon, 4 Dec 2017 13:52:59 -0500 From: "Salz, Rich" To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 draft 22 middlebox interaction Thread-Index: AQHTarPv8WY7oriIB0GqXT1tAKFcTqMweZWAgAAe8oCAA0YwAIAAAeeA Date: Mon, 4 Dec 2017 18:52:59 +0000 Message-ID: <8619DF06-74FA-40F5-B774-CCEAE9C705B8@akamai.com> References: <20171202155525.56580484@pc1> <98AE612C-03E8-4A36-BA58-722FDC287FDC@akamai.com> <6707938.yJ1mNgvnlj@pintsize.usersys.redhat.com> In-Reply-To: <6707938.yJ1mNgvnlj@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.203] Content-Type: text/plain; charset="utf-8" Content-ID: <1634B84793166643B1CA2B74C64F9290@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712040267 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712040268 Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2017 18:53:10 -0000 ICAgID4gQWRhbSBMYW5nbGV5IHBvc3RlZCBzb21ldGhpbmcgdG8gdGhpcyBsaXN0IGF3aGlsZSBi YWNrLCBidXQgSSBjYW7igJl0IGZpbmQgaXQsDQogICAgPiBzb3JyeS4NCiAgICAgDQo+ICAgIEkg aGF2ZW4ndCBzZWVuIGhpbSBtZW50aW9uIGFueSBuYW1lcyBlaXRoZXINCiANCkkgd2FzbuKAmXQg Y2xlYXIuICBIZSBwb3N0ZWQgdGhhdCB0aGV5IHdlcmVu4oCZdCBnb2luZyB0byBwb3N0IG5hbWVz Lg0KDQo= From nobody Mon Dec 4 10:57: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 5D7C01288A9 for ; Mon, 4 Dec 2017 10:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Uw0VF1DgRRX for ; Mon, 4 Dec 2017 10:57:52 -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 0F7D9128896 for ; Mon, 4 Dec 2017 10:57:52 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CE556743; Mon, 4 Dec 2017 18:57:51 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-18.brq.redhat.com [10.40.200.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 88DAE619F1; Mon, 4 Dec 2017 18:57:51 +0000 (UTC) From: Hubert Kario To: "Salz, Rich" Cc: "tls@ietf.org" , Hanno =?ISO-8859-1?Q?B=F6ck?= Date: Mon, 04 Dec 2017 19:57:49 +0100 Message-ID: <14843431.FUOnbjgNY3@pintsize.usersys.redhat.com> In-Reply-To: <8619DF06-74FA-40F5-B774-CCEAE9C705B8@akamai.com> References: <6707938.yJ1mNgvnlj@pintsize.usersys.redhat.com> <8619DF06-74FA-40F5-B774-CCEAE9C705B8@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1947408.X4ofrZMmik"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 04 Dec 2017 18:57:51 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2017 18:57:53 -0000 --nextPart1947408.X4ofrZMmik Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 4 December 2017 19:52:59 CET Salz, Rich wrote: > > > Adam Langley posted something to this list awhile back, but I can= =E2=80=99t > > > find it sorry. > > > > I haven't seen him mention any names either >=20 > =20 > I wasn=E2=80=99t clear. He posted that they weren=E2=80=99t going to pos= t names. oh, then that does match my recollection but I'm similarly disappointed about the opaqueness of the whole process =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 115, 612 00 Brno, Czech Republic --nextPart1947408.X4ofrZMmik Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlolmq0ACgkQkqjRuAHS 9fX5bQ//dvJAR0Z39JhUkAlfLfh+kfePVvPaxiouzv0WjfAybG7ur3CtBYD3iqT1 yCzlOF3L6FYsf5ar/fiRw/8wYTD5o0JddrGN4JNyhCUgxDRDN7c3p6f6JX9Pp0eF WUbusjPH424+s+rjf59fmZrP4oTNWs25cWzI0I13GgV/z0YC50DfsyKUn+xRxkWR LfxBIs7ceOEjCvBhjruixCZdKhMAEuBgfb4aNiZApCIGfM7D5Bx7UHuyD5onjj37 BqaN3wDWoFOqXdQW5lb0ERO65bQG3dn6Ue4kAjLhhyjFNIUiARAaErEywOqZfQ2r Ej7MJFNVp0yaTYbwj3DurlqRk3+Gk97Ma/rruYfLvWJQ4YNMXDBsXzA5d8beh+D6 dVLEYOR8xYZYonEeSKeHkPVuTTaaQXhpGI/JSK5/Mixz70ahPzLOurn8F8BM1lv6 UaOzCpydZBjwSxcNAdBvl1rRJNvTRO0zw0E2+gToqWgmU4V3XFbAczBaRmrr8hZV JkORXooqJWu+qB5KxUc4Gi9bB0ygbzTjBT2PBpBCsd5M7rb9XtCR9G+F2v6PRjlO 26J6YWId9V+maR3ZOB6LZznBBdC6qjO+jUeKcG3aOW7tzxYqXFCgZB7G3tRY0eFP c91+XxuX7vEVz4SWXP43HpdmsA3Xk3v5oJwDIyriCFOYLrHk7TI= =Fnr6 -----END PGP SIGNATURE----- --nextPart1947408.X4ofrZMmik-- From nobody Mon Dec 4 17:11:08 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED51512426E; Mon, 4 Dec 2017 17:11:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151243626091.13801.4107754124002363156@ietfa.amsl.com> Date: Mon, 04 Dec 2017 17:11:00 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 01:11:01 -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 WG of the IETF. Title : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename : draft-ietf-tls-tls13-vectors-03.txt Pages : 43 Date : 2017-12-04 Abstract: Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and ivs are shown so that implementations might be checked incrementally against these values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 4 17:19: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 64CE0126557; Mon, 4 Dec 2017 17:19:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRM7k33nBv1s; Mon, 4 Dec 2017 17:19:08 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 6895E12426E; Mon, 4 Dec 2017 17:19:08 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id 103so4403095otj.12; Mon, 04 Dec 2017 17:19: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=B8IAr1SxJCd0RDCgmRPMMHyaQgu4n1bg7R0ky0gMo1U=; b=upMo9yOGyumwBqZIlHwMYd5ej2D+euHs80yGsYJ92XttH18wJ946hlvyG88XBa0mg6 j0vhJ2Za/OkSbrq8+SQqXQIGCVh6bBTRh/GpQHiPjRwmvfTGbEYuhjS1sFTWDQmatFum ASc11PLGvg0rrZ2m7qHjkLbsXozN47Choz8tBvIdBa+W6DwI5z0oAtplM1IzaG+2Ap73 oCgIaiQX+7HJMLA+bjceJaVuNRp4chpv9/AxI1AhIf4adwEO3ddc2SLXD3o1UaDkKhmu 3mFKfIhwqoHQDI+VOe62YZQ5GlTNOqlfnJe/OTp3C0WigdXIgEuH0Q+FHTxVxpECWh95 y90A== 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=B8IAr1SxJCd0RDCgmRPMMHyaQgu4n1bg7R0ky0gMo1U=; b=AoORaFEOq4ZVpA+gikbWlkGna8WeqJXwSiUceIJ7QaZgmNcmt1t50HvfpS+R+ZImu5 cy0AzzpoA59ekBpNYg1rUj+z9XcKtIPbHsSiJb75bPU7FogMmBL2t2H9gR5lVlaXZPLO V1xUkjHlZnvyvl6Welf97d/29N/KnoaNIgnxq2hGxG+e+z7ZdZAW3yYb5/Ds9DHhR3Im W+HOiKjyVkIILpNpaf+z8CSV/WR8q5pdoOfiEfmNQuLGZ+cuh+f3IK4fbMGFtJpP6PYd wSNAp6MXBd6HqnCHbX7M3q4wWc5gHchE5i6zPoErQZQSb2YgO2XXB3PoEs26N+T4xcbp kjlw== X-Gm-Message-State: AJaThX7dbSU5ut0hteih7QgdpmirbLCcWHj7oFslgtby7IoQBX4Pfq5P j8V6aiuAc4Fb4XU/yYi1zkJrxxW34lQ4B2QX08VETw== X-Google-Smtp-Source: AGs4zMYqNVvnAGIs7nwyrod0G1BOQ/Xub4kPUZRXcUqDvDISEijqbwz4gLCW/G9uKjgoIohcb05x/CzcPU7bPSDlS44= X-Received: by 10.157.88.141 with SMTP id x13mr16808339otg.175.1512436747494; Mon, 04 Dec 2017 17:19:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 4 Dec 2017 17:19:06 -0800 (PST) In-Reply-To: <151243626091.13801.4107754124002363156@ietfa.amsl.com> References: <151243626091.13801.4107754124002363156@ietfa.amsl.com> From: Martin Thomson Date: Tue, 5 Dec 2017 12:19:06 +1100 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 01:19:10 -0000 This should be up to date with draft-22 now. On Tue, Dec 5, 2017 at 12:11 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Example Handshake Traces for TLS 1.3 > Author : Martin Thomson > Filename : draft-ietf-tls-tls13-vectors-03.txt > Pages : 43 > Date : 2017-12-04 > > Abstract: > Examples of TLS 1.3 handshakes are shown. Private keys and inputs > are provided so that these handshakes might be reproduced. > Intermediate values, including secrets, traffic keys and ivs are > shown so that implementations might be checked incrementally against > these values. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Dec 4 17:25: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 5421812426E for ; Mon, 4 Dec 2017 17:25:03 -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 2ItJm8WsN_P9 for ; Mon, 4 Dec 2017 17:25:01 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE11A1242F5 for ; Mon, 4 Dec 2017 17:25:00 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v190so419307ywg.4 for ; Mon, 04 Dec 2017 17:25:00 -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=4g4LX+W+Ii6jb64jLDvtyWOolmsaRY59dhHGJq0/TIc=; b=QDE6o5QgOp3AGmr+WVM9Z89YbQYhxOBsvP1aEGY4BmwBLpQ5rVVRJ+/dHFel1+Fsxl HmzAGUIY5VQC2Ddx1s18iGgwzInibrKQ1+AAg7MUNluQ7LbRW4SFR9q0y1MtdfPPPGDm vwpPje0xTBYV4sc224DyqiGeukT6Gf5AeqVtDd9olW1bASS4v6/7uaaBaLuYwuk48UVY e30CL1u8FC74ZLxVmiCAEUpzi8eP3LHIlQ0KccFPcpI51G8+fM2tKR2ss/tmQVS0A/wx UCdjoVAla/WmGugkNe/O8UHfvpHRJNsnCW12625R8R98Y0yaj/UwkYluAcdWD/S+K7Y9 +j/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:from:date:message-id:subject:to; bh=4g4LX+W+Ii6jb64jLDvtyWOolmsaRY59dhHGJq0/TIc=; b=ptA8B1SShrm/7xXQPPsQ0lbbRbjhZqk63sfkaOQ0Y7WOWrTW9EZRDgK2MBQypxN52m N6dNbVLXCwbqslVPJgMtZC8MAFBR3kvtJbnnpxJGH/LhjTtHTxejkKrEIcBsCBAsC9eC 6x2gANo5IPsUz3dHtrXEC4BEOgimN/o8zAYJmgENzkiuITzy/IpQ/dLJiUMQInV0lvxZ yN4ykHnhJgq7XFoblW79PJ9eetu/vU60ifZOGbLhb/3ZnfDmrdywgg3ap1Y+4nCFWSni 44IT8d4jmUEOmDKKjRNM7ZRce/994+qlAdf9ZOu6h/hbQF84SogViU68rovN4ABE46zR NA2Q== X-Gm-Message-State: AJaThX4z63TixukGgVijJytMhXU82fWFcnMw70q7ZSLwbj5C2CIdtVs7 x3+9tVnosexh6TcZNe+w9R1bCaGxNJaew60B4hDnSTehiyw= X-Google-Smtp-Source: AGs4zMZmeO5zn3Mv7mtrWbGghoDs5fRFs0bOK1Dnx3bD04clYZ2V6etE9Jh/D/UhsyfUOgqGdEGHu/NT83Sqzl1UqeU= X-Received: by 10.129.85.198 with SMTP id j189mr11232669ywb.504.1512437099810; Mon, 04 Dec 2017 17:24:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Mon, 4 Dec 2017 17:24:19 -0800 (PST) From: Eric Rescorla Date: Mon, 4 Dec 2017 17:24:19 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f169e146c41055f8db479" Archived-At: Subject: [TLS] Closing on PSS. PR#1114 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2017 01:25:03 -0000 --001a113f169e146c41055f8db479 Content-Type: text/plain; charset="UTF-8" Hi folks, I've put together a PR that attemps to address the PSS issue. See: https://github.com/tlswg/tls13-spec/pull/1114 Because there are platforms which don't have any support for PSS in the cert validator, at all, it seems like we MUST be able to express the following: 1. I accept PSS in CV, but nowhere in certificates, and the SPKI MUST be of type rsaEncryption (because this is what Chrome can do on some platforms). Going forward, we want to be able to express: 2. I accept PSS in CV *and* everywhere in the certificate chain (otherwise PSS certificates are dead) 3. I accept EdDSA in CV but not for signing certificates (note that this is subtly different from the PSS case because you would need an EdDSA SPKI) 4. I accept EdDSA in CV and everywhere in the cert chain Of these, #4 is mandatory, but #2 and #3 are pretty nice to have if we want fast deployment. Otherwise, it's not possible to roll out EdDSA (or other new algorithms) to browsers which don't have full support in the validator, which, based on history, seems like a pretty common situation. Unfortunately, this seems to require two distinctions: 1. CV versus cert chain (for any incremental deployment) 2. PKCS#1 versus PSS (for the goofy PSS case). So, I think in order to address this problem we need two constructs: - A separate extension that refers only to the cert chain - Two sets of RSA code points, one for PSS and one for PKCS#1. For the first, we would introduce a new signature_algorithms_certs which says: "this is what I support for the signature algorithms in certificates" (and by extension SPKI) If this is present, you filter: (a) CV signatures/EE keys against signature_algorithms (b) the signatures on certificates (and keys of their signers) against signature_algorithms_cert If it's absent, you filter everything against signature_algorithms as in the current design. For the second, we would have: - rsa_pss_shaX_rsae == "I support PSS signatures with rsaEncryption SPKI" [these would use the current rsa_pss_shaX code points] - rsa_pss_shaX_rsassa_pss == "I support PSS signatures with RSASSA-PSS SPKI" To go back to our requirements, you would say #1 (PSS in CV only, with rsaEncryption) as: signature_algorithms = [rsa_pss_shaX_rsae] signature_algorithms_cert = [rsa_pkcs1_shaX] You would say #2 (full PSS) as: signature_algorithms = [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss] signature_algorithms_cert = [rsa_pkcs1_shaX, rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa-pss] You would say #3 (EdDSA in CV only as) signature_algorithms = [ed25519] signature_algorithms_cert = [something else like ecdsa_secp256r1_sha256] And finally, #4 (full EdDSA support) signature_algorithms = [ed25519] signature_algorithms_cert = [ed25519] I recognize that this isn't totally ideal, but I think it covers all the relevant cases, and even some we don't need to cover, like you would support RSASSA-PSS SPKI in the EE cert: signature_algorithms = [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss] signature_algorithms_cert = [rsa_pkcs1_shaX] Comments? -Ekr --001a113f169e146c41055f8db479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I've put toget= her a PR that attemps to address the PSS issue.

Se= e:


=
Because there are platforms which don't have any support for= PSS in
the cert validator, at all, it seems like we MUST be able= to express
the following:

1. I accept P= SS in CV, but nowhere in certificates, and the SPKI
=C2=A0 =C2=A0= MUST be of type rsaEncryption (because this is what Chrome
=C2=A0= =C2=A0can do on some platforms).

Going forward, w= e want to be able to express:

2. I accept PSS in C= V *and* everywhere in the certificate chain
=C2=A0 =C2=A0(otherwi= se PSS certificates are dead)

3. I accept EdDSA in= CV but not for signing certificates
=C2=A0 =C2=A0(note that this= is subtly different from the PSS case because
=C2=A0 =C2=A0you w= ould need an EdDSA SPKI)

4. I accept EdDSA in CV a= nd everywhere in the cert chain


Of = these, #4 is mandatory, but #2 and #3 are pretty nice to have if
= we want fast deployment. Otherwise, it's not possible to roll out
=
EdDSA (or other new algorithms) to browsers which don't have full<= /div>
support in the validator, which, based on history, seems like a
pretty common situation.


U= nfortunately, this seems to require two distinctions:

<= div>1. CV versus cert chain (for any incremental deployment)
2. P= KCS#1 versus PSS (for the goofy PSS case).


So, I think in order to address this problem we need two constructs= :

- A separate extension that refers only to the c= ert chain
- Two sets of RSA code points, one for PSS and one for = PKCS#1.

For the first, we would introduce a new si= gnature_algorithms_certs
which says: "this is what I support= for the signature algorithms in
certificates" (and by exten= sion SPKI) If this is present, you filter:

=C2=A0 = =C2=A0(a) CV signatures/EE keys against signature_algorithms
=C2= =A0 =C2=A0
=C2=A0 =C2=A0(b) the signatures on certificates (and k= eys of their signers)
=C2=A0 =C2=A0against signature_algorithms_c= ert

If it's absent, you filter everything agai= nst signature_algorithms as
in the current design.

=

For the second, we would have:

- rsa_pss_shaX_rsae=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D "I support= PSS signatures with rsaEncryption SPKI"
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[these would use the current rsa_pss_shaX code points]
- rsa_pss_shaX_rsassa_pss =3D=3D "I support PSS signatures with RSA= SSA-PSS SPKI"


To go back to ou= r requirements, you would say #1 (PSS in CV only, with rsaEncryption)
=
as:

=C2=A0 signature_algorithms =3D [rsa_pss_= shaX_rsae]
=C2=A0 signature_algorithms_cert =3D [rsa_pkcs1_shaX]<= /div>


You would say #2 (full PSS) as:

=C2=A0 signature_algorithms =3D [rsa_pss_shaX_rsae, r= sa_pss_shaX_rsassa_pss]
=C2=A0 signature_algorithms_cert =3D [rsa= _pkcs1_shaX, rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa-pss]

You would say #3 (EdDSA in CV only as)

=C2= =A0 signature_algorithms =3D [ed25519]
=C2=A0 signature_algorithm= s_cert =3D [something else like ecdsa_secp256r1_sha256]

And finally, #4 (full EdDSA support)

=C2=A0 = signature_algorithms =3D [ed25519]
=C2=A0 signature_algorithms_ce= rt =3D [ed25519]


I recognize that t= his isn't totally ideal, but I think it covers all the relevant
cases, and even some we don't need to cover, like you would support = RSASSA-PSS
SPKI in the EE cert:

=C2=A0 s= ignature_algorithms =3D [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss]
<= div>=C2=A0 signature_algorithms_cert =3D [rsa_pkcs1_shaX]

Comments?
-Ekr

--001a113f169e146c41055f8db479-- From nobody Mon Dec 4 17:35: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 5EF53126DED for ; Mon, 4 Dec 2017 17:35:44 -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 V7lC0vGFEk8r for ; Mon, 4 Dec 2017 17:35:43 -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 D2542120725 for ; Mon, 4 Dec 2017 17:35:42 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id w131so13180852oiw.0 for ; Mon, 04 Dec 2017 17:35:42 -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=SEckeGgQnf8dT3dxx5AFcwk9WvYD0Fc8nc4ik2tdADA=; b=fzHUtydEfEv4FHRJvZrH21COr/hZnD8bm0d9cxxCcJ4OeXF7j+v19a7GxWEWEJXtRC /Et4f2tNST1iPBT5BvN+/1qJbzk+b7QWZMOcPwwES4fzzGRnwWeXuw8704w2FXEJwCO3 KSKDPXWGV6q5Jeyn2zIPOR0Xs28qvsuoEzPt6H6sU5H1Ba2zbWPfe0fO5Fmq4mHJZVS+ 1lrQT4aQk+XtTHQQ11hEZlq788+8lquSL3thCrZYSIt2oy/uEfhtelinpmcn8xCqYFA2 jz7nQOSvE4Vu1POb8PREcdO2+lOuFzVtTVCWib/ZepaJNb8WlaM6kwF0OCkDa9SsNk8x izBw== 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=SEckeGgQnf8dT3dxx5AFcwk9WvYD0Fc8nc4ik2tdADA=; b=OoyF9UmceCk1Rr9ZCDp/iNR3vLCK4FNi+NBUV9Tk5MEo/AM5/cH8hP7Dp9fhZWDaYC cvFBLbABM7Bs8HRnKuoUa79VB3vHW8emAGTN8MqwfxPCGP4jzF9nDjTY7rOBfHia8yc6 t4/1m5IZyBu3AUtpVW1v1NYMBbiz1DxeU/qawzvSMNJi0ASojQc9OsBMxU5B+1W7/e6A lkXC+sX8OWlAmrs5Ob+8B+Tr6XpZBZzBpw3v8x+Fkee8+s96lSoBPCDbRR3E+SgvQ/EE PDsbKfzIkjxiy7IAwTzEuiFfgBthGkRp4Bm6PmGJC4ded3uSifxEAP6Om4KuUU03BAfX x1Lw== X-Gm-Message-State: AJaThX7wcbA5XKlzVO3l8CduHM73bdNBvlXUxup6d08ixn/sxhlHUx0X y5jlGcHNv4W75UQdhPV11wb5Kv6nOUunJ5WF9Ev5fA== X-Google-Smtp-Source: AGs4zMZuuMfpHQhcN+EYT0A+Tg05SoCg+XU2pyVXe4sbEjRe4jEGRdSlrBWbM4kMf0+U8n1qd3xYfvpmGMDMWbkAkII= X-Received: by 10.202.48.8 with SMTP id w8mr15076922oiw.284.1512437742130; Mon, 04 Dec 2017 17:35:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 4 Dec 2017 17:35:41 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 5 Dec 2017 12:35:41 +1100 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Closing on PSS. PR#1114 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2017 01:35:44 -0000 On Tue, Dec 5, 2017 at 12:24 PM, Eric Rescorla wrote: > - A separate extension that refers only to the cert chain > - Two sets of RSA code points, one for PSS and one for PKCS#1. To be clear, this is two sets of RSA-PSS code points, one for PSS SPKI and one for PKCS#1 SPKI. That's awful, but I agree that it is necessary. I like the overlap with signature_algorithms and signature_algorithms_cert, because it makes the simple design possible without making the horrible intermediate steps possible. From nobody Tue Dec 5 03:00: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 832921292F5 for ; Tue, 5 Dec 2017 03:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjgos1F5A8Gg for ; Tue, 5 Dec 2017 03:00:40 -0800 (PST) Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A440128CFF for ; Tue, 5 Dec 2017 03:00:37 -0800 (PST) Received: by mail-wr0-f182.google.com with SMTP id v105so20525390wrc.3 for ; Tue, 05 Dec 2017 03:00:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=EgpjNOW3QEqjTsj+Jpun+Y4X9TR9VRVs84jve4uktSI=; b=i/FDd/6+ehgEgN0LLJ/O9/G5jCHOXInz9AMfu4d5aPeQhFE3FdL/GzygxbjEQr17fH QfP27Mgi2CzD/GmM0V1kOwboUMdDg1Ir0/sStRuxRTu23TkSmGG3uAEuSDKjj1YViagn qVSkueXcgUiGIrx+gr3KTOubft+xM3mZgXSKmPTucT45Vjv3rTRT/JzqKQOrdr1J71a5 tU9Jazgld9zLG5/yHxxtsGfhRtH/k8EOna3w5uxCm9UWQzVBmDW5NEkjJmcG5IDPyuce Nt5VC4V5AurWWFikNRRCdxuOfisJkY5KYgULJz9xREDc5ZW5SnXqC729/lNi9HBpp6qs lzoQ== X-Gm-Message-State: AKGB3mJmC3xaCdktjIXq/saSIo6ssEXHVa54+3KjiujNqi+zI/BzQxpi C6ta5mHPaOGlAhFabJSjBDwWBQ== X-Google-Smtp-Source: AGs4zMYYjNqrjw+OSXGetYALMi6FmBEexyTFDxCroDBcQrU9iouA0yq2d/GupVrze9zPFhnqNZ2aEQ== X-Received: by 10.223.135.77 with SMTP id 13mr6090546wrz.142.1512471635541; Tue, 05 Dec 2017 03:00:35 -0800 (PST) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id e4sm205649wmi.14.2017.12.05.03.00.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Dec 2017 03:00:34 -0800 (PST) Message-ID: <1512471634.3587.127.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , "tls@ietf.org" Date: Tue, 05 Dec 2017 12:00:34 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 (3.26.2-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Closing on PSS. PR#1114 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2017 11:00:43 -0000 On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > Hi folks, > > I've put together a PR that attemps to address the PSS issue. > > See: > https://github.com/tlswg/tls13-spec/pull/1114 > > > Because there are platforms which don't have any support for PSS in > the cert validator, at all, it seems like we MUST be able to express > the following: > > 1. I accept PSS in CV, but nowhere in certificates, and the SPKI > MUST be of type rsaEncryption (because this is what Chrome > can do on some platforms). > > Going forward, we want to be able to express: > > 2. I accept PSS in CV *and* everywhere in the certificate chain > (otherwise PSS certificates are dead) > > 3. I accept EdDSA in CV but not for signing certificates > (note that this is subtly different from the PSS case because > you would need an EdDSA SPKI) > > 4. I accept EdDSA in CV and everywhere in the cert chain I do not see why specific platform considerations should lead such a major protocol change, at the cost of the platforms which can accomodate the requirements. I believe that such major moves for compatibility for specific platforms should be explicitly expressed in the WG charter. regards, Nikos From nobody Tue Dec 5 13:36: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 E1D7F12773A for ; Tue, 5 Dec 2017 13:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84KbXK-YPgPX for ; Tue, 5 Dec 2017 13:36:24 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9061267BB for ; Tue, 5 Dec 2017 13:36:23 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id v12so764096ybj.5 for ; Tue, 05 Dec 2017 13:36:23 -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=14+ilvUq2CKNIAX18KJKfuzLbSg4tqBpQ0lsmzqLvDE=; b=Mg2o4VWxUAJrRdXnnXmhst4hydEg3KgLytGxTwlKd6TH4Uk58OGb8KVpiBfhJeXfpz bKHH3MwZqvOYK59o6ALG0o8qql4jxKGtM5QKCBU8/mGbfyTAnDCqo+bEFkMxsje+m0AP YHMhbfDjkhg7TbpGdMtTfygoX0GT644i7JwYRUJyuFloBBgcCfg2W31T4dnKTHzQRKqz kbn2BpLICu04jeDs7KOS1ps70a3PoiLIbaUY3RdgyBhGfKdWa5NyDQLMBK7B5zeBmrL+ qWZxo02nNSjDmMOIXkVydnV0QvY5lEHKSYt/YhH0czKUS95gaXOwKCJbhKxTuEGmZOkz Irvg== 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=14+ilvUq2CKNIAX18KJKfuzLbSg4tqBpQ0lsmzqLvDE=; b=aVHvJKh1mLBmjgGeX5VBjLyrG4aAYgK3PZtoSiAUvuW5ZWoKcW6xd0VHs0t4RqN7/w Lpze1zNr1h9ZnqhweywydOZ8yBCi16X58MnyWBnMvNaWH8HZEFWbz2q5bo0dLF+K6iTW 0xrTsWeQ4NAtfSqsm4upP36zHgVnCRaspIqa65iKTS/L5H6PCWJYwhxLthKXaCMjivEk Fe/POYesrE8A2z7t+AH/Q3ETpr1KOYLYar2IHLdcWJpduF0jWl109pxE0S1/iN4KCSBU 4LP6cWHgII48K23zZ47IF3Ub160/V1sWQsjO6/T3us5ZfX67teQMRoGVklK3D7L+i8Ut /W0w== X-Gm-Message-State: AJaThX6P8mr0AQLXtmq7JAdbPbPhSOGL4uCyyuZrjemkGb//z2onlS3v 7q0grL9k5/ozbWe2MDGqE+8tuGJ4Dg246VESMTbfpzouorQ= X-Google-Smtp-Source: AGs4zMZL2H4lL0kGF0w30OUFxd8dV3bSMp7s3zFF6kzYfPFFQYo8yDtrOeZ09m3Nk2gt5+p87lUC76K5/LBIA9TI4d8= X-Received: by 10.37.246.39 with SMTP id t39mr13891883ybd.497.1512509782754; Tue, 05 Dec 2017 13:36:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 5 Dec 2017 13:35:42 -0800 (PST) From: Eric Rescorla Date: Tue, 5 Dec 2017 13:35:42 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045da8425219f5055f9ea0c2" Archived-At: Subject: [TLS] Preliminary data on Firefox TLS 1.3 Middlebox experiment X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2017 21:36:26 -0000 --f403045da8425219f5055f9ea0c2 Content-Type: text/plain; charset="UTF-8" Hi folks, I now have some preliminary numbers to share with the group based on our Firefox experiments. The executive summary is that our data confirms Google's results. More detail below. EXPERIMENTAL DESIGN This is a forced experiment in which each client tries all the variants. The experiment is deployed via a system add-on (a remotely deployable, centrally managed piece of JavaScript code), and then takes measurements by trying to do an XHR to a given URL (https://mail.google.com/robots.txt) with a specific set of flags. We do the following three measurements: - TLS 1.2 - TLS 1.3 draft-18 - TLS 1.3 draft-18 with (approximately) PR#1092 ("7e02") We take five trials for each measurement, randomly shuffling the measurement order and then repeating the shuffled pattern five times. Each trial is done with a different connection and we declare "success" when any of the five trials succeeds. RESULTS This experiment was run on a 2% sample of the Firefox Beta population who have locale set to en-US, which we selected because of very high GMail blocking rates in some locales, which is a potential confounding factor. The experimen started 11/27 and has been running through today. This gave us an initial population of 161578, of whom 160809 (99.5% completed the experiment and reported results). This produced the following results: Success Failure Fail Rate -------------------------------------------------------- TLS 1.2 158260 2549 .0158 TLS 1.3-18 158194 4743 .0291 TLS 1.3-Experiment 158194 2615 .0163 For the statistics minded, the difference between -18 and 1.2 is significant at p < .001 and the 95% confidence interval of the failure rate difference is .0122-.0143 (using R's prop.test). There is no significant difference between 1.2 and 1.3-experiment (p = .36). We've got a -22 experiment in flight now, but it will only be on Nightly, so this is probably the strongest data we will have for a while. -Ekr ADDITIONAL DETAILS The relevant NSS version: https://dxr.mozilla.org/mozilla-beta/source/security/nss/lib/ssl Experimental code: https://github.com/mozilla/one-off-system-add-ons/tree/master/addons/tls13-middlebox-ghack iPython Notebook with analysis: https://gist.github.com/ekr/598208b5399faf303453b10cb11647bf --f403045da8425219f5055f9ea0c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I now have some pr= eliminary numbers to share with the group based on
our Firefox ex= periments. The executive summary is that our data
confirms Google= 's results. More detail below.


= EXPERIMENTAL DESIGN
This is a forced experiment in which each cli= ent tries all the
variants. The experiment is deployed via a syst= em add-on (a remotely
deployable, centrally managed piece of Java= Script code), and then
takes measurements by trying to do an XHR = to a given URL
(ht= tps://mail.google.com/robots.txt) with a specific set of flags. We
do the following three measurements:

- TLS 1= .2
- TLS 1.3 draft-18
- TLS 1.3 draft-18 with (approxim= ately) PR#1092 ("7e02")

We take five tri= als for each measurement, randomly shuffling the
measurement orde= r and then repeating the shuffled pattern five
times. Each trial = is done with a different connection and we declare
"success&= quot; when any of the five trials succeeds.


RESULTS
This experiment was run on a 2% sample of the Fi= refox Beta population
who have locale set to en-US, which we sele= cted because of very
high GMail blocking rates in some locales, w= hich is a potential
confounding factor. The experimen started 11/= 27 and has been running
through today.

T= his gave us an initial population of 161578, of whom 160809 (99.5%
completed the experiment and reported results). This produced the
following results:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Success=C2=A0 =C2=A0 =C2=A0= Failure=C2=A0 =C2=A0 =C2=A0 Fail Rate
--------------------------= ------------------------------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
TLS 1.2=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0158260=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02549=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .0158
TLS 1.3-18=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 158194=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04743=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 .0291
TLS 1.3-Experiment=C2=A0 =C2= =A0 158194=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02615=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 .0163

For the statistics minded, the diffe= rence between -18 and 1.2 is
significant at p < .001 and the 9= 5% confidence interval of the failure
rate difference is .0122-.0= 143 (using R's prop.test). There is no
significant difference= between 1.2 and 1.3-experiment (p =3D .36).

We= 9;ve got a -22 experiment in flight now, but it will only be on
N= ightly, so this is probably the strongest data we will have for
a= while.

-Ekr


ADDITIONAL DETAILS





--f403045da8425219f5055f9ea0c2-- From nobody Tue Dec 5 13:54: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 07BFA12869B for ; Tue, 5 Dec 2017 13:54:37 -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 z2heS5zmU-_V for ; Tue, 5 Dec 2017 13:54:34 -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 7813D128891 for ; Tue, 5 Dec 2017 13:54:34 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id f1so771689ywd.8 for ; Tue, 05 Dec 2017 13:54:34 -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; bh=kqKKrnt+0s/YHIHzf5zcZaW7gViRTJ892l9z6k9jljc=; b=r3ejOsPZ5PA4aEkmeXe2xEqt6At0bi9o7HEU9G4BEbSEvn85R3GsrJ8HOFnOFgv1yO DWra7dyWJaP8UhQyjQnKFtAMZi1BfbDDfhK/w+nNs/oB1tB93kL6oHM91XW60xcWJNm2 /TM85qInlOuWLPUQ0m5HpbiVhO1R5jrRNfWbwOqTGB64Ixyg8Jdqqvm8vsR33vga3GAG a9MWJdBa01RKzyHbp3894ixvYuAFDpqhSpM8tOEkjzitPARBIFxjftVWpLSNiXPYPgPy Ut988/iE3me3nE4itPbmIpRqLfVQhZMgaIWKSYvPAhsUff9LvwG7Ztp3coe2V01mEy2X EFZQ== 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=kqKKrnt+0s/YHIHzf5zcZaW7gViRTJ892l9z6k9jljc=; b=q27hE2XDEDsuNqXGooPfjWOvb9nqvOcsE7wMIfUAZjv+a6lRAFhEDzgy3s9/V8SOVv eEi7ff+0GFbsJKIs8ghcD7CzyEOlVmVqrRh9cShOoMmznHrCDnqdTlFY5qjsDCI6g1LH MNXqUrbL455tGdTnAjJtUCm+o+uLkHP9iLH3kQ1DP66pCi6/dP9hr8+GoGABqiZnrFKJ 6+/qJpG1g0pEKPeDpcwNHJDzSvvrpUKILa3JxCPcXNJNLyYUo/A1xtiJTJxV7A2j+Ht7 0eLV6IJpyMypmmh/lEK+Q2vdj8IZU8OZre0c/cM1KeNHu7EAE9ESiYHGyHBEVpKhCIRC baIQ== X-Gm-Message-State: AJaThX5BZHYGHObQZDtfyLAUpyYVsVLZutzdHZbo309NyyLuRT6/8GJ5 fkSfZJAiTklRaeILEAEIgcJ5q0zz88DcfBdpLZH0cRG2id8= X-Google-Smtp-Source: AGs4zMY9pDSz+gmee+M9EIEuckM0bBWErvKyK6JDEQoFrAO7NZWU1iSMn+21CxTYe0fKo78zfly7VVpJxEk73iIlnhU= X-Received: by 10.129.87.210 with SMTP id l201mr14580006ywb.2.1512510873467; Tue, 05 Dec 2017 13:54:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 5 Dec 2017 13:53:52 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 5 Dec 2017 13:53:52 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11457576551a95055f9ee1a9" Archived-At: Subject: Re: [TLS] Preliminary data on Firefox TLS 1.3 Middlebox experiment X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2017 21:54:37 -0000 --001a11457576551a95055f9ee1a9 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 5, 2017 at 1:35 PM, Eric Rescorla wrote: > Hi folks, > > I now have some preliminary numbers to share with the group based on > our Firefox experiments. The executive summary is that our data > confirms Google's results. More detail below. > > > EXPERIMENTAL DESIGN > This is a forced experiment in which each client tries all the > variants. The experiment is deployed via a system add-on (a remotely > deployable, centrally managed piece of JavaScript code), and then > takes measurements by trying to do an XHR to a given URL > (https://mail.google.com/robots.txt) with a specific set of flags. We > do the following three measurements: > > - TLS 1.2 > - TLS 1.3 draft-18 > - TLS 1.3 draft-18 with (approximately) PR#1092 ("7e02") > > We take five trials for each measurement, randomly shuffling the > measurement order and then repeating the shuffled pattern five > times. Each trial is done with a different connection and we declare > "success" when any of the five trials succeeds. > > > RESULTS > This experiment was run on a 2% sample of the Firefox Beta population > who have locale set to en-US, which we selected because of very > high GMail blocking rates in some locales, which is a potential > confounding factor. The experimen started 11/27 and has been running > through today. > > This gave us an initial population of 161578, of whom 160809 (99.5% > completed the experiment and reported results). This produced the > following results: > > Success Failure Fail Rate > -------------------------------------------------------- > > TLS 1.2 158260 2549 .0158 > TLS 1.3-18 158194 4743 .0291 > Oops. This first number should be 156066. This is what happens when you cut and paste from your notebook. -Ekr TLS 1.3-Experiment 158194 2615 .0163 > > For the statistics minded, the difference between -18 and 1.2 is > significant at p < .001 and the 95% confidence interval of the failure > rate difference is .0122-.0143 (using R's prop.test). There is no > significant difference between 1.2 and 1.3-experiment (p = .36). > > We've got a -22 experiment in flight now, but it will only be on > Nightly, so this is probably the strongest data we will have for > a while. > > -Ekr > > > ADDITIONAL DETAILS > The relevant NSS version: https://dxr.mozilla.org/ > mozilla-beta/source/security/nss/lib/ssl > Experimental code: https://github.com/mozilla/one-off-system-add-ons/tree/ > master/addons/tls13-middlebox-ghack > iPython Notebook with analysis: https://gist.github.com/ekr/ > 598208b5399faf303453b10cb11647bf > > > > > > > --001a11457576551a95055f9ee1a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Dec 5, 2017 at 1:35 PM, Eric Rescorla <ekr@rtfm.com> = wrote:
Hi folks,

I now have some preliminary numbe= rs to share with the group based on
our Firefox experiments. The = executive summary is that our data
confirms Google's results.= More detail below.


EXPERIMENTAL DE= SIGN
This is a forced experiment in which each client tries all t= he
variants. The experiment is deployed via a system add-on (a re= motely
deployable, centrally managed piece of JavaScript code), a= nd then
takes measurements by trying to do an XHR to a given URL<= /div>
(https://mail.google.com/robots.txt) with a specific set of flags.= We
do the following three measurements:

- TLS 1.2
- TLS 1.3 draft-18
- TLS 1.3 draft-18 with (= approximately) PR#1092 ("7e02")

We take = five trials for each measurement, randomly shuffling the
measurem= ent order and then repeating the shuffled pattern five
times. Eac= h trial is done with a different connection and we declare
"= success" when any of the five trials succeeds.


RESULTS
This experiment was run on a 2% sample o= f the Firefox Beta population
who have locale set to en-US, which= we selected because of very
high GMail blocking rates in some lo= cales, which is a potential
confounding factor. The experimen sta= rted 11/27 and has been running
through today.

This gave us an initial population of 161578, of whom 160809 (99.5%<= /div>
completed the experiment and reported results). This produced the=
following results:

=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Success=C2=A0 =C2= =A0 =C2=A0 Failure=C2=A0 =C2=A0 =C2=A0 Fail Rate
----------------= ----------------------------------------=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
TLS 1.2=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0158260=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A02549=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .0158
TLS 1.3-18= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 158194=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A04743=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .0291

Oops. This first number should be 156066. This is what= happens when you cut
and paste from your notebook.
-Ekr


TLS 1.3-Experiment=C2=A0 = =C2=A0 158194=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02615=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 .0163

For the statistics minded, the di= fference between -18 and 1.2 is
significant at p < .001 and th= e 95% confidence interval of the failure
rate difference is .0122= -.0143 (using R's prop.test). There is no
significant differe= nce between 1.2 and 1.3-experiment (p =3D .36).

We= 've got a -22 experiment in flight now, but it will only be on
Nightly, so this is probably the strongest data we will have for
a while.

-Ekr


--001a11457576551a95055f9ee1a9-- From nobody Tue Dec 5 17:01: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 8D8881273E2 for ; Tue, 5 Dec 2017 17:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvrZ9q4Srf_A for ; Tue, 5 Dec 2017 17:01:02 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541721200F1 for ; Tue, 5 Dec 2017 17:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1512522055; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=9455; bh=XaLip5ievsXy/UE9xUng6l9n+EBcdOHQfNDdD9Tn75U=; b=BTqBKtundWqieu7II2T3qSnRAohAWdSYqe3ek7t3IeiKBTYgHefuZkCiEHGjJnMR SGPUTXghCxfHk2YoBGEm7mf36/d2X7Sdg2Jmyq+jwYFEEqegbdDtWI9vJLhKc4oxVDK XkRtDwZHFaNYEWEi/T5QtkeULNulDnYYrBkpxYXY= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1512522055743249.4272374754022; Tue, 5 Dec 2017 17:00:55 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Tue, 05 Dec 2017 20:00:53 -0500 From: R du Toit To: Message-ID: Thread-Topic: [TLS] TLS 1.3 draft 22 middlebox interaction References: <20171203155552.GA8097@LK-Perkele-VII> In-Reply-To: <20171203155552.GA8097@LK-Perkele-VII> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3595348855_381150038" X-ZohoMailClient: External X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D Archived-At: Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2017 01:01:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3595348855_381150038 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thank you for the thoughtful responses so far. I have been working in the = middlebox arena for more than 20 years, and I am also concerned about the st= ate of certain implementations. I would like to think that the TLS stack th= at my team and I maintain have no serious security flaws, but vulnerabilitie= s in TLS stacks have shown that even people with the best of intentions get = things wrong at times. Security conscious middlebox vendors would certainly= like to fix their bugs, while at the same time improving interoperability w= ith TLS 1.3. The middlebox in my original post, for example, has already fi= xed the 0-RTT draft-22 interop issue. =20 Anyway, that is my way of saying that there are many people like myself fol= lowing the TLS WG email threads, and we all want to help make TLS a success = for consumers and enterprises. It would be good if middlebox vendors could = actually participate in experiments - especially to iron out some of the cor= ner cases. =20 I also want to reply to some specific comments: =20 >> If you're a protocol enforcing middlebox (ugh, these shouldn't exist) yo= u should get out of the way. Middleboxes often need to decide if they want to be a MITM or not on a per-= session basis. This requires parsing the CH as if the middlebox is a TLS se= rver. It should always be safe to parse the CH, but while the middlebox is = in this =E2=80=9Cserver phase=E2=80=9D it might receive unexpected data before TLS versi= ons have been negotiated, or before the middlebox has even decided to termin= ate the TLS session. I agree that the middlebox should not try to enforce p= rotocol checks beyond what is certain. Up until TLS 1.3, any record that fo= llows a CH before SH is received was a protocol error. It was also a possib= le indication of attack. For example, many simple attack scripts looking to= exploit Heartbleed would send a heartbeat record immediately after the CH, = without waiting for a reply from the server. I agree that the right place t= o fix Heartbleed is on the server, however there are still vulnerable server= s out there, and this sort of protocol validation does in fact help. =20 >> Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reig= n to change everything past the ServerHello again. The questions here were actually with regards to 0-RTT data, which occurs b= efore the ServerHello. If the middlebox supports only TLS 1.2, and it termi= nates TLS, is it correct for the middlebox to break the connection when it s= ees 0-RTT data? Will this be counted as a middlebox =E2=80=9Ccausing=E2=80=9D a failure= , because it does not seem like there is another option for the middlebox if= it is terminating the TLS session. =20 >> If any of these happens, you are dealing with Undefined Behavior ... Indeed, and I can imagine other fields being overloaded. Who would have th= ought at the time that cipher-suites would one day be used as backwards comp= atible signals that can propagate through poorly implemented middleboxes; "r= andom" bytes already have special meaning; unknown record types were used in= attacks; etc. =20 >> However, note that none of the above actually covers 0-RTT. This is beca= use no earlier version envisioned anything like 0-RTT. Exactly! =20 --Roelof =20 --B_3595348855_381150038 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Thank you for the thoughtful= responses so far.  I have been working in the middlebox arena for more= than 20 years, and I am also concerned about the state of certain implement= ations.  I would like to think that the TLS stack that my team and I ma= intain have no serious security flaws, but vulnerabilities in TLS stacks hav= e shown that even people with the best of intentions get things wrong at tim= es.  Security conscious middlebox vendors would certainly like to fix t= heir bugs, while at the same time improving interoperability with TLS 1.3.&n= bsp; The middlebox in my original post, for example, has already fixed the 0= -RTT draft-22 interop issue.

 

Anyway, that is my way of saying that there are ma= ny people like myself following the TLS WG email threads, and we all want to= help make TLS a success for consumers and enterprises.  It would be go= od if middlebox vendors could actually participate in experiments - especial= ly to iron out some of the corner cases.

&n= bsp;

I also want to reply to some specific = comments:

 

>> If you're a protocol enforcing middlebox (ugh, these shouldn= 't exist) you should get out of the way.

Mi= ddleboxes often need to decide if they want to be a MITM or not on a per-ses= sion basis.  This requires parsing the CH as if the middlebox is a TLS = server.  It should always be safe to parse the CH, but while the middle= box is in this “server phase” it might receive unexpected data b= efore TLS versions have been negotiated, or before the middlebox has even de= cided to terminate the TLS session.  I agree that the middlebox should = not try to enforce protocol checks beyond what is certain.  Up until TL= S 1.3, any record that follows a CH before SH is received was a protocol err= or.  It was also a possible indication of attack.  For example, ma= ny simple attack scripts looking to exploit Heartbleed would send a heartbea= t record immediately after the CH, without waiting for a reply from the serv= er.  I agree that the right place to fix Heartbleed is on the server, h= owever there are still vulnerable servers out there, and this sort of protoc= ol validation does in fact help.

 

>> Someday the TLSWG will design TLS 1.4= which, like TLS 1.3, has free reign to change everything past the ServerHel= lo again.

The questions here were actually = with regards to 0-RTT data, which occurs before the ServerHello.  If th= e middlebox supports only TLS 1.2, and it terminates TLS, is it correct for = the middlebox to break the connection when it sees 0-RTT data?  Will th= is be counted as a middlebox “causing” a failure, because it doe= s not seem like there is another option for the middlebox if it is terminati= ng the TLS session.

 

>> If any of these happens, you are dealing with Unde= fined Behavior ...

Indeed, and I can imagin= e other fields being overloaded.  Who would have thought at the time th= at cipher-suites would one day be used as backwards compatible signals that = can propagate through poorly implemented middleboxes; "random" byt= es already have special meaning; unknown record types were used in attacks; = etc.

 

>> However, note that none of the above actually covers 0-RTT. This = is because no earlier version envisioned anything like 0-RTT.

=

Exactly!

 

--Roelof

 

--B_3595348855_381150038-- From nobody Tue Dec 5 21:06:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00179129467 for ; Tue, 5 Dec 2017 21:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.489 X-Spam-Level: *** X-Spam-Status: No, score=3.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuMRauBr4afS for ; Tue, 5 Dec 2017 21:05:58 -0800 (PST) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18D2128D6F for ; Tue, 5 Dec 2017 21:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1512536757; bh=wl1s7HcALMNFe1IU70L3Mz1SnUFADAOR7GciwcNEIao=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=W4fGNAfKCa5sgAAdWldiFjUKPckrZReNAqYL44TllzerpFrQWno2NSOZrfILSL66WmhV/DGPsu7uAa9nW47Lm72+bJCN96QFdMR03R4HeMnrySXxCcPy6IqJo7f6HJSCT8ws3eOiW/s/lZWOX0HRznxDlaZgqhCU9Y3DKpsPyhMDHi7LLT7jk/S6J53/G8HR0gs1RlM0ryu4N0uvvIbVQZ44w6yW68iWY24rW25pjtVG06aFfu+fMcDpXfz34GJq2d/eHxz2SGB2JcHtYK5ppHcpDyUtSUybitrztvY+JJYF7dcaREWX7W+yRJPb5GnoQlrC+RCMPuibdwoxqlYF2w== X-YMail-OSG: uxs67VAVM1lbbn4IS9EPPlA9whY7FOKb6D2dCBHyBElXUj4.HJ6AWaZ8e22wTsm Uvj.19wvEBPcm3DGQApu80L_i9BxDh3clp3pRm6jZWW4H9HrU67siGRGlCQeb8dZrWxVJinBpzno ZDaMYvJVe3wtK9B.d4tGpJXt4Z7603Z5RfK8ncJqiY.dbpNF.LZcYQfmWfJTjmKTGX0iTMI4w934 NWOU_gfl_K4ZT_Spjqky2v4I5drvvhPFDpk5tBINkdBJZwzCVBRDR9LYl7ECVJXensJ.kWnqTd0B EGFzIHXx6FjVcZgUNp3gNjGCow9XCY9T1CfcCcRKiVwM6JKdcaG70fcUvp0lFgQdBnugEw3dLNyL 0B2ntx2TJxwNs.6dRGO7hEJ6sENozV66IeLNi41dgSBLnT_OXcOwB8Hj8UVM2m.2q7bIciZ17Jko 3GxBtpGgnYMqcoIuLF91QoKPuY04MndU8O9uI2HfmksRZdXA51ljj.MSNq2dVJpDoY3MFQ0AMNcS y27NEuiqLhv61fpUNvXXftQs46PHL9cSVeN9.wu17hqVDW2Bs8E9u9ebWGAlw9O40RmhJ0_XN_8g WwkD0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 Dec 2017 05:05:57 +0000 Date: Wed, 6 Dec 2017 05:05:52 +0000 (UTC) From: Jitendra Lulla Reply-To: Jitendra Lulla To: Message-ID: <1789795499.2668959.1512536752976@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1789795499.2668959.1512536752976.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11015 YahooMailBasic Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Archived-At: Subject: [TLS] rfc 6520 TLS heartbeat feature X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2017 05:06:00 -0000 Hi, As tls 1.3 is being worked upon, older work like rfc 6520 and any enhancements to it may not be as important. Also, particularly the TLS heartbeat feature, which has become famous for wrong reasons, is disabled by the SSL implementations eg OpenSSL. I tried to uncover an issue below pertaining to the heartbeat messages here: https://www.mail-archive.com/openssl-dev@openssl.org/msg47273.html Experts struggle to find any significant use of this feature for both the TLS and DTLS. I am planning to propose enhancements which will include restricted issuance of the heartbeat requests (wrt size and frequency) to avoid the exploit mentioned in the link above. A stronger standard will trigger bug/vulnerability free implementations. I would like to know if enhancements to this rfc are welcomed or it is there to be abandoned completely? In other words, is it worth spending time? Thanks Jitendra From nobody Wed Dec 6 06:08: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 4AE09128D0D for ; Wed, 6 Dec 2017 06:08:17 -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 (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I42xXggp64Pj for ; Wed, 6 Dec 2017 06:08:08 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BAE128D86 for ; Wed, 6 Dec 2017 06:07:59 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB6DvZTQ011673; Wed, 6 Dec 2017 14:07:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=nXOFpAfnglzXGwiCDU211qFXSI9VChyNN6zAUVm7IrI=; b=aQBhvEfj0ux9fBGpPZT8Z6zkOClyrYJ0sRWYyWZ0YP0OXZh3VOqWas1KkHJntN5HdlzT lOylLnZP19GyVaafwPe+EWFJxcz65Wi8AAUZmXTzFeE+YgkMEn758Xj9f7V6hYVrd80G MaksHD8WHKm68M5M7NgdMwXMhheYv48ateFRV52CC8/KcxZa8ZPcogx64HP50m63Q3tv m7hcGV2WBT72YwG0wy00JO76z4cY+6kdbr+KYMZmU5+SkYnPmv4zMsIKYV1D4dP+sLen mJAg8cSr+Uo+tIWpzKzxA4GCV21+N+zOBzRyOTYc0ewch7PsStSKQuhurJQ4WXVocSGX FQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2ekpp4cy30-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Dec 2017 14:07:58 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vB6E5tkp019619; Wed, 6 Dec 2017 09:07:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ekrcyq329-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Dec 2017 09:07:56 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 6 Dec 2017 09:07:56 -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.1263.000; Wed, 6 Dec 2017 09:07:56 -0500 From: "Salz, Rich" To: Jitendra Lulla , "tls@ietf.org" Thread-Topic: [TLS] rfc 6520 TLS heartbeat feature Thread-Index: AQHTbk/uAw35QayBaEmpJg0vFM/7zqM2rmqA Date: Wed, 6 Dec 2017 14:07:55 +0000 Message-ID: References: <1789795499.2668959.1512536752976.ref@mail.yahoo.com> <1789795499.2668959.1512536752976@mail.yahoo.com> In-Reply-To: <1789795499.2668959.1512536752976@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.25] Content-Type: text/plain; charset="utf-8" Content-ID: <01268CA02E20724588F978893C6BBA5D@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712060206 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712060204 Archived-At: Subject: Re: [TLS] rfc 6520 TLS heartbeat feature X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2017 14:08:17 -0000 4p6iIEluIG90aGVyIHdvcmRzLCBpcyBpdCB3b3J0aCBzcGVuZGluZyB0aW1lPw0KICAgIA0KWW91 IG1pZ2h0IGZpbmQgaXQgd29ydGh3aGlsZSB0byBsb29rIGF0IFBldGVy4oCZcyDigJxMVFMgZm9y IFRMU+KAnSBkcmFmdC4NCg0KIE5vYm9keSBjYXJlcyBhYm91dCBoZWFydGJlYXRzIGFuZCBmb3Ig dGhpcyBpc3N1ZSwgdGhhdOKAmXMgcHJvYmFibHkgZ29vZCBlbm91Z2guDQoNCg== From nobody Wed Dec 6 13:35: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 6C2F3127286 for ; Wed, 6 Dec 2017 13:35:37 -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, 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 fTzMcPIP7g0x for ; Wed, 6 Dec 2017 13:35:35 -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 21DCE1275FD for ; Wed, 6 Dec 2017 13:35:35 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id v22so5403817wrb.0 for ; Wed, 06 Dec 2017 13:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ax9xVw34eC5kReLlhTNBogVF6Mdxc5pC9j3edQxVENg=; b=R+iMk2I6N7GBIJMnVXSOk4mbQ8UOzjdmUjlxEK3XdXA9xsZIXwSRevnnHQL1RQThnG yJ02SpCtggG20Y7Hl+WgIwC+jyDcmHxcWr+SpPJpBs1RRR2Pb20dkvcLCm/P30MPL0rk dV/szJe0Fa7LjV+KMwpt0L58HtF8hAuZspcABg4zBVP2KRDiCQoWttCWkZntK84qDgP+ 9MfyNHCCxHIF8y9HuYjYSBCMzK8jOUZ5RLTFNX7l9sUz4f/XjRl4IV9d8TBdvL04yg67 BfVYyioGBP6HZZ9AGz7zjhA7hbMbsv//wD2Bts2uGDq7C/HBzTL9ysdBUwj7ULh8uHpJ Xh/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:references:in-reply-to:from:date :message-id:subject:to; bh=Ax9xVw34eC5kReLlhTNBogVF6Mdxc5pC9j3edQxVENg=; b=KpBEKPuAqBwu3Sq+8tN7DilGBAiuSzv3xZaLnpldg3JKMITs7mvtYndEorO38wa8hA Sqwt4cDCPsqf36L0zGJIUu/YWs7uqU08sxG1HSZR0h1fMxRDntPGTaa49yq/Uy1SeBOL j1uSNDMoq0EjuRm3b3fFe/ww850DV0/m2IyfsJAyEgRnG+JHratHuaa/vp7axXjOaMwp 4YAcV6Iu5nUWQfsDh36X9WyWlBDpRFihTSklJsaPLSGDrbypNCvQ4ZwFlEYMrejBTDCJ wwmzKmev16mCS6sI6hJUDdvu5SpJ4nDx0LhRr9DickSoNG8tVYxXtEpAEEIRMubNY50D NHTQ== X-Gm-Message-State: AJaThX5car1ROTLmDT2MUh2EEp6TDLCWgz5vRmmsTw+IwN26kSdyhyiV DWdvKPdEAqcAX9aGK5qH11H8KQipSdCB7NxM0L8= X-Google-Smtp-Source: AGs4zMYL22y1pciYYSwtSweWgDsA91OWQZHNWAz4AK/8ZCvZZbsvJ+JNDX4zMxAlcXaip1PAr6B4hmOM89cNJ9gKal4= X-Received: by 10.223.135.1 with SMTP id a1mr22108212wra.50.1512596133395; Wed, 06 Dec 2017 13:35:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Wed, 06 Dec 2017 21:35:22 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1147dc4e384261055fb2bb12" Archived-At: Subject: Re: [TLS] Exported Authenticators proposed change to incorporate authenticator request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2017 21:35:37 -0000 --001a1147dc4e384261055fb2bb12 Content-Type: text/plain; charset="UTF-8" This is an uncontroversial change and nobody has responded from the list, so unless someone has any objections I'm going to incorporate this change (along with a change to address Benjamin Kaduk's comments) and publish a new draft next week. Nick On Thu, Nov 23, 2017 at 1:18 PM Nick Sullivan wrote: > Martin Thomson raised an issue Github (Issue #5 > ) > suggesting that we modify the exported authenticators draft to include the > ability to incorporate a CertificateRequest into an authenticator. I have > put together a set of changes to the draft to incorporate this suggestion: > https://github.com/tlswg/tls-exported-authenticator/pull/9 > > The advantage of this change is that it provides a more explicit binding > between a request for an authenticator (which includes TLS extensions) and > the authenticator itself. This change also significantly simplifies the HTTP/2 > Additional Certificates draft > > that depends on exported authenticators. I presented this change at IETF > 100 and there were no objections. > > Comments welcome, > Nick > > > > > > --001a1147dc4e384261055fb2bb12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is an uncontroversial change and nobody has resp= onded from the list, so unless someone has any objections I'm going to = incorporate this change (along with a change to address Benjamin Kaduk'= s comments) and publish a new draft next week.

Nick
<= br>
On Thu, Nov 23, 2017 at 1:18= PM Nick Sullivan <nichol= as.sullivan@gmail.com> wrote:
Martin Thomson raised an issue Github (Issue #5) suggesting that we modify the exported authenticators draft to= include the ability to incorporate a CertificateRequest into an authentica= tor. I have put together a set of changes to the draft to incorporate this = suggestion:
https://github.com/tlswg/tls-exported-authent= icator/pull/9

The advantage of this change is th= at it provides a more explicit binding between a request for an authenticat= or (which includes TLS extensions) and the authenticator itself. This chang= e also significantly simplifies the HTTP/2 Ad= ditional Certificates draft that depends on exported authenticators. I = presented this change at IETF 100 and there were no objections.
<= br>
Comments welcome,
Nick

=C2=A0



--001a1147dc4e384261055fb2bb12-- From nobody Wed Dec 6 15:35:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E6E126B6D for ; Wed, 6 Dec 2017 15:35:40 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnOJDvUtTnIt for ; Wed, 6 Dec 2017 15:35:38 -0800 (PST) Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026F51205F0 for ; Wed, 6 Dec 2017 15:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=9eZ/lzss19/hOVO+YjTqdFJIv4DpF9uYS0dA9/PKzvk=; b=Rt8m5HPsfspdsS1zzy4CTtEYJcTvcl/SXBIZuHNbsUyjcgJ2vr8hfJpsrFnNVNJZXmSZ+1m08kkUW13UgtjLWLSw/VjCcHCEJZ8LTyRuLDB+qeJsqCJm2uqwZ/n4wjCxc9vb6g/GOORfrIIRmDoX9IxFWDqF6mL4CFD7E5VMMtOEJDW4TEHhNT0BOV6ydlQPahpjg1I+hQUOY19l1q59bb53aY986CGppdTPyKCwTkkn5xrg2qasacYZPVb1k/qd/zbdVplOgxPICkpd7jVFKtz5mJ8lc6oPKYjR6wq4dNdtauwF7fzrGOHoHZc+YMojP7bU8sevpXYRmdw699hu/g==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eMjDy-0006lx-55 for tls@ietf.org; Thu, 07 Dec 2017 00:35:35 +0100 Date: Wed, 6 Dec 2017 23:35:30 +0000 From: Peter Wu To: tls@ietf.org Message-ID: <20171206233530.GC29946@al> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: [TLS] Reference for justification of middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2017 23:35:40 -0000 Hi, The current draft makes the following claim: Field measurements have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Would it be possible to add a reference for this claim for the benefit of future readers? One possible (terse) reference I could find is https://www.ietf.org/mail-archive/web/tls/current/msg24517.html -- Kind regards, Peter Wu https://lekensteyn.nl From nobody Wed Dec 6 15:43:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9AB12762F for ; Wed, 6 Dec 2017 15:43:31 -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 kxlbVzFHJQcV for ; Wed, 6 Dec 2017 15:43:29 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B636612894A for ; Wed, 6 Dec 2017 15:43:29 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id m129so2263671ywb.11 for ; Wed, 06 Dec 2017 15:43:29 -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=qHn3jhWQuv3IzPT97nZAtOyK4ymtvEkgIdllac80blo=; b=VYZneYOyx6Alc5kUiB5EXkOT1FmS+ChOdRsTKdXwRiEcQoZNL6MdQQhHaKpN9GekQb 5exXLMdVu8dFmlh/+Plo6sWokENuLYMWZEoaGAxEagKU8r8iIXJlhf/RWTOmA5HvqVoU InpreIEhiCg4ieg6Hpoo8s1nCDexcZ7iAKT/sa/XujtwJ8aoCVn9Ow8V/CiT8WOMkCh5 4F5gqcwrMdAMHYhbl5UiJhD94ocPjH79IxhDM+dNm3dptztHuJ5uT90HX8IrxgMsVFJq BPluR6/zQ8qFTvp517HIckuahnLqTX9ZDt2Ic6O4DiPreexY667V9r57rwPWpotUiW6Y IDmg== 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=qHn3jhWQuv3IzPT97nZAtOyK4ymtvEkgIdllac80blo=; b=neGyROo9CS0Qjl1FVMlPI+sNqiOfP3r+So8fQTyqFOjne8kEAOzietgW1badNXHZpK 6TAKGMxAb+t4p4e8MJc9epEZKumZLYU2ecXZYcFpsyrKE1ClTCW3xita+eHXANAhX1LW qcEbzCO1Ys3WTm7/WUq+ykhuyK/yDZVVGhz4KKAcIMqnbtutfJ+KtFQvPRsYt3hhWh3w Vdy0gylMuqVzNT39yb/qun2jdY+mH2I/un9SuB4PZQoNY0/f3qyPZvQU7edBnvkeY/Nx uuJl9lJq9eI9Er1zHHJLtACfHYEwUyNfNdHqu27FeSA+D49nBCt/+hknsK5UMVTT7pS7 jvDA== X-Gm-Message-State: AJaThX55N9ddFgy9NieYZjH83OZS8LDM4kGDZWaKJSuo+dEGIX5KZT46 vXVp/bY58LSyfUTRSxhnXFmzP0tDHukvLMg07lMTINZdOwE= X-Google-Smtp-Source: AGs4zMamX8JC4//wGpUL1ONLfwtWHgRWO9eMVgjiHVHB6lS6n6EetGCKcHRjPMeqkgPLvMBFlY+la0AnsHvTLgZ5pik= X-Received: by 10.129.173.94 with SMTP id l30mr17506655ywk.5.1512603808995; Wed, 06 Dec 2017 15:43:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 15:42:48 -0800 (PST) In-Reply-To: <20171206233530.GC29946@al> References: <20171206233530.GC29946@al> From: Eric Rescorla Date: Wed, 6 Dec 2017 15:42:48 -0800 Message-ID: To: Peter Wu Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045ea716b8e2b5055fb484f9" Archived-At: Subject: Re: [TLS] Reference for justification of middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2017 23:43:32 -0000 --f403045ea716b8e2b5055fb484f9 Content-Type: text/plain; charset="UTF-8" I would cite: https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/ (the slides, which include David's data) https://www.ietf.org/mail-archive/web/tls/current/msg25091.html (my email from yesterday) -Ekr On Wed, Dec 6, 2017 at 3:35 PM, Peter Wu wrote: > Hi, > > The current draft makes the following claim: > > Field measurements have found that a significant number of middleboxes > misbehave when a TLS client/server pair negotiates TLS 1.3. > > Would it be possible to add a reference for this claim for the benefit > of future readers? One possible (terse) reference I could find is > https://www.ietf.org/mail-archive/web/tls/current/msg24517.html > -- > Kind regards, > Peter Wu > https://lekensteyn.nl > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045ea716b8e2b5055fb484f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




On Wed, Dec 6, 2017 at 3:35 PM= , Peter Wu <peter@lekensteyn.nl> wrote:
Hi,

The current draft makes the following claim:

=C2=A0 =C2=A0 Field measurements have found that a significant number of mi= ddleboxes
=C2=A0 =C2=A0 misbehave when a TLS client/server pair negotiates TLS 1.3.
Would it be possible to add a reference for this claim for the benefit
of future readers? One possible (terse) reference I could find is
https://www.ietf.org/mail-archiv= e/web/tls/current/msg24517.html
--
Kind regards,
Peter Wu
http= s://lekensteyn.nl

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

--f403045ea716b8e2b5055fb484f9-- From nobody Wed Dec 6 22:48:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5170112711D for ; Wed, 6 Dec 2017 22:48:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6I1V-VLxhmx for ; Wed, 6 Dec 2017 22:48:04 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3207126FB3 for ; Wed, 6 Dec 2017 22:48:04 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id e10so4583064uah.10 for ; Wed, 06 Dec 2017 22:48:04 -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=97sL84TpJbXQEtN5t96SDyHiwao4Y+MW0Zlib5SG2Iw=; b=hjVfVx++klUprHz/yDmbhfFriz2V5bBbK97Yn7yf3zxoCEm8Qi0LDbyXJdv5QjdiRn 3+WFJeHRhEhehjgOuDe//qNLPni5WuBhgf2j/6FldFxhAnsSZsgN3qxmwqouLh2mmK5Y 2mKUXtB+YPwQmYmqcWuhDxbumgyXPutXinwVbqXIOKOvMDi+xAqO4CmhCjQvU/DeOq6X lGD0kggdrSMTQC39KPhjTOUGU/ptR5fain3dA2N2jprXq8t5Me3AbTsEa5pq+YH55tTy Kl+jT2djO0fWmH/mnvKiLPc0HGIwE2C+2wAqbDvayEWYi85O4Od/wdB1nSPcC1O/EtAP gDxQ== 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=97sL84TpJbXQEtN5t96SDyHiwao4Y+MW0Zlib5SG2Iw=; b=ibwJDJpBNr9bGvnfOWp9Qj8aZ5sYa7BvbmGmEBVvO98dCErXl8qTLln271kivlDogY c9JfRFS5SUCvKyYy912Ue1wEjPxKY8ncB28lSrhNXVDWAg2F1mpGbQzayKR5Max75WZS UZzRyGLULDPZh6KUWBkffsIJWEdEwdGJFh3CvON+ZKylBLq6GTvsftW+ngYrJZLtMjAf A7qPWcUlqfgwP+458OiSWMcorZPfXlJuTb0/NgFiIbZp4voCV+UDelBR5qTqvoS0dWFa j6y8PcvtIYfwENmhcrJYYVD+4oI2wmgWbOoYyNLwh9VDqQqP34sZZcqnsK+ruOnz5sb6 3TMw== X-Gm-Message-State: AKGB3mLr4dk75n6G+jeKtNa9tSLX8JHbFUde9YQVjpsBMuvKiGtZIeYi vKaS9x3uTm5yiXvMAW+7gg7TATA6NGHlKECL/A8= X-Google-Smtp-Source: AGs4zMZKOkBsQohqneSv7APp7lXIKdpG1Mfzc0ab2kuT3nbQP8/n4PefsmfcnuTysOEAgzZTtpBZtOe5bNmV8dgPcKw= X-Received: by 10.176.82.163 with SMTP id v32mr13013904uav.92.1512629283665; Wed, 06 Dec 2017 22:48:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.59.206 with HTTP; Wed, 6 Dec 2017 22:48:03 -0800 (PST) In-Reply-To: References: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi> From: Alex C Date: Thu, 7 Dec 2017 19:48:03 +1300 Message-ID: To: Eric Rescorla Cc: Yuhong Bao , Andrei Popov , Peter Saint-Andre , "tls@ietf.org" , Tapio Sokura Content-Type: multipart/alternative; boundary="94eb2c190d42213ce9055fba73ea" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 06:48:07 -0000 --94eb2c190d42213ce9055fba73ea Content-Type: text/plain; charset="UTF-8" Thanks for the info. I see a pull request has just been submitted already: https://github.com/tlswg/tls13-spec/pull/1116 On Tue, Dec 5, 2017 at 1:03 AM, Eric Rescorla wrote: > > > On Mon, Dec 4, 2017 at 1:59 AM, Alex C wrote: > >> The obvious problem with randomly adding fake versions is you have to >> have a way of ensuring they won't conflict with *real* future versions - >> and whatever pattern you decide upon in order to do that, middleboxes will >> use that pattern to filter out fake versions, and fail as soon as you >> present one with a real future version (i.e. TLS 1.4). >> >> Can I also suggest adding a section about expected middlebox behaviour to >> TLS 1.3? That way there is a reasonable chance that TLS 1.4 won't face the >> same issues. >> (Or can I do that myself? I'm not really familiar with the process, sorry) >> >> > Yes, you can send a a PR at: > https://github.com/tlswg/tls13-spec/ > > -Ekr > > >> On Sat, Nov 25, 2017 at 8:21 AM, Yuhong Bao >> wrote: >> >>> That only applies to the ClientHello. >>> >>> ________________________________________ >>> From: Andrei Popov >>> Sent: Wednesday, November 22, 2017 11:22:23 AM >>> To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla >>> Cc: tls@ietf.org; Tapio Sokura >>> Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness >>> >>> The idea was for the client to randomly add non-existent TLS versions to >>> supported_versions. >>> Presumably, this will exercise the extensibility joint and prevent it >>> from becoming unusable. >>> >>> I'm not convinced this new approach will help, but we know the old one >>> required fallbacks every time a new protocol version was introduced. >>> >>> Cheers, >>> >>> Andrei >>> >>> -----Original Message----- >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao >>> Sent: Wednesday, November 22, 2017 11:04 AM >>> To: Peter Saint-Andre ; Eric Rescorla >>> Cc: tls@ietf.org; Tapio Sokura >>> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness >>> >>> They are basically doing a supported_versions extension with only one >>> entry in the ServerHello. >>> The problem with future middleboxes should be obvious. >>> >>> ________________________________________ >>> From: Peter Saint-Andre >>> Sent: Wednesday, November 22, 2017 11:02:39 AM >>> To: Yuhong Bao; Eric Rescorla >>> Cc: tls@ietf.org; Tapio Sokura >>> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness >>> >>> On 11/22/17 11:16 AM, Yuhong Bao wrote: >>> > The problem is not TLS 1.3, the problem is future versions of TLS. >>> >>> Would you mind explaining that in more detail? >>> >>> Peter >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=https%3A% >>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7C >>> Andrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d531db >>> dbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364697427 >>> 19473989&sdata=fCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS% >>> 2BPW8%3D&reserved=0 >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> > --94eb2c190d42213ce9055fba73ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the info. I see a pull request has just been su= bmitted already: = https://github.com/tlswg/tls13-spec/pull/1116

On Tue, Dec 5, 2017 at 1:03 AM, Er= ic Rescorla <ekr@rtfm.com> wrote:


<= div class=3D"gmail_quote">On Mon, Dec 4, 2017 at 1:5= 9 AM, Alex C <immibis@gmail.com> wrote:
The obvious problem = with randomly adding fake versions is you have to have a way of ensuring th= ey won't conflict with real future versions - and whatever patte= rn you decide upon in order to do that, middleboxes will use that pattern t= o filter out fake versions, and fail as soon as you present one with a real= future version (i.e. TLS 1.4).

Can I also suggest adding= a section about expected middlebox behaviour to TLS 1.3? That way there is= a reasonable chance that TLS 1.4 won't face the same issues.
= (Or can I do that myself? I'm not really familiar with the process, sor= ry)


Yes, you can send a a PR at:

-Ekr
=C2=A0
On Sat, Nov 25, 2017 at 8:21 AM, Yuhong Ba= o <yuhongbao_386@hotmail.com> wrote:
=
That only applies to the ClientHello.

________________________________________
From: Andrei Popov <Andrei.Popov@microsoft.com>
Sent: Wednesday, November 22, 2017 11:22:23 AM
To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
Cc: tls@ietf.org; Tap= io Sokura
Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness

The idea was for the client to randomly add non-existent TLS versions to su= pported_versions.
Presumably, this will exercise the extensibility joint and prevent it from = becoming unusable.

I'm not convinced this new approach will help, but we know the old one = required fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre <stpeter@stpeter.im>; Eric Rescorla <ekr@rtfm.com>
Cc: tls@ietf.org; Tap= io Sokura <tapi= o.sokura@iki.fi>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

They are basically doing a supported_versions extension with only one entry= in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre <stpeter@stpeter.im>
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tap= io Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=3D= 02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d5= 31dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364697427<= wbr>19473989&sdata=3DfCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS%2BPW8%3D&reserved=3D0

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



--94eb2c190d42213ce9055fba73ea-- From nobody Thu Dec 7 07:35:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF1129464 for ; Thu, 7 Dec 2017 07:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf_LtFsdBcJi for ; Thu, 7 Dec 2017 07:35:07 -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 BF431128D44 for ; Thu, 7 Dec 2017 07:35:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2209D300670 for ; Thu, 7 Dec 2017 10:35:07 -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 dxXioDWTMxAi for ; Thu, 7 Dec 2017 10:35:00 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 42489300579; Thu, 7 Dec 2017 10:35:00 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_026FA576-CAB6-4499-83B2-93A0110C3838" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 7 Dec 2017 10:34:59 -0500 In-Reply-To: Cc: IETF TLS To: Eric Rescorla References: <332B60C8-9355-4743-B663-9FAB77C55282@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] External PSK with certificate-based authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 15:35:11 -0000 --Apple-Mail=_026FA576-CAB6-4499-83B2-93A0110C3838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 2, 2017, at 1:51 PM, Eric Rescorla wrote: >=20 > On Sat, Dec 2, 2017 at 10:10 AM, Russ Housley > wrote: > At the bottom of page 136, the current draft says: >=20 > Note: TLS does not currently permit the server to send a > certificate_request message in non-certificate-based handshakes > (e.g., PSK). If this restriction were to be relaxed in future, the > client's signature would not cover the server's certificate = directly. > However, if the PSK was established through a NewSessionTicket, the > client's signature would transitively cover the server's = certificate > through the PSK binder. [PSK-FINISHED] describes a concrete attack > on constructions that do not bind to the server's certificate (see > also [Kraw16]). It is unsafe to use certificate-based client > authentication when the client might potentially share the same = PSK/ > key-id pair with two different endpoints. Implementations MUST NOT > combine external PSKs with certificate-based authentication of = either > the client or the server. >=20 > [PSK-FINISHED] tells why it is not safe to do client authentication = after resumption. >=20 > [Kraw16] says two things: (1) using a PSK from a previous handshake = and adding client authentication is not secure; and (2)does not work; = and the client signature must cover the public key. >=20 > So, the final sentence in the quoted paragraph seems to be too broad. = I do not see why we forbid an external PSK and certificate-based = authentication in an initial handshake. I acknowledge that TLS 1.3 does = not support it, but I have been expecting an extension to be specified = to do just that once the TLS 1.3 base specification is finished. >=20 > My view on this is that that's not a currently specified = configuration. A future specification could of course relax that. If you = wanted to submit a PR that said "absent some extension to the contrary" = that would be fine, though I think that's implicit. Please see https://github.com/tlswg/tls13-spec/pull/1117 = Russ --Apple-Mail=_026FA576-CAB6-4499-83B2-93A0110C3838 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On Sat, Dec 2, 2017 at 10:10 AM, Russ Housley <housley@vigilsec.com> wrote:
At the bottom of page 136, the current draft says:

   Note: TLS does not currently permit the server to send a
   certificate_request message in non-certificate-based handshakes
   (e.g., PSK).  If this restriction were to be relaxed in future, the
   client's signature would not cover the server's certificate directly.
   However, if the PSK was established through a NewSessionTicket, the
   client's signature would transitively cover the server's certificate
   through the PSK binder.  [PSK-FINISHED] describes a concrete attack
   on constructions that do not bind to the server's certificate (see
   also [Kraw16]).  It is unsafe to use certificate-based client
   authentication when the client might potentially share the same PSK/
   key-id pair with two different endpoints.  Implementations MUST NOT
   combine external PSKs with certificate-based authentication of either
   the client or the server.

[PSK-FINISHED] tells why it is not safe to do client authentication after resumption.

[Kraw16] says two things: (1) using a PSK from a previous handshake and adding client authentication is not secure; and (2)does not work; and the client signature must cover the public key.

So, the final sentence in the quoted paragraph seems to be too broad.  I do not see why we forbid an external PSK and certificate-based authentication in an initial handshake.  I acknowledge that TLS 1.3 does not support it, but I have been expecting an extension to be specified to do just that once the TLS 1.3 base specification is finished.

My view on this is that that's not a currently specified configuration. A future specification could of course relax that. If you wanted to submit a PR that said "absent some extension to the contrary" that would be fine, though I think that's implicit.

Please see https://github.com/tlswg/tls13-spec/pull/1117

Russ

--Apple-Mail=_026FA576-CAB6-4499-83B2-93A0110C3838-- From nobody Fri Dec 8 10:10: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 2749F127601 for ; Fri, 8 Dec 2017 10:10:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KZ45iCj_GBfN for ; Fri, 8 Dec 2017 10:10:09 -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 91F4B12708C for ; Fri, 8 Dec 2017 10:10:03 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id d4so27894330qtj.5 for ; Fri, 08 Dec 2017 10:10:03 -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=h1NMMM3/JNtf0T+NIlGhMgCn58rIcWO5DKdYkqgOHxU=; b=kTr2fjHF3dIlSFQg0adI0SxGLSNjkZcK+TRa+ChZPV6wdBQy5vFP7fpXDAd2f2eQys +L2vYREvgUAq1Uoc7ZV5LCIMTeXP0lNBf0/4pRKHpFXv4DVQCZZXEz67tSW3P95my8dF kJITGBkLBlFbAQf+1HV2F7OiB5uFmpE/hhotA= 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=h1NMMM3/JNtf0T+NIlGhMgCn58rIcWO5DKdYkqgOHxU=; b=au9tMbFf0S1dHoULhBQaSaK9kQhQeK1Ujc8b7XAjmrGR9xkzGcHz9qPOEDv1Vb+8ZZ giMVqwOp4A8gf29HzUVHnQQfHtLQu8sV2QcAyLCCoN1vugxTE7IcSqPx3PyM7avBScYE rWl7i5NFvmLphy1wbe7WaC6jQDNSLvRtfGur9AnygnNPRyoVGUh9CWZCwBWFpAyYP05J Dj68LGdpxDs33CXmlP2/CacxCgtJEbYkr/7hKPtHhW015iJpEKVi56Samd0lpfEsCcRT 3EuWJgvDBy6xNXBya7lsAA5iGzDAKi+gF/kFk/CB65wFH1m85Q3Cmx+Trs00vcH/mH5/ 33NQ== X-Gm-Message-State: AKGB3mKJ5wbhCiXJYCneGfb+RtXA4wRpYPFBxcEf4mMx2z4Uen5lUF/Q XQAx/VbdAPvYZnR8BfonO3fQYw== X-Google-Smtp-Source: AGs4zMYuOaGFEVOnsC5NuCy68nfzAtOxuQYQxy07QIuvyPTnvxPTuEgsMYuIDz1446hyWHEV3le6Sg== X-Received: by 10.237.60.117 with SMTP id u50mr15690642qte.6.1512756602801; Fri, 08 Dec 2017 10:10:02 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id m124sm384906qke.9.2017.12.08.10.10.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 10:10:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Fri, 8 Dec 2017 13:10:01 -0500 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1AB04DC2-18CE-4E82-91C0-4B80B2D93613@sn3rd.com> References: To: Nick Sullivan X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Exported Authenticators proposed change to incorporate authenticator request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2017 18:10:11 -0000 Nick, Agreed - it=E2=80=99s been a bit so merging next week seems good. That = way we might have a new version to read over the holidaze! spt > On Dec 6, 2017, at 16:35, Nick Sullivan = wrote: >=20 > This is an uncontroversial change and nobody has responded from the = list, so unless someone has any objections I'm going to incorporate this = change (along with a change to address Benjamin Kaduk's comments) and = publish a new draft next week. >=20 > Nick >=20 > On Thu, Nov 23, 2017 at 1:18 PM Nick Sullivan = wrote: > Martin Thomson raised an issue Github (Issue #5) suggesting that we = modify the exported authenticators draft to include the ability to = incorporate a CertificateRequest into an authenticator. I have put = together a set of changes to the draft to incorporate this suggestion: > https://github.com/tlswg/tls-exported-authenticator/pull/9 >=20 > The advantage of this change is that it provides a more explicit = binding between a request for an authenticator (which includes TLS = extensions) and the authenticator itself. This change also significantly = simplifies the HTTP/2 Additional Certificates draft that depends on = exported authenticators. I presented this change at IETF 100 and there = were no objections. >=20 > Comments welcome, > Nick >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Dec 8 10:50: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 F2A0C127522 for ; Fri, 8 Dec 2017 10:50:00 -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 83GIA2zzl6S5 for ; Fri, 8 Dec 2017 10:49:59 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 46A4F124D37 for ; Fri, 8 Dec 2017 10:49:59 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id t24so8095418uaa.13 for ; Fri, 08 Dec 2017 10:49:59 -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=OCYy7MHCeSf7H1P3O1nI2HlTzKv8Ov2iPo7X4i9K0ro=; b=KW/gr3BTFY0IP8SFSW5UcHFta9zRIm0v3/C+9iAqIRPcsWudBib90SLJvJcYe4E9hH U6LcCa6kh81bQWH2dvzWnSiZ0fPEM8ag6Kq/WIUDWatmjzmIXLDUixlsl82o+le6W3KY r/IxxM+s+dx2/b29gIPeSZyjLRFFXy4NRBDrw/Z9t2pSujdskYxZ12AO22/fAp4UoNeC O3RXBbbApTDRLbC2Vbxna2lO2By9kQ6KRCCLZgMa7a+hZgRvwWDxvnMjdS2qxAPJCiFf iigcRnIJky8yHKSZmba9eMWvOfLFu13Pf86qjcMSnodBlxC28TIQXtVQBtL1atzPXzRW q1kA== 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=OCYy7MHCeSf7H1P3O1nI2HlTzKv8Ov2iPo7X4i9K0ro=; b=g9qC71QesnjomITVqqrL4vg59GkBbofTbIuCFY12HObDuw1q/qWhwEehkJFsUM/ahW NKuxq2WO5qhwwXduo/3Kb6D8jesOqx+jUxZCmwqK2Wvv9IU+csotkBRNqxWV1aLZqBXJ j8cuO18TJZ0/Lt6XtLcWk3nOM9dYftFRj6Jsynbe6k6iFDyQ5E5jl89ApXSTZzRIh1mb LiA7LeIsIjV9N4dYZI3x5iSrRK8VCSK+hOVHee39UdDEeW7yZ3aC8p2elNkdw7F7qnjc Fgp/spsW5lqMo0MZNqYnqK2q6Rx2CWi5sl66ai17dukONcfzt9yQ+I8kEMDech0OnItZ +lIg== X-Gm-Message-State: AKGB3mKFnVPXkcbCyNeH3i0IniyHdkDnTt+g95u0lJ3+lHe93aCWtU2J THGSEGjp4D9D3Z+5FGd1u1ozmoWQOGJ0Jz5kJG3e8Q== X-Google-Smtp-Source: AGs4zMa2fzqLQt2NSCIWffYlRKOfw1yd24ool9umqPakSboso0F0uoEb6HoDuqadqa7wzUrd2zBcL3lEDoBzhC7evBo= X-Received: by 10.176.67.228 with SMTP id l91mr19525937ual.181.1512758998098; Fri, 08 Dec 2017 10:49:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.20.230 with HTTP; Fri, 8 Dec 2017 10:49:17 -0800 (PST) From: Joseph Birr-Pixton Date: Fri, 8 Dec 2017 18:49:17 +0000 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Two draft-22 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2017 18:50:01 -0000 Hello, Draft 22 says: An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time during the handshake and MUST simply drop it without further processing. That requirement is hard to meet in a library that implements both TLS1.2 and TLS1.3 -- a CCS prior to ServerHello would have to be both fatally rejected (TLS1.2) and dropped without further processing (TLS1.3). Are there any problems with tightening up "at any time during the handshake"? Or perhaps I should be interpreting the time prior to ServerHello as not being "during the handshake"? -- There's inconsistency in whether the supported_versions extension is allowed in HelloRetryRequest. 4.2.1 and B.3.1.1 say no, but 4.1.4, 4.2 and 9.2 say yes. I'll assume that's an omission and submit a PR. Cheers, Joe From nobody Fri Dec 8 11:14: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 097EA12773A for ; Fri, 8 Dec 2017 11:14:40 -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 6AfBU59trNqU for ; Fri, 8 Dec 2017 11:14:37 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752031275F4 for ; Fri, 8 Dec 2017 11:14:37 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id g191so4619465ywe.7 for ; Fri, 08 Dec 2017 11:14:37 -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=ImnaodKyAqtsbtoslleS9FIfS9+E8MIb2SloW6u+JUc=; b=lEGtvohfcPYPyDrvaVH8GVg+wDnxNs+v6CaXzzRytUBKQDUbVpeuyl73Gl8HN3gVel H0qtJQMMyWlmesm9zHy4Vn3MPow+QyKw6LrEPZBP0YlxvdZJHtUbpdBk3PZPDXmagF34 I6s0bOo6ga3S9PfNMJtCKqdnlbO7g8y+woI6d56+j/5YyV5TyFFg4oVNVd0wrbuLWGGZ YIlUkibWKygKIhkA3t9vJjpaePuqgQqV8QDeVIv8MwaBmLaic9SDafhZlAyfRem35sMx aiJCVxNObXzoFGQm7fMF/MekuWswl8HMI7reQGeHKNaf5LZv/J4iHeivmmoE08xuen6Y B3XQ== 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=ImnaodKyAqtsbtoslleS9FIfS9+E8MIb2SloW6u+JUc=; b=aVR7JrA9pvsVbDG2vTuYtmy7LHsoe3TH/ykv7A99De265SeLJh/vmRRMVBy+NXdr3l jGMgmTwIGs5DJnqqwk4g97QOrI5fIXHQKE70sLEYtPe2dykdXFfsluzzUQ++oyu+YRXa xGD9LcOlLFKz7rw0xPDuB52aWC8E3x12HIPDweKYmGQU2maihHiqv5yQRLMaGutBvTZo y6aSxBg3a679ypfg3J14Fq4fdF/5Y2tS3eZSWpisNVywYzZrmYDYvTkMVQnSCZpboHWu 9owDG2y+2204lHGF4MouzhyziF9NrkfVWct04oYCOqpTHODUm6VN/APGsb7rsEh4gnSS fimA== X-Gm-Message-State: AJaThX4u6PWOQ1Gg1FVAMCfx7FMXa/5D+5YlcAMrI+NZwmTN5Jo2SnfD 6essJ5jFrwPotoMFdd14ylJS7hunaJm+UTzoJtCzGA== X-Google-Smtp-Source: AGs4zMbyAJ0Z3opnK8Zso3CJGV6PSMB/11FHbUq8Lv/3+ltUq5l8rr8YMFrNFtF3VaEPCeDfjCvYHkAR7Qa8NUhFBXU= X-Received: by 10.129.48.202 with SMTP id w193mr22436969yww.378.1512760476673; Fri, 08 Dec 2017 11:14:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 8 Dec 2017 11:13:56 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 8 Dec 2017 11:13:56 -0800 Message-ID: To: Joseph Birr-Pixton Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11409cfad7c198055fd8fe85" Archived-At: Subject: Re: [TLS] Two draft-22 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2017 19:14:40 -0000 --001a11409cfad7c198055fd8fe85 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 8, 2017 at 10:49 AM, Joseph Birr-Pixton wrote: > Hello, > > Draft 22 says: > > An implementation may receive an unencrypted record of type > change_cipher_spec consisting of the single byte value 0x01 at any > time during the handshake and MUST simply drop it without further > processing. > > That requirement is hard to meet in a library that implements both > TLS1.2 and TLS1.3 -- a CCS prior to ServerHello would have to be both > fatally rejected (TLS1.2) and dropped without further processing > (TLS1.3). > Well, you could read this as overriding the 1.2 requirement, namely, that if you offer 1.3, you must reject it. > Are there any problems with tightening up "at any time during the > handshake"? Or perhaps I should be interpreting the time prior to > ServerHello as not being "during the handshake"? > I think if we think this is the right answer we should say so, and I would be fine with that. There's inconsistency in whether the supported_versions extension is > allowed in HelloRetryRequest. 4.2.1 and B.3.1.1 say no, but 4.1.4, > 4.2 and 9.2 say yes. I'll assume that's an omission and submit a PR. > Correct. Please do. -Ekr > > Cheers, > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11409cfad7c198055fd8fe85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 8, 2017 at 10:49 AM, Joseph Birr-Pixton &= lt;jpixton@gmail.com= > wrote:
Hello,

Draft 22 says:

=C2=A0 An implementation may receive an unencrypted record of type
=C2=A0 change_cipher_spec consisting of the single byte value 0x01 at any =C2=A0 time during the handshake and MUST simply drop it without further =C2=A0 processing.

That requirement is hard to meet in a library that implements both
TLS1.2 and TLS1.3 -- a CCS prior to ServerHello would have to be both
fatally rejected (TLS1.2) and dropped without further processing
(TLS1.3).

Well, you could read this as = overriding the 1.2 requirement, namely, that if
you offer 1.3, yo= u must reject it.=C2=A0


Are there any problems with tightening up "at any time during the
handshake"? Or perhaps I should be interpreting the time prior to
ServerHello as not being "during the handshake"?
=

I think if we think this is the right answer we should = say so, and I would be
fine with that.

<= br>
There's inconsistency in whether the supported_versions extension is allowed in HelloRetryRequest.=C2=A0 4.2.1 and B.3.1.1 say no, but 4.1.4, 4.2 and 9.2 say yes. I'll assume that's an omission and submit a PR= .

Correct. Please do.

-Ekr
=C2=A0

Cheers,
Joe

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

--001a11409cfad7c198055fd8fe85-- From nobody Fri Dec 8 11:34: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 6183612751F for ; Fri, 8 Dec 2017 11:34:31 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMwfthGOcbUe for ; Fri, 8 Dec 2017 11:34:29 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86836124F57 for ; Fri, 8 Dec 2017 11:34:29 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB8JVrjI009698; Fri, 8 Dec 2017 19:34:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=CrwWBB1hzPo3b324aSPQAXGWvDeWO6VJ89PwDFZWDrc=; b=PFyUwRyvoVjMquT01cVsFJQQUPk8n0Mk4x0ndSy/5wUGWmg1ziy53Sd5TRCw5rsu1eVk fySIGMce8hCDYvw6zVTslM9r5bVCJXwteFoq3zki3QlAZBzsxUXGin772DlFpm7Iuoqh NDT35YOUP6yhju7BncdyWZSRP/h55gdmvIlg8GafWDpOq/mzqk2EZfteUcNOHKaxOEea ILL4HoHuu5uOIHgJmX/T8OaVZvRJVjc3US+k1RnGqHGu8BCS3w2KWgN7BW9vzvE09AfH 8Z5OhXJmlovsuz44nGs//0hj8k0vfu5aUHnRDfvzTn9u4IgLgaxUye1bElL4TMSvju+3 Aw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2eqn6nhnx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 19:34:27 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vB8JUpP1011838; Fri, 8 Dec 2017 14:34:26 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2eqg71u8x2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 14:34:26 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Dec 2017 14:34:25 -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.1263.000; Fri, 8 Dec 2017 14:34:25 -0500 From: "Salz, Rich" To: Joseph Birr-Pixton , "tls@ietf.org" Thread-Topic: [TLS] Two draft-22 comments Thread-Index: AQHTcFVezwgv3MNFF0yaTSfpZz6xoKM6KhQA Date: Fri, 8 Dec 2017 19:34:24 +0000 Message-ID: <89D6911C-C81D-41D8-803D-BE05EB0FD249@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.169] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=855 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080264 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=788 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080265 Archived-At: Subject: Re: [TLS] Two draft-22 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2017 19:34:31 -0000 4p6iIFRoYXQgcmVxdWlyZW1lbnQgaXMgaGFyZCB0byBtZWV0IGluIGEgbGlicmFyeSB0aGF0IGlt cGxlbWVudHMgYm90aA0KICAgIFRMUzEuMiBhbmQgVExTMS4zIC0tIGEgQ0NTIHByaW9yIHRvIFNl cnZlckhlbGxvIHdvdWxkIGhhdmUgdG8gYmUgYm90aA0KICAgIGZhdGFsbHkgcmVqZWN0ZWQgKFRM UzEuMikgYW5kIGRyb3BwZWQgd2l0aG91dCBmdXJ0aGVyIHByb2Nlc3NpbmcNCiAgICAoVExTMS4z KS4NCiAgICANCldlbGwgT3BlblNTTCBtYW5hZ2VkIHRvIGRvIGl0LiAgSSBndWVzcyBJIHNob3Vs ZCBhZG1pdCB0aGF0IGl0IGNvdWxkIGJlIGludGVycHJldGVkIGFzIGFyZ3VpbmcgaW4gZmF2b3Ig b2YgeW91ciBwb2ludCA6KSAgTGVzcyBmbGlwcGFudGx5LCBpdOKAmXMgcHJldHR5IHN0cmFpZ2h0 Zm9yd2FyZDogd2hlbiB5b3UgZ2V0IGEgQ0NTIGxvb2sgYXQgdGhlIHN0YXRlIGFuZCBmYWlsIG9y IGlnbm9yZS4NCg0K From nobody Sat Dec 9 04:21:42 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 9746312711B; Sat, 9 Dec 2017 04:21:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151282209956.24790.5482932813219061171@ietfa.amsl.com> Date: Sat, 09 Dec 2017 04:21:39 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 12:21:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Transport Layer Security (TLS) Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-01.txt Pages : 7 Date : 2017-12-09 Abstract: In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-01 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 Sat Dec 9 04:30:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE6128B90 for ; Sat, 9 Dec 2017 04:30: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, 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=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQMsV65g9Smc for ; Sat, 9 Dec 2017 04:30:27 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F94126D0C for ; Sat, 9 Dec 2017 04:30:27 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:8010:6241:0:14d2:9c89:db12:b159]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 398ECDF5B3 for ; Sat, 9 Dec 2017 12:30:25 +0000 (UTC) Date: Sat, 9 Dec 2017 12:30:23 +0000 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20171209123023.GA8296@pinky> Mail-Followup-To: tls@ietf.org References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151282209956.24790.5482932813219061171@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1512822625; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; bh=oU2FyUMVj2fRn9HO5jctSFoN9AM9ADI5wxmWJ7BLMjc=; b=RF7K6BdQithcvGlenaTeuGfjoDe5R8WEDxTeI8nWIIsN8nEfV8jqzr6RUctHilvTrVhvjU 0SMBiaZ19MNYtYs2vfofDod4rhMed/HbtL5UEXzpNz3Gpacebk/7MNHeL2VfFmMWAsMNr8 bq79hGxNVMq9FFoGfokeNkvUc8vnIEU= Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 12:30:30 -0000 Hello, Sorry for the long delay from the last update. On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Transport Layer Security (TLS) Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-01.txt > Pages : 7 > Date : 2017-12-09 > > Abstract: > In Transport Layer Security (TLS) handshakes, certificate chains > often take up the majority of the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. Here are the changes in this update, based on previous discussions: * Defined a new CompressedCertificate message instead of re-defining the contents of Certificate. Applications can decide to send a compressed certificate using this new message, or keep sending the normal uncompressed Certificate. This has a number of small advantages like making it possible for applications like WireShark to not have to maintain per-connection state when decoding compressed certificates since they could just look at the handshake message type instead of having to remember if compression was negotiated. But most importantly, this makes it possible for applications to decide whether to compress certificates on a case-by-case basis, even if they already negotiated support for it (see next point). * Added support for client certificates. Both server and client-side support is negotiated using the same "compress_certificates" extension, but given the previous change, client and server can negotiate compression and only decide to receive compressed certificates rather than send them (i.e. a client or server is only required to implement decompression). * Added a compatibility note regarding Certificate-intercepting middleboxes, explaining that replacing the Certificate message in TLS < 1.3 might cause connections to break. The only remaining issue is defining compression dictionaries [0]. However, attempts at defining one that is not biased (as per previous discussion on the subject [1]) haven't led to anything concrete (i.e. no substantial compression ratio increase). Both me and Victor don't think this is a blocking issue though, since dictionaries can be added later on by simply defining new compression type codepoints. Also, we think the wire format is pretty stable now, so we are wondering whether this would be a good time to start the process for early codepoint assignment (for the extension and handshake message type), so we can start looking at deploying this. Cheers [0] https://github.com/tlswg/certificate-compression/issues/1 [1] https://www.ietf.org/mail-archive/web/tls/current/msg22537.html From nobody Sat Dec 9 04:43: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 021A9128BA2 for ; Sat, 9 Dec 2017 04:43:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 lrgTNpoHG13r for ; Sat, 9 Dec 2017 04:43:41 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0149126D0C for ; Sat, 9 Dec 2017 04:43:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 26EC097A23 for ; Sat, 9 Dec 2017 14:43:39 +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 Gp4GVV1gq6cv for ; Sat, 9 Dec 2017 14:43:38 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A514D72 for ; Sat, 9 Dec 2017 14:43:37 +0200 (EET) Date: Sat, 9 Dec 2017 14:43:37 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20171209124337.GA7162@LK-Perkele-VII> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171209123023.GA8296@pinky> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 12:43:44 -0000 On Sat, Dec 09, 2017 at 12:30:23PM +0000, Alessandro Ghedini wrote: > Hello, > > Sorry for the long delay from the last update. > > On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Transport Layer Security (TLS) Certificate Compression > > Authors : Alessandro Ghedini > > Victor Vasiliev > > Filename : draft-ietf-tls-certificate-compression-01.txt > > Pages : 7 > > Date : 2017-12-09 > > > > Abstract: > > In Transport Layer Security (TLS) handshakes, certificate chains > > often take up the majority of the bytes transmitted. > > > > This document describes how certificate chains can be compressed to > > reduce the amount of data transmitted and avoid some round trips. > > Here are the changes in this update, based on previous discussions: > > * Defined a new CompressedCertificate message instead of re-defining the > contents of Certificate. Applications can decide to send a compressed > certificate using this new message, or keep sending the normal uncompressed > Certificate. The section 3 on extension still seems to be written like Certificate message was still used. > * Added support for client certificates. Both server and client-side support is > negotiated using the same "compress_certificates" extension, but given the > previous change, client and server can negotiate compression and only decide > to receive compressed certificates rather than send them (i.e. a client or > server is only required to implement decompression). Where is the client certificate compression algorithm signaled? -Ilari From nobody Sun Dec 10 10:19: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 E5F69128B93 for ; Sun, 10 Dec 2017 10:18:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 h2QDDkfZzwEm for ; Sun, 10 Dec 2017 10:18:58 -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 46E0A124D68 for ; Sun, 10 Dec 2017 10:18:58 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id r39so32782382qtr.13 for ; Sun, 10 Dec 2017 10:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=JgW/609uy92CHQ1HOM7Zbnm1eILHgO2mdpBXmboypMs=; b=aPyrq5Ih73XSEhXeWHKValz/5HlxyVd2Re2irCqrlXN5jzeuCSYywf15Jb/2GHoufm dK31NAnX837g1Xzt4kA8MVbq82lmSYhVBYiUFwSiTzdAseRx/upNmZFK4StsyZR0T7fT BIw3lzMucbBy5C7afGRqlylIeUInju0xYQTi4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=JgW/609uy92CHQ1HOM7Zbnm1eILHgO2mdpBXmboypMs=; b=qM8pvZQnV/CsJIO2BtmqrvbdGpnT7iN5NMj8XSSYIx/IRgHBbPBb01oE7UXKfdmO7Y uRJgKiWJY6Ke05jAhVpFDP3ATC713gax5csH0DpJEREXb8JVDhTka048EahrmaAslsR9 sPIl1AwM/GPJ7ZqDMkzXEp93KpA+idP9lG4fe5AYZoIx7o5+I+BcAEWHE0MffSdFHqbk v3pMNhjqRfHiBNQH0XoN0c1jufwUNl4NFNBxUYEQJZHCd4/98SjTFhKQNjnqZhQoVXTv 6ZZ5QgQcDRp44a3iq8bjkm4VFXh62CIgViP8q4UBOc11+A5yj3uHaae9M3/cL9acT4gt ebCg== X-Gm-Message-State: AKGB3mL0f+Idzb7ZXnosC0mBdVtIqRqx+8vqu8noDS3A7e1cMYpFzB7k pXaFpw+ae/GZw1CzVij9mJztWqw94LI= X-Google-Smtp-Source: AGs4zMY+RcEt/E0nwb5tmm114tJwLD+UYL+F/7i25FBRODiikaX4Q6LC9Eq/XuU/Bu9RcGOflFW3zw== X-Received: by 10.200.54.93 with SMTP id n29mr25217932qtb.179.1512929937283; Sun, 10 Dec 2017 10:18:57 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id r55sm3302445qta.57.2017.12.10.10.18.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 10:18:56 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <34DE1644-4197-4171-A12E-44260BBEAF74@sn3rd.com> Date: Sun, 10 Dec 2017 13:18:55 -0500 To: "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [TLS] Proposed AUTH48 change to draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 18:19:00 -0000 A while back Martin Rex noted an editorial error in = draft-ietf-tls-rfc4492bis, which is patiently waiting in the RFC = editor=E2=80=99s queue. He noted: The last of the "must implement 1 of these 4" list of cipher suites = at the end of section 6 is not contained in the table at the beginning = of section 6 above it (instead, it appears in rfc5289 only). To address this error it has been proposed that the following change be = made to the list at the end of s6: - o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 + o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA Please let us know by December 18th whether you object to this change = (and why). Cheers, spt= From nobody Sun Dec 10 10:58: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 14E6D1276AF for ; Sun, 10 Dec 2017 10:58:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KSgVeaLjqeHW for ; Sun, 10 Dec 2017 10:57:58 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 407A61200FC for ; Sun, 10 Dec 2017 10:57:58 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id m59so32952730qte.11 for ; Sun, 10 Dec 2017 10:57:58 -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=2wdn8W15UTiFmAy6B3qaC8pYp23Bpn9MYYm6OcA6jGU=; b=nBWKvCmpdizo2VFzc4piLZxqhWXLdDKgkR1aWMeqDznvs8IhsoZhvvqlp3aAphQw8G 5Tzy59PLqE+dXbxvYQxbwCHBCj8/fWqA652i5iIF+zOtEfcqA6Mixs5M6Myestk/OgQe h0r0D5gbkxUZbuw4cTl8T+61k6LiHg4O+YVM0= 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=2wdn8W15UTiFmAy6B3qaC8pYp23Bpn9MYYm6OcA6jGU=; b=eMDYZpm8vOQ0UyqXZ4nqDpjvaQsHScuFs+xZMGcHx+ry1JIhIzh506BKKMhS7/v9Eq BYigqSwFSSiKsSnpbFM4KQaN431TXBksrWFFwaPym094YqDvPAKuWHPfWCO1/UejFGgz J8wUTXBYWLteq30R7S1oA7FULmZsPLQ5wqhEectDlq3PbmO8aXd0xTd/2jKv4CXxws9+ hfZqORo+y/h1oystwTZeU0lO9cHENChgIXOg44UBVduTFChMBB4JHKaEGmDEYUBSHRGL fyyrUjvdi0+V1dAO/djiLbeASv8DdkQLvNPIQ0mD8uYsL/2ZpZVVMjnxQx9GK0y63QpO +BqA== X-Gm-Message-State: AKGB3mLnxYbHBUniSSzPEjKhI01LUkk/q4Oy7/Qi3Rtoe12hLKsfMLEx O2//rNgkPzmyAW5lkk7ctrZwYRgcZ1Y= X-Google-Smtp-Source: AGs4zMa9d+jPkNSArdv7pC+g0ihU6Q2X9k6VhDbb1eZW93JezUCapLds3Ivr/fleB9WntxVXlERWgw== X-Received: by 10.55.89.68 with SMTP id n65mr43377390qkb.187.1512932277207; Sun, 10 Dec 2017 10:57:57 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id r33sm3123024qte.36.2017.12.10.10.57.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 10:57:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <20171209124337.GA7162@LK-Perkele-VII> Date: Sun, 10 Dec 2017 13:57:54 -0500 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8DACA4DB-7083-4355-BB43-AF65A4414C71@sn3rd.com> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171209124337.GA7162@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 18:58:00 -0000 > On Dec 9, 2017, at 07:43, Ilari Liusvaara = wrote: >=20 > On Sat, Dec 09, 2017 at 12:30:23PM +0000, Alessandro Ghedini wrote: >> Hello, >>=20 >> Sorry for the long delay from the last update. >>=20 >> On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-drafts@ietf.org = wrote: >>>=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 WG of the = IETF. >>>=20 >>> Title : Transport Layer Security (TLS) Certificate = Compression >>> Authors : Alessandro Ghedini >>> Victor Vasiliev >>> Filename : draft-ietf-tls-certificate-compression-01.txt >>> Pages : 7 >>> Date : 2017-12-09 >>>=20 >>> Abstract: >>> In Transport Layer Security (TLS) handshakes, certificate chains >>> often take up the majority of the bytes transmitted. >>>=20 >>> This document describes how certificate chains can be compressed = to >>> reduce the amount of data transmitted and avoid some round trips. >>=20 >> Here are the changes in this update, based on previous discussions: >>=20 >> * Defined a new CompressedCertificate message instead of re-defining = the >> contents of Certificate. Applications can decide to send a = compressed >> certificate using this new message, or keep sending the normal = uncompressed >> Certificate. >=20 > The section 3 on extension still seems to be written like Certificate > message was still used. Are you suggesting a subtle wording change because once =E2=80=9Cnegotiate= d=E2=80=9D compression isn=E2=80=99t always used? I.e.,=20 OLD: =E2=80=A6 which is used by the client and the server to negotiate the use of compression for their certificate chains, as well as the choice of the compression algorithm. ... NEW: .. which is used by the client and the server to negotiate the *possible* use of compression for their = certificate chains, as well as the choice of the compression algorithm. ... >> * Added support for client certificates. Both server and client-side = support is >> negotiated using the same "compress_certificates" extension, but = given the >> previous change, client and server can negotiate compression and = only decide >> to receive compressed certificates rather than send them (i.e. a = client or >> server is only required to implement decompression). >=20 > Where is the client certificate compression algorithm signaled? Correct me if I=E2=80=99m wrong, but I think the assumption here is that = if the client offers both zlib and brotli and the server returns brotli = that the client (if it does choose to compress) will use the same = algorithm the server chose. spt= From nobody Sun Dec 10 15:00: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 B53CC126D3F for ; Sun, 10 Dec 2017 14:59:59 -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 XIh9DW7yB_u9 for ; Sun, 10 Dec 2017 14:59:57 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003: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 B284D1242EA for ; Sun, 10 Dec 2017 14:59:57 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id 184so10485440oii.2 for ; Sun, 10 Dec 2017 14:59:57 -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; bh=k1RgN2DdRW4nmawXphVIjYpS2yRPNIjN4IJWhbrPOSQ=; b=QtuMkmJor1YWxk702/oRHAXkt0IKQ0jFZ9iWJ/R619WQCyvVyI3Q2gQeXIXm52z8rE koCUEwLRcmpNP68+pAXcebxWTD2l2qjjNZKOpU0GxD/KQUwuEjmQZo+uwELPMos/nPZv 4M36Kq8jAp2/z1eRfvPuWS2a7gw0UwnX2BJbfaGieJNEWmcng4NVFviDGr0GQsWkIOak TU7RMAb4wENYLfZjquy/e1PgQdo5mD02DgjcnhNpxNTguGFkOvQgek4rrTfAMDGuDTMU FAUXn2cP7Zxh6Eu4S+P9RIAYjzWDVkdE78FvOu9HtJ9szTz/0mqYd1pr7KyTU9Dx+Of8 Ycbw== 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=k1RgN2DdRW4nmawXphVIjYpS2yRPNIjN4IJWhbrPOSQ=; b=YUmmvNa4rIsOdN+7FJe/Vmg9+xv/X3zsBer/PxqkabAe3MyEuKJB00x+rpBe1edIew /mIUDy1V2PrXJskQK/5oj4VGql51YjYW8jSY6Gg3ULw/A/FlSyAiBfyVuPuVCDJYGVJY hHE2FRStYb0Q3wrPSSz7RdjFhqGadx1FaaBp9E8y44q9/vB/jhEpQO5HDK3cC4TVyku7 vD5EtNgN/9ZSESw1PyjlbrfZse8On+1T6w0R3H/9sybXi+MBBRjNOTDmSdbr5CzJ6l7h KnF4TFvH9tH1wsyiODruZOnnQoUKIvew1fo7DRL4aEubawMG9TqGIcZT5esSnKGHYhAQ 5afg== X-Gm-Message-State: AJaThX4E575iaJXq7Y7rDONd1rll0iycoyyHWcV0WibafyUIbRQ4xpPb ZM/hKLSFiEI+Hrgx98wVeInigNh7NLxqTKNQtsSRGE3G X-Google-Smtp-Source: AGs4zMYMq5NMLHrGPn66rP4QGPukjkQmXIT/pERTro7cTBGt4MSXlAUsiw1uA76VC94uNQbkf+jQXS2UjF1NPOv1qGc= X-Received: by 10.202.10.68 with SMTP id 65mr30483458oik.84.1512946796706; Sun, 10 Dec 2017 14:59:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 10 Dec 2017 14:59:56 -0800 (PST) In-Reply-To: <20171209123023.GA8296@pinky> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> From: Martin Thomson Date: Mon, 11 Dec 2017 09:59:56 +1100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 22:59:59 -0000 A codepoint might be premature just yet. The idea of using a new handshake message type is to allow someone to choose between compressing and not. But consider the case where both client and server support non-intersecting sets. This negotiation would cause failure, but that would be unnecessary. You could allow the server to advertise multiple (as the current format allows), but in that case, when the server certificate arrives and is compressed, the client can't know which compression method was used without trialing each. Similarly, when the client certificate arrives, the server can't know which compression method was used either. I think that the best solution to that problem is to include the compression scheme in the Certificate message. It also suggests (to me at least) that modifying Certificate rather than defining a CompressedCertificate makes sense, though that might not fit with the idea that you transform CompressedCertificate into Certificate before putting it in the transcript. Or, you could trim the list on the server side to a single value, but then you have to deal with TLS 1.3 CertificateRequest more explicitly, which is currently not at all addressed. In that spirit, I would also suggest that you describe what happens to a TLS 1.3 Certificate message that contains extensions (the entire thing is wrapped up as a whole, I assume). In light of the changes, this seems like a bug: If the server chooses to use the cached_info extension [RFC7924] to replace the Certificate message with a hash, it MUST NOT send the compress_certificates extension. The server could send the extension to allow the client to compress even if it had a cached certificate. On Sat, Dec 9, 2017 at 11:30 PM, Alessandro Ghedini wrote: > Hello, > > Sorry for the long delay from the last update. > > On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Transport Layer Security WG of the IETF. >> >> Title : Transport Layer Security (TLS) Certificate Compression >> Authors : Alessandro Ghedini >> Victor Vasiliev >> Filename : draft-ietf-tls-certificate-compression-01.txt >> Pages : 7 >> Date : 2017-12-09 >> >> Abstract: >> In Transport Layer Security (TLS) handshakes, certificate chains >> often take up the majority of the bytes transmitted. >> >> This document describes how certificate chains can be compressed to >> reduce the amount of data transmitted and avoid some round trips. > > Here are the changes in this update, based on previous discussions: > > * Defined a new CompressedCertificate message instead of re-defining the > contents of Certificate. Applications can decide to send a compressed > certificate using this new message, or keep sending the normal uncompressed > Certificate. > > This has a number of small advantages like making it possible for > applications like WireShark to not have to maintain per-connection state > when decoding compressed certificates since they could just look at the > handshake message type instead of having to remember if compression was > negotiated. > > But most importantly, this makes it possible for applications to decide > whether to compress certificates on a case-by-case basis, even if they > already negotiated support for it (see next point). > > * Added support for client certificates. Both server and client-side support is > negotiated using the same "compress_certificates" extension, but given the > previous change, client and server can negotiate compression and only decide > to receive compressed certificates rather than send them (i.e. a client or > server is only required to implement decompression). > > * Added a compatibility note regarding Certificate-intercepting middleboxes, > explaining that replacing the Certificate message in TLS < 1.3 might cause > connections to break. > > The only remaining issue is defining compression dictionaries [0]. However, > attempts at defining one that is not biased (as per previous discussion on the > subject [1]) haven't led to anything concrete (i.e. no substantial compression > ratio increase). Both me and Victor don't think this is a blocking issue > though, since dictionaries can be added later on by simply defining new > compression type codepoints. > > Also, we think the wire format is pretty stable now, so we are wondering > whether this would be a good time to start the process for early codepoint > assignment (for the extension and handshake message type), so we can start > looking at deploying this. > > Cheers > > [0] https://github.com/tlswg/certificate-compression/issues/1 > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22537.html > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Dec 10 22:09: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 9958F12702E for ; Sun, 10 Dec 2017 22:09:42 -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] 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 5sKxJ5cOtc0G for ; Sun, 10 Dec 2017 22:09:40 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797DF1241FC for ; Sun, 10 Dec 2017 22:09:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E8956B51E5; Mon, 11 Dec 2017 08:09:37 +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 a2-PThQ4oqZM; Mon, 11 Dec 2017 08:09:37 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 892D072; Mon, 11 Dec 2017 08:09:35 +0200 (EET) Date: Mon, 11 Dec 2017 08:09:35 +0200 From: Ilari Liusvaara To: Martin Thomson Cc: "tls@ietf.org" Message-ID: <20171211060935.GA4599@LK-Perkele-VII> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 06:09:42 -0000 On Mon, Dec 11, 2017 at 09:59:56AM +1100, Martin Thomson wrote: > A codepoint might be premature just yet. > > The idea of using a new handshake message type is to allow someone to > choose between compressing and not. But consider the case where both > client and server support non-intersecting sets. This negotiation > would cause failure, but that would be unnecessary. New handshake message type is pretty much necressary if one wants to also compress client certificates. Client does not have answer block outside certificate message, and trying to use that would lead into chicken and egg problem. And on supporting algorithms, the main problem is decompressing. There are very simple trivial "compression" algorithms for both Zlib and Brotli. And then there are pre-canned responses. > You could allow the server to advertise multiple (as the current > format allows), but in that case, when the server certificate arrives > and is compressed, the client can't know which compression method was > used without trialing each. Similarly, when the client certificate > arrives, the server can't know which compression method was used > either. Guessing here seems extremely bad idea. In general, in security protocols, you never want to guess what the other end intended. Trying to guess meaning is recipe for security problems. > I think that the best solution to that problem is to include the > compression scheme in the Certificate message. It also suggests (to > me at least) that modifying Certificate rather than defining a > CompressedCertificate makes sense, though that might not fit with the > idea that you transform CompressedCertificate into Certificate before > putting it in the transcript. Transforming messages before putting them in transcript? That sounds like recipe for some very nasty implementation headaches. AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject synthetic message, but that is a lot easier than actual message transformation. > Or, you could trim the list on the server side to a single value, but > then you have to deal with TLS 1.3 CertificateRequest more explicitly, > which is currently not at all addressed. In that spirit, I would also > suggest that you describe what happens to a TLS 1.3 Certificate > message that contains extensions (the entire thing is wrapped up as a > whole, I assume). Yes, that is what I get from the document. -Ilari From nobody Sun Dec 10 23:59: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 36199127843 for ; Sun, 10 Dec 2017 23:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11EH_5GtHgG0 for ; Sun, 10 Dec 2017 23:59:47 -0800 (PST) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436E4126BF0 for ; Sun, 10 Dec 2017 23:59:47 -0800 (PST) Received: by mail-wm0-f45.google.com with SMTP id b199so8870992wme.1 for ; Sun, 10 Dec 2017 23:59:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=MCgcMZwsBko36SE4eEbgSlmIrGX12dMVWLwS38yRUUs=; b=h+L9RVndD/2QC5TAblRuOYCcKO5bwWVF+sU3dDT3bezelAwDGYe2tx2Rr0gJnJCpWx 8wICvRWCE1GRQ3mEHypcK41IGkV2I0txaCTiLNp6TLRFlELNKKCj5aj0FT8nBhtTHlUl AjOacLQipYrw7sEYTdYAmyRjUCH8UulvFa2Z++YQcC8/aSvkC8rjtQHahz9xxLu2c+N0 vo71WKu1r6G/PcNonUlYMiiwPu2D4PpS0F4opyJR2TALBoZWWx45QpNZzfy6OEjkEYuC +Gu3UEIhaBz0TzK15uFRug86IJu0gD8YXvt57VW0zkmeanYAlduFtrkbjV9ixqE3E0e2 0M+A== X-Gm-Message-State: AKGB3mL6Z1K/SUl0bqweL3n/HmaBoz/hT3+vK4mnxoDERccXMxir5JsP lXc8Ow3GtJHgpxEnit2KW+Br4BzK7mw= X-Google-Smtp-Source: AGs4zMY1qQDTQn60jwtXZROEBcQeDOl94LflRJuN9SXV5rP31Ps3aryUFbAIzxSSblWGULj5rGa+rQ== X-Received: by 10.28.138.75 with SMTP id m72mr10781403wmd.97.1512979185663; Sun, 10 Dec 2017 23:59:45 -0800 (PST) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id r14sm19250702wrb.43.2017.12.10.23.59.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 10 Dec 2017 23:59:44 -0800 (PST) Message-ID: <1512979184.3296.4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , "tls@ietf.org" Date: Mon, 11 Dec 2017 08:59:44 +0100 In-Reply-To: <1512471634.3587.127.camel@redhat.com> References: <1512471634.3587.127.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 (3.26.2-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Closing on PSS. PR#1114 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2017 07:59:49 -0000 On Tue, 2017-12-05 at 12:00 +0100, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > > Hi folks, > > > > I've put together a PR that attemps to address the PSS issue. > > > > See: > > https://github.com/tlswg/tls13-spec/pull/1114 As I guess, we cannot mandate RSA-PSS private keys and certificates for TLS1.3, I've followed up with a subsection on security considerations for re-using the RSA and RSA-PSS private keys. That includes recommendations to reduce the impact from cross-protocol attacks affecting these keys. https://github.com/tlswg/tls13-spec/pull/1123 regards, Nikos From nobody Mon Dec 11 06:50: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 49042126D46 for ; Mon, 11 Dec 2017 06:50: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 NYdF6r0raGdc for ; Mon, 11 Dec 2017 06:50:19 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730D8126B71 for ; Mon, 11 Dec 2017 06:50:19 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id t78so11726893oie.8 for ; Mon, 11 Dec 2017 06:50:19 -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=QfNvmMarP48NtRUcl6pBuWsNeOP7TqX/vzbv4+ccC2s=; b=VpDZ+kVZFn9jv7GFwn/b735Zf/kLkRtzHHY550V6u6ahtjgOBcvvks+E/PcUDiuquD 9GCgkMeY3hwbGmVzhoEVnEcfUzs8o6CLuMrf/uo698X/ZqvotNheYcY3bWuESnFJHdYk nEwXCbEg0Rp26VMqh9nQ7Zi3hygaRuuXdvRWWit7ed4gnNCcI3YmNZZAkQb69NSGNVWd jnrJdtLMR4Fpe3Sb8wZZX9NmtNZyNkCerp1/OQamve68F3TFYoO1V4ejnbD53eGQkMcN 2FZvZ75X6K6/H532Y2cT9Z7YDdtbB/hO4GtrTe4jXQR5X6p3aYaF1/JC4yR22QOAMcFg x1nQ== 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=QfNvmMarP48NtRUcl6pBuWsNeOP7TqX/vzbv4+ccC2s=; b=l1xUy3C3d73p+LtAAo3gk1jFgBCdkkjVl12+BOMBy3pW3UhFAN8AlpMWL8wRsr7gVS 4jjecmTS17ZWpBjGvCZngdfbvNyttaMKYEUX0eN8AkHbVn80R4IX+/mvkvFsXY+Xrq6p HLzxaJrVRPjCLACY8hHe/HCt5CJPYJJ9tHpsTTm+HQJplFBZFuoe+F8edFj5dV7v+4S7 0U+0xEjd6vO/6iNYZYsIOmCKxSagPZ2Gr3/8VgShTOO2/B3s238tf18bHmd3FF6xECh5 tbhcj/Q4pSMt00pyd82nKGEVUswUdJCU77VtN7ivAOaGBJvkK+7m66F3jyeNTn854Rr/ 3rkA== X-Gm-Message-State: AKGB3mJI6dnAmOXCrf2tBwWPdvJ4erUF88+uKgPBamuWdns4O/HRzcuF xQyCnTAxVA+dCNleItoVW+GOBbcA/s4pxhjYiDk= X-Google-Smtp-Source: ACJfBosIwQCOLhrtCuAr9iSs8S/ZqprWNSXHcVsrxtkXIWlXD7LOlUjGVjVjSoziFlhN7FS1JCxojlZUO3mk+PlHrNg= X-Received: by 10.202.10.68 with SMTP id 65mr545858oik.84.1513003818377; Mon, 11 Dec 2017 06:50:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 11 Dec 2017 06:50:17 -0800 (PST) In-Reply-To: <20171211060935.GA4599@LK-Perkele-VII> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171211060935.GA4599@LK-Perkele-VII> From: Martin Thomson Date: Mon, 11 Dec 2017 08:50:17 -0600 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 14:50:21 -0000 On Mon, Dec 11, 2017 at 12:09 AM, Ilari Liusvaara wrote: > Transforming messages before putting them in transcript? That sounds > like recipe for some very nasty implementation headaches. > > AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject > synthetic message, but that is a lot easier than actual message > transformation. My understanding is that this is what is proposed. FWIW, it's not that awful for us to implement in NSS. From nobody Mon Dec 11 06:51: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 C42DB126DEE for ; Mon, 11 Dec 2017 06:51:12 -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] 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 8PdBM4JUL3Cs for ; Mon, 11 Dec 2017 06:51:10 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511FF126D0C for ; Mon, 11 Dec 2017 06:51:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 6CA775DE48; Mon, 11 Dec 2017 16:51:07 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 4oCa831xLadu; Mon, 11 Dec 2017 16:51:04 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A69572317; Mon, 11 Dec 2017 16:51:01 +0200 (EET) Date: Mon, 11 Dec 2017 16:51:01 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20171211145101.GA5741@LK-Perkele-VII> References: <1512471634.3587.127.camel@redhat.com> <1512979184.3296.4.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1512979184.3296.4.camel@redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Closing on PSS. PR#1114 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2017 14:51:13 -0000 On Mon, Dec 11, 2017 at 08:59:44AM +0100, Nikos Mavrogiannopoulos wrote: > On Tue, 2017-12-05 at 12:00 +0100, Nikos Mavrogiannopoulos wrote: > > On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > > > Hi folks, > > > > > > I've put together a PR that attemps to address the PSS issue. > > > > > > See: > > > https://github.com/tlswg/tls13-spec/pull/1114 > > As I guess, we cannot mandate RSA-PSS private keys and certificates for > TLS1.3, I've followed up with a subsection on security considerations > for re-using the RSA and RSA-PSS private keys. That includes > recommendations to reduce the impact from cross-protocol attacks > affecting these keys. > > https://github.com/tlswg/tls13-spec/pull/1123 Some comments: - Shared keys between servers are fairly common. Some of those servers are very badly configured (e.g. Static RSA enabled). - If another server does not share key, but has certificate valid for the name, that certificate can be used as well. (These are the same considerations as for DROWN). -Ilari From nobody Mon Dec 11 07:00: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 75DAF126D0C for ; Mon, 11 Dec 2017 07:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_HELO_TEMPERROR=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 0tYHKb2YinKo for ; Mon, 11 Dec 2017 07:00:20 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050A7126B71 for ; Mon, 11 Dec 2017 07:00:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4252953726; Mon, 11 Dec 2017 17:00:18 +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 shEOzFjmkBpG; Mon, 11 Dec 2017 17:00:18 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D59BB27F; Mon, 11 Dec 2017 17:00:15 +0200 (EET) Date: Mon, 11 Dec 2017 17:00:15 +0200 From: Ilari Liusvaara To: Martin Thomson Cc: "tls@ietf.org" Message-ID: <20171211150015.GB5741@LK-Perkele-VII> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171211060935.GA4599@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 15:00:21 -0000 On Mon, Dec 11, 2017 at 08:50:17AM -0600, Martin Thomson wrote: > On Mon, Dec 11, 2017 at 12:09 AM, Ilari Liusvaara > wrote: > > Transforming messages before putting them in transcript? That sounds > > like recipe for some very nasty implementation headaches. > > > > AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject > > synthetic message, but that is a lot easier than actual message > > transformation. > > My understanding is that this is what is proposed. FWIW, it's not > that awful for us to implement in NSS. I searched the drafts (both -00 and -01). I find absolutely nothing to suggest this extension would play any games with the handshake hash. And considering that extension playing such games is AFAIK unprecidented, that would warrant rather big warnings. -Ilari From nobody Mon Dec 11 07:09:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663B4126D73 for ; Mon, 11 Dec 2017 07:09: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 sAYz-gTkjPFg for ; Mon, 11 Dec 2017 07:09:17 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 B6DC8126B71 for ; Mon, 11 Dec 2017 07:09:17 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id r63so11759812oia.6 for ; Mon, 11 Dec 2017 07:09:17 -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=trM76XfI4w0oD+0NxHL6LQhZ00IxXa38UVEDbTeAW24=; b=Dwk7y6eGcvULLqvb1Lyue0IyPxFpdcn4TiT0nICEEItifeiOaLmcw/KJMq90vsGxqP EVM+kyTIzcVyEpPv0a3ZG90q378vqPm7FvTjMbgpUvG2qGSWEldAHQoE7LXBGKT4zHDR sPGJT0G+y37HFtITHyIqLrAP0OwUUOoDfXxUkcItlLqm11YQJngqYu3Mm2FTxEnIW0dt aka4ckijJUnBBCmIL11rmzTqd2ICrW3qbGHeU5/ndfgS3WedhQIg6vMbKdRTU2S4Hxid Z5NjvXfK1JIfO5JKQG6lz8tlc6cz1aH/OiPcWYRMCFBCKX+jqmD899pzWZU4/GyvlpSk qWsQ== 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=trM76XfI4w0oD+0NxHL6LQhZ00IxXa38UVEDbTeAW24=; b=Shn1hSeVdxO+76i1SamL89eXn9ItbGKotMibWKRlFbmqSRrL+c9lLoZny71/xPdajY w++MyTcqIdfw/0bFaMCvUnr5aMQUKssLcKwIxGHEsE6KVwbX4ZgLIMtUKCNacQvX0hVM yhI95oNlSC/RP/Rb0EZi0VIYCO6LWogXJgaqPfSMdN1xO3KjdG0lEXj85RKvbx9n6W5g Jva3h5a9d1/p1GDajgskOgUBk0KPIaSxiaJU1PTfA8aE4jl9LMCNEAo7eTbbjLTSxs2y d7QoumWXEqsVyTXIMBW/Ybv43xOGtj3sOBwTgrzk+oe1W3jbQ3WIZkJnDPucihwTGBcj 1O7w== X-Gm-Message-State: AKGB3mJrAmGlSgP+ni58xsnQdQicQ3Ira9F63ZCakAwAzzw66uhJb2Yi fujg4NKsIlU5SCHSQcSOgmb+V7iZxDJxvTZdF0AN6SRE X-Google-Smtp-Source: ACJfBotq5n3BP8VKcxAWbCn95OorlzMTbzaQ4V9qhaaP2FT7fAsNNGImDcmAhrB2mQx4naP1YNC5eW6wKawUveDrbH0= X-Received: by 10.202.170.143 with SMTP id t137mr582709oie.313.1513004956927; Mon, 11 Dec 2017 07:09:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 11 Dec 2017 07:09:16 -0800 (PST) In-Reply-To: <20171211150015.GB5741@LK-Perkele-VII> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171211060935.GA4599@LK-Perkele-VII> <20171211150015.GB5741@LK-Perkele-VII> From: Martin Thomson Date: Mon, 11 Dec 2017 09:09:16 -0600 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 15:09:19 -0000 On Mon, Dec 11, 2017 at 9:00 AM, Ilari Liusvaara wrote: > I searched the drafts (both -00 and -01). I find absolutely nothing > to suggest this extension would play any games with the handshake > hash. And considering that extension playing such games is AFAIK > unprecidented, that would warrant rather big warnings. Ahh, I read too much into this: After decompression, the Certificate message MUST be processed as if it were encoded without being compressed. From nobody Mon Dec 11 12:43:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945381273B1 for ; Mon, 11 Dec 2017 12:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 8P_eP55K7h12 for ; Mon, 11 Dec 2017 12:43:32 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1981205F0 for ; Mon, 11 Dec 2017 12:43:31 -0800 (PST) Received: from [47.143.125.17] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1eOUvC-0003Uu-GO for tls@ietf.org; Mon, 11 Dec 2017 15:43:30 -0500 Date: Mon, 11 Dec 2017 12:43:30 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79981a4485c35ab0bccfd33feda9c621c1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.17 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 20:43:34 -0000 The discussion of this draft makes it sound like implementations=20 will have additional complexity to support certificate=20 compression. Complexity adds security risks, so just how much=20 benefit does certificate compression provide? My naive thinking=20 is that most of the data in certificates is signatures, which=20 shouldn't be very compressible. Of course, for small systems, even a small improvement may be important. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345=20 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos,=20 CA 95032 From nobody Mon Dec 11 14:36: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 0F1BE124234 for ; Mon, 11 Dec 2017 14:36:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0-mrwa6HVJ8 for ; Mon, 11 Dec 2017 14:36:03 -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 8CBFA128B91 for ; Mon, 11 Dec 2017 14:35:59 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id g10so42680810qtj.12 for ; Mon, 11 Dec 2017 14:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1MYcZoG0Sfi6ryF8QNH9Ina67ghyiR13KSzipSqj/xA=; b=QYIzZlRJfqkz+TX8tVbgVnvywRrMm8rel2o1Gqt1OknpzxkiuC5cXjf+nvbY+Gd2gG P+ndNk9/DYbyR4BJ/CrwUSkXHDNUVGqHTnFWtSNsJ8H9gAx6jdl7EnA2hl8HHUDx+Hvq X071vaUgQlPmtl/66ZvUWD4x50RrzWrQQE8Lg= 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=1MYcZoG0Sfi6ryF8QNH9Ina67ghyiR13KSzipSqj/xA=; b=pIYUz7KqMgrlHzRtaT9SrCfiZrIsOHUdZlXj75wkJVaiCGGEoLZEurBRsXXBMQZ2jO BigHgaOaZMOxPsH947LIfBt6v9HJA4x69hvhQWHt7WgJFqx1+05jrT+60dqDwVlFcWEb dAOvEs3UgwhNgq1I5JWRS+HlPMfZiYzsxPm+5dLteAk/xY/GCJ2yRc/2mtO4yUjExPgL oarjSiQhFVLKU9fpspbvFC20Uh3I9FpmFcDvAhDr4rtPUmR1/1UDHEVyUALQU5lyyJV6 vp/BZsvesQ7YTvE3QsypFfqt8Wo6oGTg2BvZOnz6Xt4KhGEGrhOeX1wwb6bnJHzCU0gi bcDw== X-Gm-Message-State: AKGB3mICKkeXTAU+pAQtyl12E+CqPmV+TD8TKHCwq6dW6n5+SkyPVzus fCPCy9b+6Udcje2TbfH6jPrsPJqknqdFe4ksyHB3dQ== X-Google-Smtp-Source: ACJfBov1lNagXn2dNKbxud5QgFohpX0ZTv59e0/1uL8onb18dcderwMx4fDtfZfp9KuEozTiTBlLB9y31kOEEyDHL04= X-Received: by 10.200.50.61 with SMTP id x58mr2963159qta.117.1513031758600; Mon, 11 Dec 2017 14:35:58 -0800 (PST) MIME-Version: 1.0 References: <20171116031327.GJ82825@kduck.kaduk.org> In-Reply-To: <20171116031327.GJ82825@kduck.kaduk.org> From: Nick Sullivan Date: Mon, 11 Dec 2017 22:35:47 +0000 Message-ID: To: Benjamin Kaduk Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="001a114045748173430560182823" Archived-At: Subject: Re: [TLS] draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 22:36:05 -0000 --001a114045748173430560182823 Content-Type: text/plain; charset="UTF-8" Ben, Putting the authenticator in an encrypted tunnel is not necessary for binding, but it is necessary for keeping the certificate itself confidential. I'll add text to that effect. Nick On Wed, Nov 15, 2017 at 7:13 PM Benjamin Kaduk wrote: > In the exported authenticators draft we claim that "The > application layer protocol used to send the authenticator SHOULD > use TLS as its underlying transport." This is of course natural -- > why would you be using TLS authenticators if you were not using TLS > -- but it seems that we would also benefit from saying what > properties are actually *required* of the channel used to transport > the authenticator. (Confidentiality? Binding to the key material > of the TLS connection?) > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114045748173430560182823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Putting the authenticator in an en= crypted tunnel is not necessary for binding, but it is necessary for keepin= g the certificate itself confidential. I'll add text to that effect.

Nick

On Wed, Nov 15, 2017 at 7:13 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
In the exported authenticators draft we claim that "The=
application layer protocol used to send the authenticator SHOULD
use TLS as its underlying transport."=C2=A0 This is of course natural = --
why would you be using TLS authenticators if you were not using TLS
-- but it seems that we would also benefit from saying what
properties are actually *required* of the channel used to transport
the authenticator.=C2=A0 (Confidentiality?=C2=A0 Binding to the key materia= l
of the TLS connection?)

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a114045748173430560182823-- From nobody Mon Dec 11 15:49: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 7B558128BBB for ; Mon, 11 Dec 2017 15:49:08 -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 zCr8xlrwC6T4 for ; Mon, 11 Dec 2017 15:49:06 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 BC2C8128B91 for ; Mon, 11 Dec 2017 15:49:06 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id p3so16327486oti.5 for ; Mon, 11 Dec 2017 15:49: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=Yq294oIjOmLrcpn/Jxkm1P1sDjoK8WBzlR8vt1krLsU=; b=O7X4T3QBlh6kZ9xmgTpJTGygouBhlTHT1QOL1ne37gjYFdHEh3+p5AE4kW/9VI5PfI gVgfiFwuMZ7k8su7PGmvEGa8f/aud/a0JyQ/zAtjvGAQRVD/RWgxqdSgqkLNR1+LbUIo iuCqtpu0vbASbgfkWuKgbJ02NOI7i0SPpwn5KCJsaaOnxSO3RiGtKzEWurQ2S9+3PGAF FC2M3sDmBfaSbUKJ4b7wQcGDU84X2tMKahiCWzVts73u95+kosVOUJQ74zaPCnp+BeuC LfpiG2/69kWiZ5Ho5FAnDf5Unp9MIjY/e3BQ13PvYZFv9/s/cDDjjzs7MwZiNzK5MEsP UtNw== 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=Yq294oIjOmLrcpn/Jxkm1P1sDjoK8WBzlR8vt1krLsU=; b=jM1mSOAvoo2/T8DGRDH8Re2071fG2Pb7b/+Fh4DIzbRctO/sPImpaCDu4lH8Aq/E3y EygR1xhs/Lgda/K+Q57+mjsek7WCXZGCcO51XNBiz+O9NLR6FZ372O+oOKY7Ib9VZoZT 3cXU0L0xTPZxW4E6FN0jUsc9Nd7E1SqG3uWTmBOcP/SYxBKA59QscqIjHACTxfMoTeKO omfWifvbd35KZqiMPnIMMlvevz4GgWkjCOrCijFZj8pRyHhUeOSVvfI0no7fGhQBePK5 puVz32QFslk0q3mD4ZCcLfzjaIYeyfV2y3hjXoHhmTfgUIFwePbAd/7UjWl/I7cIM30f mvHA== X-Gm-Message-State: AKGB3mJZEmID8rU2Z4E+1/530m3CpjOwvv3gP8tFLjTbRYy85uXdfK2E RqI0PBDvcuYFnIYTQ1e5HvS7svOwYeUSEkNh9Gx4yg== X-Google-Smtp-Source: ACJfBotZpKROcMvDGBUkJw0KzPfoyEGSqp/q9TSp3pKHCK3dZmRV3ZEg6lU6XHe81lwMxelmEPY0qZ8aB0kVndPLrh0= X-Received: by 10.157.67.146 with SMTP id t18mr1894629ote.103.1513036145947; Mon, 11 Dec 2017 15:49:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 11 Dec 2017 15:49:05 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 11 Dec 2017 17:49:05 -0600 Message-ID: To: Bill Frantz Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:49:08 -0000 Certificates are pretty wasteful, outside of the keys themselves. There has to be some significant gains to be had. I think that we have discussed generating a dictionary that would be useful for certificates, so if we do that we won't know the full answer yet (I see no mention of that in the draft, so I guess that I might be in dreamland). On Mon, Dec 11, 2017 at 2:43 PM, Bill Frantz wrote: > The discussion of this draft makes it sound like implementations will have > additional complexity to support certificate compression. Complexity adds > security risks, so just how much benefit does certificate compression > provide? My naive thinking is that most of the data in certificates is > signatures, which shouldn't be very compressible. > > Of course, for small systems, even a small improvement may be important. > > Cheers - Bill > > ------------------------------------------------------------------------- > Bill Frantz | When it comes to the world | Periwinkle > (408)356-8506 | around us, is there any choice | 16345 Englewood Ave > www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Dec 12 16:32: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 9F825127601 for ; Tue, 12 Dec 2017 16:32: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, 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=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 bYAlie-opzbb for ; Tue, 12 Dec 2017 16:32:18 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2161C12711D for ; Tue, 12 Dec 2017 16:32:18 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id k19so1749806qtj.6 for ; Tue, 12 Dec 2017 16:32: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=t5f5XugpjK2ZRZ5Oxq7wlG5TGpXy+6FoGvqc0hBjnhY=; b=p6jkcb7Kh4DZnAshZ/b7guTNS3/egvD9CCsH0qe9j6PLyzL1xCY8fU4/JjIFf/nWH3 6NTSMno/i5JlwpojRb8uLU4toxTf7lyFvbAh6CmS8NpLWfjDkheTd6nfD8bQD6Sn/TZu rbizgB3CZJPn292mWHHXmw8VuBzGfLyNIQcRVy937bygbx9/e/Q5OdXS2XqaWSAaQVYL isPLPLPMsRlhd1GOtO0YbleW7LVE/+p0cV1GcHZ/QirHgSxuqp3soPVT8okAOD5jnvSf SST8RlefhxcAbGOUq6G89ci78eLLRH3Te6ihFQMKMKl9ExbVtJj8AT6WdLU0SW4AqUtv I60Q== 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=t5f5XugpjK2ZRZ5Oxq7wlG5TGpXy+6FoGvqc0hBjnhY=; b=rI6L2xg2THEfzIb9/2bhpfrT2DRXOAeuVF8nh9v4ELiv+fDZX1WUZVBTv4rv6VS1au Zf2rXcgGX4H9N1x2u2Ffj+fIhuHZp4Xdd8qqOnbfQ7k26d/4q2JpFCNwuWDhZil2CLOr LJsjwCoNAq+2ac3QVbc0anfNifXLAFnwfLn5aEOGjVC2Pwi/T3aAFS0FzUflt5ZfS8CT tnppqeXninMX2TADQdmwCfpds4k2NR0D8Q5A48/e9HsvWhOKjCT+GW100OLwOitiTy3s zVgeTug41eVEh+xuAHkMg+7UdpDkdZkFC0xyrtGAPxqZ9mFjCleK/BTN8E5R6r8cFU1N PcQg== X-Gm-Message-State: AKGB3mJ5D6PKFKOq/utzJMwca2CDjWoRBo8SSS7nkIYbiqLdRystDRA2 OeUjKuDBKuz3i4PVfEsISgUT3LuV1BuHxRVI12x+4w== X-Google-Smtp-Source: ACJfBostWONmImSa0bRF4Tv9n4Uj2WjRv9OlrqN+MiLzm+Rf+4ry+ilg4XI0Y4fWxz654pCN2LNwJCe2yNfc7zEYLhc= X-Received: by 10.237.62.169 with SMTP id n38mr8853652qtf.42.1513125136957; Tue, 12 Dec 2017 16:32:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.18.33 with HTTP; Tue, 12 Dec 2017 16:32:16 -0800 (PST) In-Reply-To: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> From: Victor Vasiliev Date: Tue, 12 Dec 2017 19:32:16 -0500 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113b51244aba2b05602de67d" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:32:21 -0000 --001a113b51244aba2b05602de67d Content-Type: text/plain; charset="UTF-8" On Sun, Dec 10, 2017 at 5:59 PM, Martin Thomson wrote: > A codepoint might be premature just yet. > > The idea of using a new handshake message type is to allow someone to > choose between compressing and not. But consider the case where both > client and server support non-intersecting sets. This negotiation > would cause failure, but that would be unnecessary. > > You could allow the server to advertise multiple (as the current > format allows), but in that case, when the server certificate arrives > and is compressed, the client can't know which compression method was > used without trialing each. Similarly, when the client certificate > arrives, the server can't know which compression method was used > either. > > I think that the best solution to that problem is to include the > compression scheme in the Certificate message. It also suggests (to > me at least) that modifying Certificate rather than defining a > CompressedCertificate makes sense, though that might not fit with the > idea that you transform CompressedCertificate into Certificate before > putting it in the transcript. > https://github.com/tlswg/certificate-compression/pull/8 I wrote a PR that splits client and server compression negotiation, and moves the compression algorithm directly into the CompressedCertificate message. The idea is that now you can process this statelessly, i.e. you don't need greater handshake context to parse a CompressedCertificate message (helpful for tools like Wireshark and in general simplifies things). Also, there is now no "negotiation" -- one side just lists the algorithms it support and the other may or may not send a compressed cert using one of them. Does this PR address your concerns? > Or, you could trim the list on the server side to a single value, but > then you have to deal with TLS 1.3 CertificateRequest more explicitly, > which is currently not at all addressed. In that spirit, I would also > suggest that you describe what happens to a TLS 1.3 Certificate > message that contains extensions (the entire thing is wrapped up as a > whole, I assume). > Indeed. This is why the draft compresses the Certificate message, as opposed to just the certficiates themselves (to cut down the redundancy in OCSP and SCT messages). > In light of the changes, this seems like a bug: > > If the server chooses to use the cached_info extension [RFC7924] to > replace the Certificate message with a hash, it MUST NOT send the > compress_certificates extension. > > The server could send the extension to allow the client to compress > even if it had a cached certificate. > Yup. The PR above removes this entire section, since the server no longer sends the extension to opt into compression. --001a113b51244aba2b05602de67d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Dec 10, 2017 at 5:59 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
A codepoint might be premature just yet.

The idea of using a new handshake message type is to allow someone to
choose between compressing and not.=C2=A0 But consider the case where both<= br> client and server support non-intersecting sets.=C2=A0 This negotiation
would cause failure, but that would be unnecessary.

You could allow the server to advertise multiple (as the current
format allows), but in that case, when the server certificate arrives
and is compressed, the client can't know which compression method was used without trialing each.=C2=A0 Similarly, when the client certificate arrives, the server can't know which compression method was used
either.

I think that the best solution to that problem is to include the
compression scheme in the Certificate message.=C2=A0 It also suggests (to me at least) that modifying Certificate rather than defining a
CompressedCertificate makes sense, though that might not fit with the
idea that you transform CompressedCertificate into Certificate before
putting it in the transcript.


=
I wrote a PR that splits client and server compression negotiation, an= d
moves the compression algorithm directly into the CompressedCer= tificate
message.=C2=A0 The idea is that now you can process this= statelessly, i.e.
you don't need greater handshake context t= o parse a
CompressedCertificate message (helpful for tools like W= ireshark and in
general simplifies things).=C2=A0 Also, ther= e is now no "negotiation"=C2=A0 -- one
side just lists = the algorithms it support and the other may or may not
send a com= pressed cert using one of them.

Does t= his PR address your concerns?
=C2=A0
Or, you could trim the list on the server side to a single value, but
then you have to deal with TLS 1.3 CertificateRequest more explicitly,
which is currently not at all addressed.=C2=A0 In that spirit, I would also=
suggest that you describe what happens to a TLS 1.3 Certificate
message that contains extensions (the entire thing is wrapped up as a
whole, I assume).

Indeed.=C2=A0 Th= is is why the draft compresses the Certificate message, as
oppose= d to just the certficiates themselves (to cut down the redundancy
in OCSP and SCT messages).
=C2=A0
In light of the changes, this seems like a bug:

=C2=A0 =C2=A0If the server chooses to use the cached_info extension [RFC792= 4] to
=C2=A0 =C2=A0replace the Certificate message with a hash, it MUST NOT send = the
=C2=A0 =C2=A0compress_certificates extension.

The server could send the extension to allow the client to compress
even if it had a cached certificate.

Yup.=C2=A0 The PR above removes this entire section, since the server no=
longer sends the extension to opt into compression.
<= /div>
--001a113b51244aba2b05602de67d-- From nobody Tue Dec 12 16:41: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 94A8E12704A for ; Tue, 12 Dec 2017 16:41:03 -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, 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=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 nAHIlrv_aN40 for ; Tue, 12 Dec 2017 16:41:01 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A23126CBF for ; Tue, 12 Dec 2017 16:41:01 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id e2so1824951qti.0 for ; Tue, 12 Dec 2017 16:41:01 -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=0XM6G9RCfz4IUUv6YTiJ3+n79IAQE0wy3xAX0nRcNMM=; b=Rw8Hp/vviNxBZ81GfNMSPTpLKSfN5yIv61Y8KXQe9t3qAsrln0czeDX0cappOfrNEf 38HsKW19MOmzUxfn5ZcTyw/A7qOmNmrvt0FVPCigY/J2SC4E9zZZGRa3Jry+pph5NNOS dlIsXgx6tPIpMIu0NrlZjlMA+VKqNdIaQWMiFObzRYmQiECkksrTaR7hXXt9ANZVAqmE 1drO6JQ6quQJKKIt4uT2kmoplSp3pYjEfiG69cpDi0ld4k25TO0/Pw7AgxprROQHeVV8 rbcnmt/TMbIcfwybXeyekN4OKfacZfjqROZlHsYAHEW+Ts5FtmqKDGZo0bLQPcd14nFo zMWw== 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=0XM6G9RCfz4IUUv6YTiJ3+n79IAQE0wy3xAX0nRcNMM=; b=lCL5NkzbdXotFWAgtoavJYHE5NsRJ4zV8rr2cZ5fDIqLRe7eZmDzl4gDtMcrmFQFBp 8OiMlWOMZyU9q3OmNhwiw7jw7+kyX+sSuEvbKo2iLkprc4IZq8L9emQxw+8kiETTrQhy qLczom6/cK4i3lm63xMMwFefu2vywzPr5sIG+nRUzz142ijOcCZ3OGlUC9/bMNWGcAZd B78tKPJgJ1bcBXZdTVhivAXREVm0LCYDOciQH3KiFuxGoQ9ID1r4je35Enn9tkyFVYO2 N5FbEtC3O4MrmPaJGncPcSojwFfOywVaa4vxU5GwYqXJU3PjalA88BbfWxRLTo7rwK4D A4Ng== X-Gm-Message-State: AKGB3mIIBYhAe2YYfkWRmylkwGb5bEb5D4VbL/OTrAUjglE0O4eBUtd5 aHwXaVIm1tm+O9rnfwS/rlhXyLWXjHgldtQRjE8ZVntpesc= X-Google-Smtp-Source: ACJfBout+Xq2hpCqX9u9SjJS05Pp7/YELVdLliPME58YfdWWZ/AOMkuGLGFH9bB6s7K796wEFZfApZVGEX3+ys3OyUo= X-Received: by 10.237.37.5 with SMTP id v5mr8310380qtc.32.1513125660244; Tue, 12 Dec 2017 16:41:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.18.33 with HTTP; Tue, 12 Dec 2017 16:40:59 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 12 Dec 2017 19:40:59 -0500 Message-ID: To: Martin Thomson Cc: Bill Frantz , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113e317c7b7a7c05602e05e0" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:41:03 -0000 --001a113e317c7b7a7c05602e05e0 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 11, 2017 at 6:49 PM, Martin Thomson wrote: > Certificates are pretty wasteful, outside of the keys themselves. > There has to be some significant gains to be had. I think that we > have discussed generating a dictionary that would be useful for > certificates, so if we do that we won't know the full answer yet (I > see no mention of that in the draft, so I guess that I might be in > dreamland). Indeed. I've presented some numbers on this back in Chicago: https://datatracker.ietf.org/meeting/98/materials/slides-98-tls-certificare-compression/ There is currently no pre-shared dictionary in the draft, since deciding what to put into that dictionary is somewhat of a hard question (both from the technical and from the ecosystem perspective). I'm still working on making one, but the current plan is to not block the draft on this, since the simple scheme is already quite effective, and adding it is a matter of adding another compression algorithm to the list. --001a113e317c7b7a7c05602e05e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Dec 11, 2017 at 6:49 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
Certificates are pretty wasteful, outside of the keys themselves.
There has to be some significant gains to be had.=C2=A0 I think that we
have discussed generating a dictionary that would be useful for
certificates, so if we do that we won't know the full answer yet (I
see no mention of that in the draft, so I guess that I might be in
dreamland).

Indeed.=C2=A0 I've presente= d some numbers on this back in Chicago:


Ther= e is currently no pre-shared dictionary in the draft, since deciding
<= div>what to put into that dictionary is somewhat of a hard question (both
from the technical and from the ecosystem perspective).=C2=A0 I= 9;m still
working on making one, but the current plan is to not b= lock the draft on
this, since the simple scheme is already quite = effective, and adding it
is a matter of adding another compressio= n algorithm to the list.
--001a113e317c7b7a7c05602e05e0-- From nobody Tue Dec 12 16:43:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE55127601 for ; Tue, 12 Dec 2017 16:43:23 -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 PQh2ZgeQwODC for ; Tue, 12 Dec 2017 16:43:21 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 74B6912711D for ; Tue, 12 Dec 2017 16:43:21 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id o23so640206otd.1 for ; Tue, 12 Dec 2017 16:43:21 -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=oJ5cPyb7fHCt5LQy6J5w3tvhoDgP1cgMjHqYolkO99E=; b=AR+RqrMoCJo1eVXP5ezOYnK1/gdBxZ+P/Q98/VjKbgiatVmAKryuDHzwC12CFwknD4 ajYHu7cQ1WipwBIG+w/Ekpzv42Ro19yCxajbPreXSYYQ3e8DXd96uzjdCnrJlnjfiqRY smoh3wPPoIAnFrSKC1ppAFRzq+TTzBdhtz8nwrpq+O9tcOIWE+4nmK5YvNs+AUfh1zY/ vyKBe3W2AGrueiQSZnYlhs/HqQBGCQ1jRmqPYcG6PSVYfuq3fI8HWlAMb9BMwyxpOLaP xrW0ZNZ7OBwRmIsBPCjYhc1PiYNwA8zlkDQC/EjFOx5w8fEczvHeFsDncEXpb26nTo8d nAlw== 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=oJ5cPyb7fHCt5LQy6J5w3tvhoDgP1cgMjHqYolkO99E=; b=qXMb8fFqWmO5veRaUE93mzHiZMH8skCaNdgZoTV7eUBw/W2qFwu/MiMkD80MGMLwBO KA7N+7BcDUOzZgjBEG2y/aDUBnRij+XhWn4po2G8Tp1JMy7eh1stttwfZzhSdEkr3u/n bESLkTt0pIIIgsvMA7zERVTBJErXp8Uy8gbOB23c4JKVG0/mpkVnVOCo6obsFWdv9khx AXMX4iOWy4tQUzge+Ydhtf9VIBqRc0cYFIp69HpfObb6PiH1FmitEofGWBzaMHz0mIXa IinuhYnr93UZt+VpeUBXeaBEpABE07S7HzN3F7omhRCErEwEwcKmujoL3nZlu/9HnaFf IEJA== X-Gm-Message-State: AKGB3mLCLGPjbY8jhN0GIsLH8DALRTUCO8P3uqTRrQgu8jAg03C0rseU dxnXaOv5zQVDTYIDKFHW/Z3xpsSyTTneqp89at0= X-Google-Smtp-Source: ACJfBouKmJ5eI221yp1nlCyzzMF2YRHSSjq+SEK/d0zyzJOZWv+mVLehMVY09aYoILMsgkGlkubKucsBegEIPhe6zlk= X-Received: by 10.157.88.141 with SMTP id x13mr598959otg.175.1513125800537; Tue, 12 Dec 2017 16:43:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 12 Dec 2017 16:43:19 -0800 (PST) In-Reply-To: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> From: Martin Thomson Date: Tue, 12 Dec 2017 18:43:19 -0600 Message-ID: To: Victor Vasiliev Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:43:23 -0000 On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev wrote: > https://github.com/tlswg/certificate-compression/pull/8 That's a lot cleaner. Thanks. Some minor quibbles, but I like this construction far better. A question about client certificates prior to TLS 1.3: Are we happy making compression for client certificates only available in TLS 1.3 (or higher if we can assume that we will maintain parity in future)? I think that I can live with that. From nobody Tue Dec 12 17:04:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB1B128656 for ; Tue, 12 Dec 2017 17:04:30 -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, 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 T6JNwJiBbBbj for ; Tue, 12 Dec 2017 17:04:28 -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 022C5126CBF for ; Tue, 12 Dec 2017 17:04:27 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id d141so80987qkc.12 for ; Tue, 12 Dec 2017 17:04:27 -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=kxZurYEHDsluRmiwEPLtNcTB4vmBlnlLtCHjoN2ewXY=; b=CcrCpLQ93fEvfyse+xqxR77eyJ6+SEkE2khimYMxEjysjrQyDyepABqw5/u/FzvsDv wWLxd1/uKzjicyZWJffNpNhYrgHkUe7JBioZRbJtEXXKbAS1fm0V6NIycVGViMhruaV6 MmpNXxyHgIUh28TiikZ+/DiDKMhU95WL3C8si0JGFzyKGaHli19AzUT9TaFP1DKTtLVL ep6K7GxtcYziDHN00e5u3wbnxW5k4ioH6v0bZa0rd1y8jyWhsB3mrUBJKAGyG2WgGCHj IplzbiFPQTSZMKBg3W1SJuHH/dsqAv+2D1sSPwLTmpTpAuTt17tSiZAJjm2SKfv0YnGy VLsg== 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=kxZurYEHDsluRmiwEPLtNcTB4vmBlnlLtCHjoN2ewXY=; b=I348Lm2FU/HRNB2mXR9AMh3elUvWO6FcxvlSCsDBRoMTAY/XPaXLQxDJ9v+bUylyn9 v4GdGcRCFVL4hO05SyAOfXAFAQNfPdz2gZ7RhKW8AWmo7qfMQ9sej4cxQvgwQ/bZ3jFT fxNBAFLZ+iqp0xPqYY1x+d8e2o3xN7KrmCS50YTp8svLd1o05X9B8qkA8F1r751AwbMD fMXSqbODX7NKqgjZpIgzAnr6QfFcLBt/I/2yr1i9Okd17jFMG6NT3X4fsBjPzr0xK621 yZy8p+5tiGE9TfwDePl5I8fa4jjYCbh+4X6yYf6afRDYUwjtkmeRRADS9YG9y1OZBIhT PCZQ== X-Gm-Message-State: AKGB3mKLWUEuKilg/hyCwj/siGAdbMyj72X+OI8e/GI48xsn87Aka9CP 6yBkHkb6yqRqKaFOh+Vn5bVTqL7s2ckWT21btelqyA== X-Google-Smtp-Source: ACJfBou7mmiBhZjyRrQXMr2ysI1WJasriU008YjK4ELGl+AkVsYS4eUkooBSU3XCzOEwVl0qchRRZ4WbrxZJfsPHzvA= X-Received: by 10.55.105.131 with SMTP id e125mr8010067qkc.214.1513127066666; Tue, 12 Dec 2017 17:04:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.18.33 with HTTP; Tue, 12 Dec 2017 17:04:26 -0800 (PST) In-Reply-To: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> From: Victor Vasiliev Date: Tue, 12 Dec 2017 20:04:26 -0500 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114ff3a24ffbd205602e5919" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 01:04:30 -0000 --001a114ff3a24ffbd205602e5919 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 12, 2017 at 7:43 PM, Martin Thomson wrote: > On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev > wrote: > > https://github.com/tlswg/certificate-compression/pull/8 > > That's a lot cleaner. Thanks. Some minor quibbles, but I like this > construction far better. > > A question about client certificates prior to TLS 1.3: Are we happy > making compression for client certificates only available in TLS 1.3 > (or higher if we can assume that we will maintain parity in future)? > I think that I can live with that. > Pretty much. The initial draft did not have support for client certificates, and besides, due to middlebox issues, I expect everyone to deploy this only for TLS 1.3+ anyways. --001a114ff3a24ffbd205602e5919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 12, 2017 at 7:43 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev <vasilvv@google.com> wrote:
> https://github.com/tlswg/certificat= e-compression/pull/8

That's a lot cleaner.=C2=A0 Thanks.=C2=A0 Some minor quibbles, but I li= ke this
construction far better.

A question about client certificates prior to TLS 1.3: Are we happy
making compression for client certificates only available in TLS 1.3
(or higher if we can assume that we will maintain parity in future)?
I think that I can live with that.

Pretty much.=C2=A0 The initial draft did= not have support for client
certificates, = and besides, due to middlebox issues, I expect everyone to
deploy this only for TLS 1.3+ anyways.
--001a114ff3a24ffbd205602e5919-- From nobody Tue Dec 12 19:06:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E41270B4 for ; Tue, 12 Dec 2017 19:06:00 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.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 WD3MF3Mw88Em for ; Tue, 12 Dec 2017 19:05:58 -0800 (PST) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9F5126CBF for ; Tue, 12 Dec 2017 19:05:57 -0800 (PST) Received: from seraph (unknown [112.97.63.97]) by gondrom.org (Postfix) with ESMTPSA id 4860B638AD; Wed, 13 Dec 2017 04:05:52 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=hU8PwrXpalq/nFO8puGaB5ah9jKf36fE84JEvt5Z3LvIWXZQvpmYp2M4bKtmk/mowMi9sWt/I1r41aEszwIfTYr2YntFtqgH/JyTljKLxYaay6y81ZioT5bkRDVjLfTE19refMc35ZCAOhUHwpQXADwIKJRgnXHH8NHe7l3fAGw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; From: "Tobias Gondrom" To: Date: Wed, 13 Dec 2017 11:05:45 +0800 Message-ID: <002901d373bf$4a4d3d00$dee7b700$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01D37402.5872C6F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNzvfoswcT4PA76RCa5zI0lGpXK9Q== Content-Language: en-us Archived-At: Subject: Re: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Dec 2017 03:06:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002A_01D37402.5872C6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello dear TLS WG and chairs, >From my side a strong support for the adoption of this WG draft. There are many scenarios, especially in IoT where this draft is essential to maintain the right security association. If we can achieve this, we can dramatically reduce the number of new handshakes and roundtrips in low-power scenarios and thus dramatically reduce power consumption. In battery powered IoT scenarios this can help and dramatically increase the lifetime of a device. (potentially up to a factor of 2-3 longer lifetimes). Therefore this feature is very important for the success of DTLS in IoT. Thank you and hope we can progress this extension as soon as possible, Tobias > Should have included a date: 13 December 2017. > On Nov 28, 2017, at 15:17, Sean Turner < sean@sn3rd.com>; wrote: > > All, > > In Singapore @ IETF100, there was strong WG consensus to adopt draft-rescorla-tls-dtls-connection-id, but we need to confirm this on the list. Please let us know by X December 2017 whether you oppose adopting this draft and why. > > Your chairs: J&S References: * [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id Sean Turner ------=_NextPart_000_002A_01D37402.5872C6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hello dear TLS WG and =
chairs, 
From my side a strong =
support for the adoption of this WG draft. 
There are many scenarios, =
especially in IoT where this draft is essential to maintain the right =
security association. If we can achieve this, we can dramatically reduce =
the number of new handshakes and roundtrips in low-power scenarios and =
thus dramatically reduce power consumption. In battery powered IoT =
scenarios this can help and dramatically increase the lifetime of a =
device… (potentially up to a factor of 2-3 longer lifetimes). =

Therefore this feature is =
very important for the success of DTLS in IoT. =

Thank you and hope we can =
progress this extension as soon as possible, =

Tobias
 
 
> Should have included a =
date: 13 December 2017.
> On Nov 28, 2017, at =
15:17, Sean Turner <sean@sn3rd.com>; =
wrote:
> =

> =
All,
> =

> In Singapore @ =
IETF100, there was strong WG consensus to adopt =
draft-rescorla-tls-dtls-connection-id, but we need to confirm this on =
the list.  Please let us know by X December 2017 whether you oppose =
adopting this draft and why.
> =

> Your chairs: =
J&S
 
References:
 
------=_NextPart_000_002A_01D37402.5872C6F0-- From nobody Tue Dec 12 19: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 58A69126CBF for ; Tue, 12 Dec 2017 19:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZG6sFyWdGCIG for ; Tue, 12 Dec 2017 19:34:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 E3C361273E2 for ; Tue, 12 Dec 2017 19:34:16 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1D368CC635E83 for ; Wed, 13 Dec 2017 03:34:13 +0000 (GMT) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 13 Dec 2017 03:34:13 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.21]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0361.001; Wed, 13 Dec 2017 11:34:10 +0800 From: yinxinxing To: Tobias Gondrom , "tls@ietf.org" Thread-Topic: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id Thread-Index: AdNzwOHaJTYH9+dDQqSOJuwGJGCUXg== Date: Wed, 13 Dec 2017 03:34:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022D15D6E7dggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Dec 2017 03:34:19 -0000 --_000_DBDF9AE44733284D808F0E585E1919022D15D6E7dggeml511mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIGFkb3B0aW5nIHRoaXMgV0cgZHJhZnQuIFRoaXMgZmVhdHVyZSB3aWxsIGhl bHAgYSBsb3QgdG8gc29sdmUgdGhlIE5BVCByZWJpbmRpbmcgcHJvYmxlbXMgaW4gSU9UIGZpZWxk cy4gSGFwcHkgdG8gc2VlIHRoYXQgdGhlcmUgd2FzIGEgc3Ryb25nIFdHIGNvbnNlbnN1cyBvbiBh ZG9wdGluZyB0aGUgZHJhZnQgaW4gU2luZ2Fwb3JlLg0KDQpZaW4gWGlueGluZw0KDQq3orz+yMs6 IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRvYmlhcyBHb25kcm9tDQq3 osvNyrG85DogMjAxN8TqMTLUwjEzyNUgMTE6MDYNCsrVvP7IyzogdGxzQGlldGYub3JnDQrW98zi OiBSZTogW1RMU10gV0cgY2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtcmVzY29ybGEtdGxzLWR0 bHMtY29ubmVjdGlvbi1pZA0KDQoNCkhlbGxvIGRlYXIgVExTIFdHIGFuZCBjaGFpcnMsDQoNCkZy b20gbXkgc2lkZSBhIHN0cm9uZyBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24gb2YgdGhpcyBXRyBk cmFmdC4NCg0KVGhlcmUgYXJlIG1hbnkgc2NlbmFyaW9zLCBlc3BlY2lhbGx5IGluIElvVCB3aGVy ZSB0aGlzIGRyYWZ0IGlzIGVzc2VudGlhbCB0byBtYWludGFpbiB0aGUgcmlnaHQgc2VjdXJpdHkg YXNzb2NpYXRpb24uIElmIHdlIGNhbiBhY2hpZXZlIHRoaXMsIHdlIGNhbiBkcmFtYXRpY2FsbHkg cmVkdWNlIHRoZSBudW1iZXIgb2YgbmV3IGhhbmRzaGFrZXMgYW5kIHJvdW5kdHJpcHMgaW4gbG93 LXBvd2VyIHNjZW5hcmlvcyBhbmQgdGh1cyBkcmFtYXRpY2FsbHkgcmVkdWNlIHBvd2VyIGNvbnN1 bXB0aW9uLiBJbiBiYXR0ZXJ5IHBvd2VyZWQgSW9UIHNjZW5hcmlvcyB0aGlzIGNhbiBoZWxwIGFu ZCBkcmFtYXRpY2FsbHkgaW5jcmVhc2UgdGhlIGxpZmV0aW1lIG9mIGEgZGV2aWNloa0gKHBvdGVu dGlhbGx5IHVwIHRvIGEgZmFjdG9yIG9mIDItMyBsb25nZXIgbGlmZXRpbWVzKS4NCg0KVGhlcmVm b3JlIHRoaXMgZmVhdHVyZSBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgdGhlIHN1Y2Nlc3Mgb2YgRFRM UyBpbiBJb1QuDQoNClRoYW5rIHlvdSBhbmQgaG9wZSB3ZSBjYW4gcHJvZ3Jlc3MgdGhpcyBleHRl bnNpb24gYXMgc29vbiBhcyBwb3NzaWJsZSwNCg0KVG9iaWFzDQoNCg0KDQoNCg0KPiBTaG91bGQg aGF2ZSBpbmNsdWRlZCBhIGRhdGU6IDEzIERlY2VtYmVyIDIwMTcuDQoNCj4gT24gTm92IDI4LCAy MDE3LCBhdCAxNToxNywgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPjxtYWlsdG86c2VhbkBz bjNyZC5jb20mZ3Q+OyB3cm90ZToNCg0KPg0KDQo+IEFsbCwNCg0KPg0KDQo+IEluIFNpbmdhcG9y ZSBAIElFVEYxMDAsIHRoZXJlIHdhcyBzdHJvbmcgV0cgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0 LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQsIGJ1dCB3ZSBuZWVkIHRvIGNvbmZpcm0g dGhpcyBvbiB0aGUgbGlzdC4gIFBsZWFzZSBsZXQgdXMga25vdyBieSBYIERlY2VtYmVyIDIwMTcg d2hldGhlciB5b3Ugb3Bwb3NlIGFkb3B0aW5nIHRoaXMgZHJhZnQgYW5kIHdoeS4NCg0KPg0KDQo+ IFlvdXIgY2hhaXJzOiBKJlMNCg0KDQoNClJlZmVyZW5jZXM6DQoNCiAgKiAgIFtUTFNdIFdHIGNh bGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LXJlc2NvcmxhLXRscy1kdGxzLWNvbm5lY3Rpb24taWQ8 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90bHMvSHlZbHVRV055MDk3bnV3 bGlFNFFFaW5FbnNvPg0KU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNu M3JkLmNvbT4+DQoNCg== --_000_DBDF9AE44733284D808F0E585E1919022D15D6E7dggeml511mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I also agree adopting this WG draft. This feature will help a lot= to solve the NAT rebinding problems in IOT fields. Happy to see that there= was a strong WG consensus on adopting the draft in Singapore.

 

Yin Xinxing

 

=B7=A2=BC=FE=C8=CB:= TLS [mailto:tls-bounces@ietf.org] =B4=FA=B1=ED Tobias Gondrom
=B7=A2=CB=CD=CA=B1=BC=E4:= 2017=C4=EA12=D4=C213=C8=D5 11:06
=CA=D5=BC=FE=C8=CB: tls@ietf.org
=D6=F7=CC=E2: Re: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id

 

Hello dear TLS WG and chairs, 
From my side a strong support fo=
r the adoption of this WG draft. 
There are many scenarios, especi=
ally in IoT where this draft is essential to maintain the right security as=
sociation. If we can achieve this, we can dramatically reduce the number of=
 new handshakes and roundtrips in low-power scenarios and thus dramatically=
 reduce power consumption. In battery powered IoT scenarios this can help a=
nd dramatically increase the lifetime of a device=A1=AD (potentially up to =
a factor of 2-3 longer lifetimes). 
Therefore this feature is very i=
mportant for the success of DTLS in IoT. 
Thank you and hope we can progre=
ss this extension as soon as possible, 
Tobias
 
 
> Should have included a date=
: 13 December 2017.
> On Nov 28, 2017, at 15:17, =
Sean Turner <sean@sn3rd.com>; wrote:
> 
> All,

> 


> In Singapore @ IETF100, the=
re was strong WG consensus to adopt draft-rescorla-tls-dtls-connection-id, =
but we need to confirm this on the list.  Please let us know by X Dece=
mber 2017 whether you oppose adopting this draft and why.=



> 


> Your chairs: J&S


 



References:



 
--_000_DBDF9AE44733284D808F0E585E1919022D15D6E7dggeml511mbxchi_-- From nobody Wed Dec 13 08:51: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 7875812706D for ; Wed, 13 Dec 2017 08:51:15 -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 HonJ6RQlVcnQ for ; Wed, 13 Dec 2017 08:51:12 -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 23C67126D0C for ; Wed, 13 Dec 2017 08:51:12 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 84so2758598qks.8 for ; Wed, 13 Dec 2017 08:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=GaNlEnWOgqhJDSYbjy7RVlGwvgXWK+Lcn7nXH4t5b1c=; b=I/Nue67/1KIfAfbV42fAT1xtIpdkvHEsxiZP9b+ecrztYIsDMxbRlUzjFbL/5cV4HU 4cb6fks7Xxw+oIeb1yXsI2Q83ifJQbpuqJ1hjKxGnmmCR+8ze2ZjW+n+H8Hs/k1INnGG fLxGd3DaK06aPN4g3Zj1BneVgV3ADMMi1Rvfc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GaNlEnWOgqhJDSYbjy7RVlGwvgXWK+Lcn7nXH4t5b1c=; b=Q6aNuewURMQl/J0iDnoqu/CwRMZzaEF4g4nUJmK4wQrX3+8gUZFqrAW9oVIz69lXAp NlTQh7EY/NMuS6a9ByhB02pLCBr61xZqHUy7eWowKWzWC3821h+ur1vk+rMpy265yQFI Yidz2UbokvilAvCDC8lTdbKlNps0nHcPK1kyb5HyKWKxX3VBN0S0Qr1kcLCG5T28RKFr 6jKDG0He/cVETmLoAU+CJWqaMyjMcSa6c3MIZNRwzie6NGS91alc56PqjFNmwg06B6KY nCXOpnvP6emjjRihmdhXck4S0pCPPoFIAqFz9J+62blGKOyA41FWYvFJuURqY2ksP83X kbkQ== X-Gm-Message-State: AKGB3mLYVdoNBS4WTA1DZyeDFDdU4w+ydK41VYpoIH0bAqP+vCCeryrs B5ZLzdsxhG3I3nRtx+nqhujEcggesnw= X-Google-Smtp-Source: ACJfBotcb6c5vFnpQxGPzgbsvhWjr9atkf8Z+AthGKSwl424D178rmV3Ot0Mq+5ki74Sj2L6qyIOug== X-Received: by 10.55.21.140 with SMTP id 12mr8527806qkv.175.1513183870210; Wed, 13 Dec 2017 08:51:10 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id v11sm1250094qtg.6.2017.12.13.08.51.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 08:51:09 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 13 Dec 2017 11:51:08 -0500 References: <6C12EF11-D3CE-41B4-B3AE-B46607E901AA@sn3rd.com> <46E879AF-5F68-48E5-908A-CD1660EB9D1F@sn3rd.com> To: "" In-Reply-To: <46E879AF-5F68-48E5-908A-CD1660EB9D1F@sn3rd.com> Message-Id: <100EB0C3-2AEA-43E7-8885-F93962ACB96B@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Dec 2017 16:51:15 -0000 Okay hearing no objections this draft is adopted by the WG. ekr - when you=E2=80=99ve got time feel free to submit the draft with = the name: draft-ietf-tls-dtls-connection-id > On Nov 28, 2017, at 15:19, Sean Turner wrote: >=20 > Should have included a date: 13 December 2017. >=20 >> On Nov 28, 2017, at 15:17, Sean Turner wrote: >>=20 >> All, >>=20 >> In Singapore @ IETF100, there was strong WG consensus to adopt = draft-rescorla-tls-dtls-connection-id, but we need to confirm this on = the list. Please let us know by X December 2017 whether you oppose = adopting this draft and why. >>=20 >> Your chairs: J&S >=20 From nobody Wed Dec 13 09:30: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 1456C1270B4 for ; Wed, 13 Dec 2017 09:30:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 TGFLChlr2i7T for ; Wed, 13 Dec 2017 09:30:12 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408DA126DFF for ; Wed, 13 Dec 2017 09:30:12 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id e2so4681214qti.0 for ; Wed, 13 Dec 2017 09:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=9EJfCGfpEKP3L3Wc83Xs1ZoRsR9WxB/XONz6iiwDW+U=; b=UftfdNkN5V7m0IVV1hcKMnRft+gzwT63MKkRNFTyVHONkWc+tCNXaPFTnCf3ERdFGI +ZOFTUZChFqtQ+WQZfyYsOWIQYs3ZXGyp0Kpg+m7IhiU97b8F7KGOZjVxERwQGTHIJID yyt3MKrLAa/I8Xp9HCqc2iBBFXW3KUsNiOiD4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=9EJfCGfpEKP3L3Wc83Xs1ZoRsR9WxB/XONz6iiwDW+U=; b=lY5v2FjJO0OQaFQZ1vD9xmiOxb+EbFsQH6xQ5HSnl3r+YwbT55Ub7sDOXexKXnlTrK A3MClzqPK/f46NrO/fSLvJ7egXHVjxGhVpxiY5kmNSfnDVLSPj7QPOEwcD1OvHiazGSh TvFcqg5/FG93AqNyKzBIlXZyijAi3BgzB6LliSiXCqyw/QOqAQx+CMqs76KT1TV/zNCX vsc0hzQtGOAjPywcvFfBNNoaqDG9RhFey2JuQlM9s57q0WrfZf1IQdriICeK/yH5EpLY RAHf7u97Gdp8GlHcGRpenfpTAIom7aHXmHzTtYCPnmAezLV3HCbnn5cqLdDi8azEnvzg oDsg== X-Gm-Message-State: AKGB3mIZ5fy2pz4/7pUeP8waD7s4EpY0cZI9mxQI8J/z80bDCAkzPGdE nmF0lERRcvJn8CjwOfQCkqXyw6W4d1w= X-Google-Smtp-Source: ACJfBot8yq2MXQeB4R2PuCiXsN1N7WnLkpC7WkmNqTo2No13uu4ZWPT6PAwbvTNwlXno0B2eqwvtYw== X-Received: by 10.200.25.78 with SMTP id g14mr12146747qtk.119.1513186211130; Wed, 13 Dec 2017 09:30:11 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id i5sm1299018qta.97.2017.12.13.09.30.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 09:30:10 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 13 Dec 2017 12:30:09 -0500 References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> To: "" In-Reply-To: <151282209956.24790.5482932813219061171@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 17:30:14 -0000 What should happen when my silly implementation sends both the = Certificate and CompressedCertificate messages? spt > On Dec 9, 2017, at 07:21, 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 WG of the = IETF. >=20 > Title : Transport Layer Security (TLS) Certificate = Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-01.txt > Pages : 7 > Date : 2017-12-09 >=20 > Abstract: > In Transport Layer Security (TLS) handshakes, certificate chains > often take up the majority of the bytes transmitted. >=20 > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compressi= on-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-certificate-compression= -01 >=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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Dec 13 10:58: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 E3A3C127286 for ; Wed, 13 Dec 2017 10:58:14 -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, 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 Che4RoHHQlT2 for ; Wed, 13 Dec 2017 10:58:11 -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 D4A2C127076 for ; Wed, 13 Dec 2017 10:58:10 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id j207so3268068qke.10 for ; Wed, 13 Dec 2017 10:58:10 -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=BdDfeOZOD8riCG0QVn2WAGTduQmcb0LfEzFVoBSfOME=; b=Mu3Ee55C8aLuBEM33VMwCo2Q6K3RUaMBhRLe0btbpk6sQzcKIb/9Ptwp9LVMVcmcyw ToQLgQlt/8tQDUIyxUgWzRLVIAb5EGPTwvSmGfuwbAhSIe21SCg95+ex5XA3bF3YaY/w adSLdDDzKpMtyVMQIhXfcfLUcxRyvi6e0s9V1oA7KcerlSWqQxcEwNrKcgdMUo9FwERO pmc9VV1qu2zv4RC84PYHPmvhVh0jVT6AjnQMFFydsWB9OqMMQ/peWYyWjuX8agtSZMTd tX2iCNP+c2kTTfjgPqO7FFUeB5R5Z/CSKm7gAWmIvVampsK3bkxk4Srtkfb/7LtnMVqa Lmzg== 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=BdDfeOZOD8riCG0QVn2WAGTduQmcb0LfEzFVoBSfOME=; b=IUvhdIJ+W8928acqP/duLtCWCdjT6tjl9snxulAXeybRavkyDQT/5wOW+50iXE2Y3K LHZc/IY4jv1dbwKSlTGucQw9SKt+v6loSXbAbWwwELiDHmhlCaFGzlQqluSdUddkZp+C akXhcyleY/OyqZaCm6iD71Af1TrcWHkXfjK8v0DvAXvNq9f/WIwAbyQzO38+8o1QFKwm aoG4MSykVcL4/8YODK+VtokNcY2cCjOVy78j/v8WNVZzRuwC1Zt/4o4xiqEs8LZl6ci0 az0d8hcJWN32wC/5WzJi92S9ToIGbdiyMPoh/8+Jd0SeibJ3MF/1gcwjU4753U9gxXzw ZyRw== X-Gm-Message-State: AKGB3mJe1sryibI2jV4plhoSuwJTn4JeI/S+fAuJvw3xr3lAA638lUap OsYoqNfZCEVMz30wYdEdlv1dlcrs9Pzlp45ucS+z/vu5djU= X-Google-Smtp-Source: ACJfBosawx1eoV6+LERk1OU2Q9wG6E1EFqKkDmcSiId6ZYS8W6pVa3ZjawEneuGonHOlHen4KuTLXO2CUafZWjBrEOc= X-Received: by 10.55.183.71 with SMTP id h68mr12515184qkf.315.1513191489763; Wed, 13 Dec 2017 10:58:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.18.33 with HTTP; Wed, 13 Dec 2017 10:58:09 -0800 (PST) In-Reply-To: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> From: Victor Vasiliev Date: Wed, 13 Dec 2017 13:58:09 -0500 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="94eb2c0594ce3a415805603d5915" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 18:58:15 -0000 --94eb2c0594ce3a415805603d5915 Content-Type: text/plain; charset="UTF-8" You mean sending both of those messages in series? This would be equivalent to sending a second Certificate message, so whatever TLS says should happen in that case (I assume it's unexpected_message alert). On Wed, Dec 13, 2017 at 12:30 PM, Sean Turner wrote: > What should happen when my silly implementation sends both the Certificate > and CompressedCertificate messages? > > spt > > > On Dec 9, 2017, at 07:21, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Transport Layer Security (TLS) Certificate > Compression > > Authors : Alessandro Ghedini > > Victor Vasiliev > > Filename : draft-ietf-tls-certificate-compression-01.txt > > Pages : 7 > > Date : 2017-12-09 > > > > Abstract: > > In Transport Layer Security (TLS) handshakes, certificate chains > > often take up the majority of the bytes transmitted. > > > > This document describes how certificate chains can be compressed to > > reduce the amount of data transmitted and avoid some round trips. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls- > certificate-compression-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls- > certificate-compression-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0594ce3a415805603d5915 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You mean sending both of those messages in series?=C2= =A0 This would be
equivalent to sending a second Certificate mess= age, so whatever TLS says
should happen in that case (I assume it= 's unexpected_message alert).
On Wed, Dec 13, 2017 at 12:30 PM, Sean Turner <= span dir=3D"ltr"><se= an@sn3rd.com> wrote:
What s= hould happen when my silly implementation sends both the Certificate and Co= mpressedCertificate messages?

spt

> On Dec 9, 2017, at 07:21, = internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Layer Security WG of the IE= TF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Transport Layer Security (TLS) Certificate Compression
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Alessandro Ghedini
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Victor Vasiliev
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tls-certificate-compression-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-12-09
>
> Abstract:
>=C2=A0 =C2=A0In Transport Layer Security (TLS) handshakes, certificate = chains
>=C2=A0 =C2=A0often take up the majority of the bytes transmitted.
>
>=C2=A0 =C2=A0This document describes how certificate chains can be comp= ressed to
>=C2=A0 =C2=A0reduce the amount of data transmitted and avoid some round= trips.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.iet= f.org/doc/draft-ietf-tls-certificate-compression/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/htm= l/draft-ietf-tls-certificate-compression-01
> https://datatrac= ker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-01
>
> A diff from the previous version is available at:
> https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-tls-certificate-compression-01 >
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

--94eb2c0594ce3a415805603d5915-- From nobody Wed Dec 13 12:04: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 C853D12009C for ; Wed, 13 Dec 2017 12:04:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 1ku6w8SYvkoN for ; Wed, 13 Dec 2017 12:04:50 -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 E83EF126FDC for ; Wed, 13 Dec 2017 12:04:49 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id g9so5243428qth.9 for ; Wed, 13 Dec 2017 12:04:49 -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=dfBtfFL+WYgPiH6IBn2BBzYdlafuIr/TOX6NvFyfyP4=; b=AK8Pihj5UI/+QHGUAIypJ2fef5kGHvD8YcBt9fZdIy2e1XH1Toa8oIWRnotPr3goK0 ZeSfrnhQLjoQY4fSiN26g2y2nwE0Qf0Ciok2tqcxuA3JQIrf+TBNOl0J6jPyV4AzJVOv jtM/Ntejz1iAUcFVjdJfOjpHx/qDjBWHsOToo= 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=dfBtfFL+WYgPiH6IBn2BBzYdlafuIr/TOX6NvFyfyP4=; b=lRJfrrjo/hTpeJbnx9peKlwSgM/bFVpe0Ftf5HiHN9S28D1PvOumX+0tn69uPZ893j jTp/hxwHccHVAnZ4Q6B3oKEifC7ftBT7hHEwnSKd2/37HXjh0nncsIXytnCw1rMn84eO IiWXPtoiXVPmbATY8/BG//8vXesi6i1e9BccYd8/REtaHjstJLhCnUODS05wNWixgGjV vWufuL6ncpQbbxC++e3pb2hboFHSat8XlWJ7FF3Y2vVN5EqBKKQrQUgHe71pgdnSUPdb roDei7i0YdwL0/S7TCUkXG4TUUVQfSTw0b4pNcnzl0+8PJiBnMJKFpO9/R/mRXWEP4B8 M/OQ== X-Gm-Message-State: AKGB3mJn+F3djIiOrL5mlPmkcXgESdrrBWnAFUUt1rl8rLIY57hh95AY lLWDjFpFDWN+oUqFv0v3x5Rm/nPg+hA= X-Google-Smtp-Source: ACJfBotjqx62Q62R/mvHnegn/WiWizYTHMvQURBN7AwxFy6Y7LsJL3ZZvvdd7lyeJghO6zvRGKCv6w== X-Received: by 10.200.8.56 with SMTP id u53mr12999446qth.85.1513195488890; Wed, 13 Dec 2017 12:04:48 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id k1sm1517481qtf.11.2017.12.13.12.04.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 12:04:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Wed, 13 Dec 2017 15:04:46 -0500 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> To: Victor Vasiliev X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 20:04:54 -0000 Exactly, but since are different messages I think the draft needs to say = that. And, to be on the safe side the draft should if you send one = don=E2=80=99t send the other. spt > On Dec 13, 2017, at 13:58, Victor Vasiliev wrote: >=20 > You mean sending both of those messages in series? This would be > equivalent to sending a second Certificate message, so whatever TLS = says > should happen in that case (I assume it's unexpected_message alert). >=20 > On Wed, Dec 13, 2017 at 12:30 PM, Sean Turner wrote: > What should happen when my silly implementation sends both the = Certificate and CompressedCertificate messages? >=20 > spt >=20 > > On Dec 9, 2017, at 07:21, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Transport Layer Security WG of the = IETF. > > > > Title : Transport Layer Security (TLS) Certificate = Compression > > Authors : Alessandro Ghedini > > Victor Vasiliev > > Filename : = draft-ietf-tls-certificate-compression-01.txt > > Pages : 7 > > Date : 2017-12-09 > > > > Abstract: > > In Transport Layer Security (TLS) handshakes, certificate chains > > often take up the majority of the bytes transmitted. > > > > This document describes how certificate chains can be compressed = to > > reduce the amount of data transmitted and avoid some round trips. > > > > > > The IETF datatracker status page for this draft is: > > = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > > > There are also htmlized versions available at: > > = https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-01 > > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compressi= on-01 > > > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-certificate-compression= -01 > > > > > > Please note that it may take a couple of minutes from the time of = submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Wed Dec 13 13:19:14 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 4A09B126E7A; Wed, 13 Dec 2017 13:19:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151319995327.30097.14412164791956381457@ietfa.amsl.com> Date: Wed, 13 Dec 2017 13:19:13 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:19:13 -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 WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-05.txt Pages : 9 Date : 2017-12-13 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 13 14:39: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 A23821274A5 for ; Wed, 13 Dec 2017 14:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0FmnW3RcGWL for ; Wed, 13 Dec 2017 14:39:16 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140181201F8 for ; Wed, 13 Dec 2017 14:39:14 -0800 (PST) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Wed, 13 Dec 2017 23:39:18 +0100 id 0000000000000099.000000005A31AC16.00004D80 Date: Wed, 13 Dec 2017 23:39:10 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20171213233910.4440a54e@pc1> In-Reply-To: <151282209956.24790.5482932813219061171@ietfa.amsl.com> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:39:19 -0000 Hi, The deployment of TLS 1.3 was delayed because Internet middleboxes broke when they saw unknown TLS data. I guess it's plausible to assume that the same problem will show up with compressed certificates. Has any thought been given to that? --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Wed Dec 13 14:44: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 2D4771274A5 for ; Wed, 13 Dec 2017 14:44:34 -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, 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 Cj14yvQffZ4V for ; Wed, 13 Dec 2017 14:44:32 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7DE1201F8 for ; Wed, 13 Dec 2017 14:44:32 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id j207so4046142qke.10 for ; Wed, 13 Dec 2017 14:44:32 -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=qZ95YX6XVM8vcnRIYjYF8rDTWsU6taUkxAf2qOLzHL4=; b=frtbMv6+2036ZwhTnkVssRCh1vRNAGZRyg2PEFhL2mqzqE4Vm+b98ykYH1C7OayWd1 XNWrzaEl3Gth1pen7KtPVNh2dgWxECaVym4ZyjSi1Yp8eWr7Q1lbyLGoasMt17rJFgit TVAtrhVi1pHd5nRG0dlayzI6WFwB8nGPg7BpY= 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=qZ95YX6XVM8vcnRIYjYF8rDTWsU6taUkxAf2qOLzHL4=; b=XOcShLZytf1nApWaMnRHntQkOpta4EfaMkNOUM6URIoXocchsOiW22oD6TUK4DzBW2 8qcyLRkoSozIZNUfsegQob456nDVChATEBQxBRji9bdYTFEGANXveoLMgQZSWbTP6E+K LRxzMNI5xYE7LMB4JJ6sVhldAQuPFQo081XOa8EVi8/O8afS0QxA3mkjOQztvj+xjwuU m2hxPl1TZQQIoExicYqmrakZ9PAu9QsCFEgbeYGWpKd4GpEY0HcF+tOYIwbqp9XItFFF evKRRaBLsSWuxt0cERwSABiBOA8ew5GYdUJFFPb4fvgQJUTZgZmfK+J+RnWlLlR5sMv6 qNKQ== X-Gm-Message-State: AKGB3mKOTTYk8Sna2l/vq2lQSTja3Za1B6Z65y6iL8Imajtczy9nnEnd EQzENgon9GN0HHvohWIOgimPuik0XVdF+iL3+uarG3g= X-Google-Smtp-Source: ACJfBouw1oI75cOavpSZvkMOq3zxDMHVPT4geifdfBBZhve4hSR6PcZWPR2WMIVDd9rHN4GRe3uFJOG/Wu+qlCgh2I0= X-Received: by 10.55.181.66 with SMTP id e63mr13059354qkf.130.1513205071252; Wed, 13 Dec 2017 14:44:31 -0800 (PST) MIME-Version: 1.0 References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171213233910.4440a54e@pc1> In-Reply-To: <20171213233910.4440a54e@pc1> From: David Benjamin Date: Wed, 13 Dec 2017 22:44:19 +0000 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c06c942bf4c640560408295" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:44:34 -0000 --94eb2c06c942bf4c640560408295 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 13, 2017 at 5:39 PM Hanno B=C3=B6ck wrote: > Hi, > > The deployment of TLS 1.3 was delayed because Internet middleboxes > broke when they saw unknown TLS data. > > I guess it's plausible to assume that the same problem will show up > with compressed certificates. Has any thought been given to that? > Everything after the ServerHello in TLS 1.3 is encrypted. A non-terminating middlebox cannot mess with it, and a correctly-implemented terminating middlebox would just not negotiate the extension. As for TLS 1.2, I do not think this specification has any hope of being deployable in TLS 1.2. We would only negotiate it in TLS 1.3 for BoringSSL. This isn't much of a loss as this requires a code change to deploy anyway, and the code change may as well carry TLS 1.3 too. (To that end, it may be better to explicitly say in the document that the extension applies to TLS 1.3 only, so other folks don't try to deploy it at TLS 1.2 and have things break in buggy non-compliant networks they aren't testing in.) David --94eb2c06c942bf4c640560408295 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 13= , 2017 at 5:39 PM Hanno B=C3=B6ck <ha= nno@hboeck.de> wrote:
Hi,
The deployment of TLS 1.3 was delayed because Internet middleboxes
broke when they saw unknown TLS data.

I guess it's plausible to assume that the same problem will show up
with compressed certificates. Has any thought been given to that?

Everything after the ServerHello in TLS 1.3 is e= ncrypted. A non-terminating middlebox cannot mess with it, and a correctly-= implemented terminating middlebox would just not negotiate the extension.

As for TLS 1.2, I do not think this specification h= as any hope of being deployable in TLS 1.2. We would only negotiate it in T= LS 1.3 for BoringSSL. This isn't much of a loss as this requires a code= change to deploy anyway, and the code change may as well carry TLS 1.3 too= .

(To that end, it may be better to explicitly say= in the document that the extension applies to TLS 1.3 only, so other folks= don't try to deploy it at TLS 1.2 and have things break in buggy non-c= ompliant networks they aren't testing in.)

Dav= id=C2=A0
--94eb2c06c942bf4c640560408295-- From nobody Wed Dec 13 15:01:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137E6124207 for ; Wed, 13 Dec 2017 15:01:28 -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, 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=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 nmFxCVJi5FWj for ; Wed, 13 Dec 2017 15:01:26 -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 5303C1201F8 for ; Wed, 13 Dec 2017 15:01:26 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id 33so5860074qtv.1 for ; Wed, 13 Dec 2017 15:01:26 -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=lHIHi0kvcwK1D6RaSacbvioup4VOnXNpo0D1sMwv3Uw=; b=aqIqx/gHT35ZxTT8Qcn2M9Au1q28ZxQsVViTHyeAz3gM3MoinDX/NBsFZpvVq+NeeH AWZf6ePD6BRaFTKum4Yv69fMB1CENxeluFhU+YcfUh9wF6ZK4KSkaGzyUZQUlL1I2hoC t7aK8QsDYIEcgqAiOLhFyFmHKj6rmEGhYOu7kmnFagoXszgRwJ0ibz2i9IuHx6RtO/GD uzvpsNdYKy6eFoIw1KipthZ/2YNTR8He1ab85+w/FCqx3slX6Y9U0RI+nXBTHnPhN+31 e+p/zCS6bon4Dx+ZfAkr60GzKyKtQwlKDkhZmVt0bTPgJo7bOBNuFYtXsLMF3JvmDir6 quYA== 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=lHIHi0kvcwK1D6RaSacbvioup4VOnXNpo0D1sMwv3Uw=; b=TfppAA1DBdG1ZY+yuGray328Iu/ctIO7Pe5kBpTb+GwYtzfhbPmp1YET06pVVEu4zU fc0JaW/HGUVT42uhCzPrg8lb2NsI7ElXk2xD4NVk7YBcn6H8Bgr2Y/mfkRArRQVs6mR5 U7XOKC4P7sGfo+eAGIOZxQ9sWeJFNDBWSF4P6i04HsEpjHcFwJl+JKG+XGE9bRalhX7W jenqFYTnZ+egjn/sSJ6TJ5Kn9koG/GeRqH39PSxDWaUarCBBQOzbV/EBqM4Q3gE/Z1tq 3WIWMxOSWwFCT7//fj2HOFfHdqEKFQ0N/gHimU4hVBB37Pay4KMfQjTqwIz6kGs2O93p 1UsQ== X-Gm-Message-State: AKGB3mKBZwJRBpvPzKgd5LP+RF5fHXgPCXQ2p+KiFxp689ESvtJfROnB 4q/zQSGGNyq+wZiae5yaBQ0NbxbYIIfKOy9z2wDt1w== X-Google-Smtp-Source: ACJfBotG8i8yFGnsCOqfFuMLc6oCFr+UsGEOAmbBxk68isGI4RbXZ4b45gvINx9684dYaa86Do5XgSlkjzVWnFgpk7I= X-Received: by 10.237.55.74 with SMTP id i68mr13773089qtb.237.1513206085183; Wed, 13 Dec 2017 15:01:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.18.33 with HTTP; Wed, 13 Dec 2017 15:01:24 -0800 (PST) In-Reply-To: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171213233910.4440a54e@pc1> From: Victor Vasiliev Date: Wed, 13 Dec 2017 18:01:24 -0500 Message-ID: To: David Benjamin Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11359c962ea81b056040bfd0" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 23:01:28 -0000 --001a11359c962ea81b056040bfd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 13, 2017 at 5:44 PM, David Benjamin wrote: > On Wed, Dec 13, 2017 at 5:39 PM Hanno B=C3=B6ck wrote: > >> Hi, >> >> The deployment of TLS 1.3 was delayed because Internet middleboxes >> broke when they saw unknown TLS data. >> >> I guess it's plausible to assume that the same problem will show up >> with compressed certificates. Has any thought been given to that? >> > > (To that end, it may be better to explicitly say in the document that the > extension applies to TLS 1.3 only, so other folks don't try to deploy it = at > TLS 1.2 and have things break in buggy non-compliant networks they aren't > testing in.) > We do discuss the middlebox problem in the document, but we leave it up to the implementers to decide what to do with it. --001a11359c962ea81b056040bfd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 13, 2017 at 5:44 PM, David Benjamin <davidben@chromium.org> wrote:
Hi,

The deployment of TLS 1.3 was delayed because Internet middleboxes
broke when they saw unknown TLS data.

I guess it's plausible to assume that the same problem will show up
with compressed certificates. Has any thought been given to that?

(To that end, it may be better to explici= tly say in the document that the extension applies to TLS 1.3 only, so othe= r folks don't try to deploy it at TLS 1.2 and have things break in bugg= y non-compliant networks they aren't testing in.)

We do discuss the middlebox problem in the doc= ument, but we leave it up to the implementers to decide what to do with it.= =C2=A0
--001a11359c962ea81b056040bfd0-- From nobody Thu Dec 14 13:47: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 72F39127599 for ; Thu, 14 Dec 2017 13:46:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fc6YeEVICO-v for ; Thu, 14 Dec 2017 13:46:56 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8E91243F3 for ; Thu, 14 Dec 2017 13:46:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 15518B537C; Thu, 14 Dec 2017 23:46:54 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 4POiine1gWpn; Thu, 14 Dec 2017 23:46:53 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7A90E2308; Thu, 14 Dec 2017 23:46:50 +0200 (EET) Date: Thu, 14 Dec 2017 23:46:50 +0200 From: Ilari Liusvaara To: Martin Thomson Cc: Victor Vasiliev , "tls@ietf.org" Message-ID: <20171214214650.GA15254@LK-Perkele-VII> References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:46:59 -0000 On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrote: > On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev wrote: > > https://github.com/tlswg/certificate-compression/pull/8 > > That's a lot cleaner. Thanks. Some minor quibbles, but I like this > construction far better. Yeah, same here, I like this construction far better than the -01 one. > A question about client certificates prior to TLS 1.3: Are we happy > making compression for client certificates only available in TLS 1.3 > (or higher if we can assume that we will maintain parity in future)? > I think that I can live with that. As others have said, this extension is basically undeployable with TLS 1.2 because middleboxes. Also, assuming parity in the future might not be a good idea. Does anyone have any idea what TLS 1.4 might be about[1] (TLS 2.0 would likely be about cleaning representation, but that would likely be a bad idea)? [1] Not Post-Quantum Cryptography. Integrating PQC into TLS 1.3 is not a difficult task (once you know the trick). And I do not see TLS changes making it any easier without weakening security. -Ilari From nobody Thu Dec 14 14:21: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 A1335124D68 for ; Thu, 14 Dec 2017 14:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJFt74DoT9AR for ; Thu, 14 Dec 2017 14:20:56 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E45126D73 for ; Thu, 14 Dec 2017 14:20:55 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id s1so4705775ybm.7 for ; Thu, 14 Dec 2017 14:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JhLmB1lY07jiwhjIfcBCU7lUSwrbRdAhq1XOEq+LVLo=; b=PR/WQkqZsU7h/eB+xG/ivodxCAfezAznGKnwLJKB3PYi+qOqz/1IdQdf+E6JwdcN1R Mvz/1LYv+OQOH4lxyarxfOrQOi30D3RdbbISrECHRgy3DvGEMi+QHFKl/eP5H4Ay6454 dPNM27KGHU0N+28lym+z6Gkl+KTFKXqDgsvUA3XqcA6n9yXGfikBdbaYna50r9SFylfN k4FwvzOIO8x7uSZX+OY8PM2XvvX2qlsNae4XWK+YPi1+BIzC91CP8DrkWaWJJt9pMQce sJ9RWPltLP936p2Ri0Ni1TB3XLDkMAtz9p15SRxiNzuyOj9IquBWhOfpqPkupsoXFCmy vn/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:from:date:message-id:subject:to; bh=JhLmB1lY07jiwhjIfcBCU7lUSwrbRdAhq1XOEq+LVLo=; b=UevFnnQohEx8rybnDIMWW8sXz4m3bbJICrw0Ug4tsHJSD8/7mYbTBLhrV4UE1hpC3Z DN+6A7H5VkhaRQKBgdSpb8/tOCMPyhjLmdMPrfctNYlmuFGjHoGj/Nzv00RVvSXOsd7h K5Ow4wPA+kB02G4cpSTUDvEle4PWE7DXMtLiJaE3NuGZDAMFqO8oTcmvedMKbOeAFucO vfshPFllyd33bCTl5TJlcCWn95eXK3PPI4Xp42yUMwJnmZNbDqNqxfVCUWayiv4M9ZNH 1ODs1qHDafEL5zel8OW09pTIbP0g4InT2eDVFFSI+dKKz+AgArZaqS/Sh8sMcJJLvQPa /hJQ== X-Gm-Message-State: AKGB3mKHtPLXz2FYGI1OasMjBok6m0Oo27eCJj027fcxNVoLebn82i70 Y/sdM6OstahVEyQQPPjRDYvhTdgIo/RVFjhonVWf1cep X-Google-Smtp-Source: ACJfBoupgBaXG09F0WVG9FAdpXuT1IJHFIHbve/z/bqmu/CMwLnT6I1r3wI7g7uFDOC8VNrVczbnu5J49SrgS350WbE= X-Received: by 10.129.91.193 with SMTP id p184mr5342599ywb.272.1513290054647; Thu, 14 Dec 2017 14:20:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.70 with HTTP; Thu, 14 Dec 2017 14:20:54 -0800 (PST) From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 14 Dec 2017 14:20:54 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114c8ee2265dcc0560544c50" Archived-At: Subject: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2017 22:21:00 -0000 --001a114c8ee2265dcc0560544c50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable TLS folks, A few weeks ago the s2n team got a mail from US CERT asking us to take a look for any Bleichenbacher attack issues and get to back to them. We didn't have any issues (thankfully!), but it was a good opportunity for us to review how we defend against BB and other related attacks. The notice was of course based on the excellent work of Hanno B=C3=B6ck, Juraj Soorovs= ky, and Craig Young. Based on the notice, we also went looking in some other code-bases and implementations we have access to, and did find issues, both classic BB98 style attacks, and small timing side channels. We've worked with vendors and code owners in each case and fixes are in place, new releases made, and so on. Based on our experiences with all of this over the last few weeks, I'd like to summarize and throw out a few suggestions for making TLS stacks more defensive and robust against problems of this class. One or two may be even worth considering as small additions to the forthcoming TLS RFC, and I'd love to get feedback on that. *First: the basic specific defense against BB98* In s2n we went with the boring basic per-the-TLS defense against BB98. We pre-generate a random PMS: https://github.com/awslabs/s2n/blob/master/tls/s2n_client_key_exchange.c#L6= 4 then we over-write this PMS only if RSA succeeds: https://github.com/awslabs/s2n/blob/55a641dc29d17780620c16713854f1c9fd31f7c= e/crypto/s2n_rsa.c#L165 since it's important not to leak timing, we use a special "constant_time_copy_or_dont" routine to do the over-write: https://github.com/awslabs/s2n/blob/master/utils/s2n_safety.c#L70 we then allow the handshake to proceed, and fail it later: https://github.com/awslabs/s2n/blob/088240d081953131deefb27a70fa6f728156f0c= f/tls/s2n_client_finished.c#L35 So far everything is standard, though we did notice in reviewing some other implementations that things can be unnecessarily complicated around handling the first step. I'm including the code links here just as an example that literally following the RFC guidance is fairly doable, but it helps a lot to have a constant-time copy-or-not kind of routine to make it much easier. *Second: hide all alerts in suspicious error cases* Next, when the handshake does fail, we do two non-standard things. The first is that we don't return an alert message, we just close the connection. This is intentional, and even though it violates the written standards, we believe it's better to optimize for frustrating attackers and not leaking information Vs making occasional debugging by TLS experts easier. I'd be interested in the thoughts of others here. We did find other implementations that just close() a connection, and we've never noticed inter-operability problems. Should we tolerate this in the RFC? *Third: mask timing side-channels with a massive delay* The second non-standard thing we do is that in all error cases, s2n behaves as if something suspicious is going on and in case timing is involved, we add a random delay. It's well known that random delays are only partially effective against timing attacks, but we add a very very big one. We wait a random amount of time between a minimum of 10 seconds, and a maximum of 30 seconds. With the delay being granular to nanoseconds. This puts a delay of 20 seconds on average on every potential attacker measurement (though obviously they can parallelize) and adds something around 2^60 bits of entropy to a measurement. The effectiveness of this technique depends on the size and distribution of the timing channel being leaked, as well the distribution of measurement latency generally, but suppose the timing leak is 10 microseconds, then the delay likely increases attacker difficulty by a factor of probably hundreds of billions. I'd be interested in thoughts on this too, as a general recommendation as "something TLS stacks can/should do is that when there's an error, mask it with a big random delay". The main "downside" of this delay is that it can tie up resources - but we're not as concerned with that. Firstly, an attacker can always cause a connection to stall for 30 seconds, and even ordinary network conditions like packet loss can trigger that. That's why we chose 30 seconds as our upper bound. Second, connections are cheap, especially in asynchronous/epoll driven models, or any model that isn't one-connection per process. We prefer to have the defense in depth. It's worth noting that this protection also helps with other timing attacks, such as Lucky13 (read https://aws.amazon.com/blogs/security/s2n-and-lucky-13/ for my write up on how the earlier version of this, with microsecond granularity, wasn't enough to defeat Lucky13, but still made it millions of times harder for an attacker) or even AES timing issues. The remainder of this mail doesn't concern changes that could made in the TLS draft, but rather just other information that may be useful for implementors. Sorry if I'm abusing the purpose of the list a little, but hopefully the last item in particular will make it worth the read. *Fourth: regression tests* We noticed that many of implementations we encountered had no regression tests. In s2n we do have plenty of tests, but actually did not have a specific regression test against BB. We didn't want to add one until the Robot attack was public, but are now adding one. *Fifth: formal constant-time verification* Regression tests on their own do not defend against timing side channel regressions, and we noticed in the commit history of some of the code we reviewed that ones had snuck in over time. For example some non-s2n code we encountered added some debug logging in the case where the padding is mismatched, which created a very small timing difference with the cost it takes to print the logging message. Here I'd like to share two pieces of work we've been doing over the last year. The first is formal verification of our code's constant time properties with ctverif and SMACK. Our integration is at: https://github.com/awslabs/s2n/tree/master/tests/ctverif We've been able to instrument our most timing sensitive routines and verify that they really do use the same number of instructions, regardless of inputs. The annotations are very readable and easy to deal with and don't mess up the code base, in fact the code I linked to earlier: https://github.com/awslabs/s2n/blob/master/utils/s2n_safety.c#L70 is annotated, that's what the S2N_PUBLIC_INPUT macro is for. These constant-time tests run on every commit and build of s2n, and defend against regressions in the code and even compiler. For those of you who may be at RWC2018/HACS, I'd love to show you more if you're interested in integrating or doing anything similar! *Sixth: fuzzy constant-time verification for code-balancing* In building the s2n formal constant-time verification, we noticed that there are more complicated aspects of TLS processing; such as CBC verification and BB98 mitigation that need to be in constant-time, but where the code also spans many functions and even messages. The solutions here typically are not small routines that are rigorously constant time, but instead rely on a degree of code-balancing: taking code paths that are "similar enough" in timing so as not to be measurable. At first, the reaction against code-balancing can often be finger-wagging, but our our survey of TLS libraries is that most are using code-balancing in some capacity. In fact, we can take the OpenSSL LuckyMinus20 vulnerability and regression as evidence that trying to be rigorously constant time on large complicated algorithms that were not designed to be constant time can seriously backfire by introducing logic errors in the very hard-to-follow constant-time adaptations. Because code-balancing is useful in these cases, and certainly used in many real world implementations, we wanted to make its effect more measurable, and more than simply good intentions. Our automated reasoning group (and in particular Daniel Schwartz-Narbonne and Konstantinos Athanasiou) has built and integrated a new tool called sidewinder. The PR integrating it into s2n is here: https://github.com/awslabs/s2n/pull/664 The great thing about Sidewinder is that it can cope with an analysis over larger and more inter-related code units, and it can produce bounds for how much may the execution paths differ by, for both instructions and memory accesses.I believe it would have prevented some of the regressions we found in our BB attack focused review of third party code bases over the last few weeks. It's another tool I'd be excited and happy to share with folks at RWC/HACS. --=20 Colm --001a114c8ee2265dcc0560544c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TLS folks,

A few weeks ago t= he s2n team got a mail from US CERT asking us to take a look for any Bleich= enbacher attack issues and get to back to them. We didn't have any issu= es (thankfully!), but it was a good opportunity for us to review how we def= end against BB and other related attacks.=C2=A0 The notice was of course ba= sed on the excellent work of Hanno B=C3=B6ck, Juraj Soorovsky, and Craig Yo= ung. =C2=A0

Based on the notice, we also went look= ing in some other code-bases and implementations we have access to, and did= find issues, both classic BB98 style attacks, and small timing side channe= ls. We've worked with vendors and code owners in each case and fixes ar= e in place, new releases made, and so on.=C2=A0

Ba= sed on our experiences with all of this over the last few weeks, I'd li= ke to summarize and throw out a few suggestions for making TLS stacks more = defensive and robust against problems of this class. One or two may be even= worth considering as small additions to the forthcoming TLS RFC, and I'= ;d love to get feedback on that.=C2=A0

First: t= he basic specific defense against BB98
In s2n we went with th= e boring basic per-the-TLS defense against BB98. We pre-generate a random P= MS:


then we over-write this PMS only if RSA succeeds:

https://github.com/awslabs/s2n/blob/= 55a641dc29d17780620c16713854f1c9fd31f7ce/crypto/s2n_rsa.c#L165

since it's important not to leak timing, we use a = special "constant_time_copy_or_dont" routine to do the over-write= :


we then allow the han= dshake to proceed, and fail it later:


So far everything is standard, though we did notice in re= viewing some other implementations that things can be unnecessarily complic= ated around handling the first step. I'm including the code links here = just as an example that literally following the RFC guidance is fairly doab= le, but it helps a lot to have a constant-time copy-or-not kind of routine = to make it much easier.=C2=A0

Second: hide all = alerts in suspicious error cases
Next, when the handshake= does fail, we do two non-standard things. The first is that we don't r= eturn an alert message, we just close the connection. This is intentional, = and even though it violates the written standards, we believe it's bett= er to optimize for frustrating attackers and not leaking information Vs mak= ing occasional debugging by TLS experts easier. I'd be interested in th= e thoughts of others here.=C2=A0 We did find other implementations that jus= t close() a connection, and we've never noticed inter-operability probl= ems. Should we tolerate this in the RFC?

Third:= mask timing side-channels with a massive delay
The secon= d non-standard thing we do is that in all error cases, s2n behaves as if so= mething suspicious is going on and in case timing is involved, we add a ran= dom delay. It's well known that random delays are only partially effect= ive against timing attacks, but we add a very very big one. We wait a rando= m amount of time between a minimum of 10 seconds, and a maximum of 30 secon= ds. With the delay being granular to nanoseconds. This puts a delay of 20 s= econds on average on every potential attacker measurement (though obviously= they can parallelize) and adds something around 2^60 bits of entropy to a = measurement. The effectiveness of this technique depends on the size and di= stribution of the timing channel being leaked, as well the distribution of = measurement latency generally, but suppose the timing leak is 10 microsecon= ds, then the delay likely increases attacker difficulty by a factor of prob= ably hundreds of billions.=C2=A0 I'd be interested in thoughts on this = too, as a general recommendation as "something TLS stacks can/should d= o is that when there's an error, mask it with a big random delay".= =C2=A0

The main "downside" of this delay= is that it can tie up resources - but we're not as concerned with that= . Firstly, an attacker can always cause a connection to stall for 30 second= s, and even ordinary network conditions like packet loss can trigger that. = That's why we chose 30 seconds as our upper bound. Second, connections = are cheap, especially in asynchronous/epoll driven models, or any model tha= t isn't one-connection per process. We prefer to have the defense in de= pth. It's worth noting that this protection also helps with other timin= g attacks, such as Lucky13 (read=C2=A0https://aws.amazon.com/blogs/security/s2n-an= d-lucky-13/ for my write up on how the earlier version of this, with mi= crosecond granularity, wasn't enough to defeat Lucky13, but still made = it millions of times harder for an attacker) or even AES timing issues.=C2= =A0

The remainder of this mail doesn't concern= changes that could made in the TLS draft, but rather just other informatio= n that may be useful for implementors. Sorry if I'm abusing the purpose= of the list a little, but hopefully the last item in particular will make = it worth the read. =C2=A0

Fourth: regression te= sts
We noticed that many of implementations we encountered ha= d no regression tests. In s2n we do have plenty of tests, but actually did = not have a specific regression test against BB. We didn't want to add o= ne until the Robot attack was public, but are now adding one.=C2=A0

Fifth: formal constant-time verification
=
Regression tests on their own do not defend against timing side channe= l regressions, and we noticed in the commit history of some of the code we = reviewed that ones had snuck in over time. For example some non-s2n code we= encountered added some debug logging in the case where the padding is mism= atched, which created a very small timing difference with the cost it takes= to print the logging message. Here I'd like to share two pieces of wor= k we've been doing over the last year. The first is formal verification= of our code's constant time properties with ctverif and SMACK. Our int= egration is at:


We've been able to in= strument our most timing sensitive routines and verify that they really do = use the same number of instructions, regardless of inputs. The annotations = are very readable and easy to deal with and don't mess up the code base= , in fact the code I linked to earlier:


is annotated, that's what the S2N_PUBLIC_INPUT macro i= s for. These constant-time tests run on every commit and build of s2n, and = defend against regressions in the code and even compiler. For those of you = who may be at RWC2018/HACS, I'd love to show you more if you're int= erested in integrating or doing anything similar!=C2=A0

Sixth: fuzzy constant-time verification for code-balancing
=
In building the s2n formal constant-time verification, we notice= d that there are more complicated aspects of TLS processing; such as CBC ve= rification and BB98 mitigation that need to be in constant-time, but where = the code also spans many functions and even messages. The solutions here ty= pically are not small routines that are rigorously constant time, but inste= ad rely on a degree of code-balancing: taking code paths that are "sim= ilar enough" in timing so as not to be measurable.=C2=A0
At first, the reaction against code-balancing can often be fing= er-wagging, but our our survey of TLS libraries is that most are using code= -balancing in some capacity.=C2=A0In fact, we can take the OpenSSL LuckyMin= us20 vulnerability and regression as evidence that trying to be rigorously = constant time on large complicated algorithms that were not designed to be = constant time can seriously backfire by introducing logic errors in the ver= y hard-to-follow constant-time adaptations.=C2=A0

= Because code-balancing is useful in these cases, and certainly used in many= real world implementations, we wanted to make its effect more measurable, = and more than simply good intentions. Our automated reasoning group (and in= particular Daniel Schwartz-Narbonne and Konstantinos Athanasiou) has built= and integrated a new tool called sidewinder. The PR integrating it into s2= n is here:


=
The great thing about Sidewinder is that it can cope with an ana= lysis over larger and more inter-related code units, and it can produce bou= nds for how much may the execution paths differ by, for both instructions a= nd memory accesses.I believe it would have prevented some of the regression= s we found in our BB attack focused review of third party code bases over t= he last few weeks. It's another tool I'd be excited and happy to sh= are with folks at RWC/HACS.=C2=A0

--
Colm
--001a114c8ee2265dcc0560544c50-- From nobody Thu Dec 14 14:43:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85901126BF7 for ; Thu, 14 Dec 2017 14:43:50 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 8yNA3KRf85t9 for ; Thu, 14 Dec 2017 14:43:48 -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 299CA1242F5 for ; Thu, 14 Dec 2017 14:43:48 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id r39so9944717qtr.13 for ; Thu, 14 Dec 2017 14:43:48 -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=dmAPwBO0uDFvaR2ZCq9BOE+aAc+FZRmbPbb6fAiI37s=; b=AwQeeZohz/jsECfJhXgUILjjr3rts5j/2pg7X112KisYR78Z2FJJDjCSs1wBUT/o3h M31nEpc/oaXj0rzIZld3VQlAuRqYiXexxBX+gBrZCciJRrtFNc9EM5cMa1W+2bMoDy80 DnJUBoRBweCJvFe3DIox2biKlte1fxkxLFWK0= 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=dmAPwBO0uDFvaR2ZCq9BOE+aAc+FZRmbPbb6fAiI37s=; b=Y4P7MvEU4wYUjRe7qar/efx074jkt4IqNNBX6SWwiwW/c4Tkc7OmJlASwLZNY62SAR dYKJZ1XmVNSruTK4NnWvUPHX1lLaXf6Mw7+TpbLKG7zPydMKVKiAvsRtqlQQmgEJDdpF UOeZNsxWC/aK++QiUCDPSvhqoQEkXnD5t18bSFDujAMKZMHtqV3epDjsmzacyY3tYlFv 2NncOGjje3oXGZer9Ir4y9MNEMqyqRTNfvGGue5rMkDV13du28DgiUA48rKSXFr17dsE gZa+K64DIm4Z+mqgAkX771kiHea2BG01szGySGhgnx7WSJ6hDKb+yfHYtHACHcqoGDhX VFww== X-Gm-Message-State: AKGB3mIpy05A/xWul1gPolwxvBUtI/XWbefMqF66p1332s1tXkImDRRp j9C+Eik5qKGLg3gNk+DDrxHRPvjA4pfqhnQl0T1q X-Google-Smtp-Source: ACJfBouOyctL4sd/HIcz00JGN8Q4Pomr45h7EG0wR4sFrzthjWgDaZCVPFfpUOGuWUdxVia+7sCzGJvCGZ0T+sDXJEs= X-Received: by 10.200.51.46 with SMTP id t43mr19376917qta.75.1513291427024; Thu, 14 Dec 2017 14:43:47 -0800 (PST) MIME-Version: 1.0 References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171214214650.GA15254@LK-Perkele-VII> In-Reply-To: <20171214214650.GA15254@LK-Perkele-VII> From: David Benjamin Date: Thu, 14 Dec 2017 22:43:34 +0000 Message-ID: To: Ilari Liusvaara Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1138e872f3d23f0560549d6b" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 22:43:50 -0000 --001a1138e872f3d23f0560549d6b Content-Type: text/plain; charset="UTF-8" On Thu, Dec 14, 2017 at 4:47 PM Ilari Liusvaara wrote: > On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrote: > > On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev > wrote: > > > https://github.com/tlswg/certificate-compression/pull/8 > > > > That's a lot cleaner. Thanks. Some minor quibbles, but I like this > > construction far better. > > Yeah, same here, I like this construction far better than the -01 one. > > > A question about client certificates prior to TLS 1.3: Are we happy > > making compression for client certificates only available in TLS 1.3 > > (or higher if we can assume that we will maintain parity in future)? > > I think that I can live with that. > > As others have said, this extension is basically undeployable with > TLS 1.2 because middleboxes. > Another observation about the middlebox issue: if we leave the text as-is, where it is defined for TLS 1.2 server certificates, but we all silently agree that servers should decline it at TLS 1.2, clients are still obligated to implement it in their TLS 1.2 state machine because the advertisement is the same. If we're never going to deploy it in TLS 1.2 anyway, this seems like a waste of the complexity budget. Better to say it is not defined for TLS 1.2 at all because of non-compliant middleboxes and avoid all this ambiguity. > Also, assuming parity in the future might not be a good idea. Does > anyone have any idea what TLS 1.4 might be about[1] (TLS 2.0 would > likely be about cleaning representation, but that would likely be a > bad idea)? > > > [1] Not Post-Quantum Cryptography. Integrating PQC into TLS 1.3 is not > a difficult task (once you know the trick). And I do not see TLS > changes making it any easier without weakening security. > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1138e872f3d23f0560549d6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 14= , 2017 at 4:47 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrot= e:
> On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev <vasilvv@google.com> wrote: > > https://github.com/tlswg/certificat= e-compression/pull/8
>
> That's a lot cleaner.=C2=A0 Thanks.=C2=A0 Some minor quibbles, but= I like this
> construction far better.

Yeah, same here, I like this construction far better than the -01 one.

> A question about client certificates prior to TLS 1.3: Are we happy > making compression for client certificates only available in TLS 1.3 > (or higher if we can assume that we will maintain parity in future)? > I think that I can live with that.

As others have said, this extension is basically undeployable with
TLS 1.2 because middleboxes.

Another ob= servation about the middlebox issue: if we leave the text as-is, where it i= s defined for TLS 1.2 server certificates, but we all silently agree that s= ervers should decline it at TLS 1.2, clients are still obligated to impleme= nt it in their TLS 1.2 state machine because the advertisement is the same.=

If we're never going to deploy it in TLS 1.2 = anyway, this seems like a waste of the complexity budget. Better to say it = is not defined for TLS 1.2 at all because of non-compliant middleboxes and = avoid all this ambiguity.
=C2=A0
Also, assuming parity in the future might not be a good idea. Does
anyone have any idea what TLS 1.4 might be about[1] (TLS 2.0 would
likely be about cleaning representation, but that would likely be a
bad idea)?


[1] Not Post-Quantum Cryptography. Integrating PQC into TLS 1.3 is not
a difficult task (once you know the trick). And I do not see TLS
changes making it any easier without weakening security.



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1138e872f3d23f0560549d6b-- From nobody Thu Dec 14 14:59:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A877127005 for ; Thu, 14 Dec 2017 14:59:11 -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 gHPr0uDSEC_N for ; Thu, 14 Dec 2017 14:59:01 -0800 (PST) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::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 875971205F0 for ; Thu, 14 Dec 2017 14:59:01 -0800 (PST) Received: by mail-vk0-x243.google.com with SMTP id g69so1266454vkg.0 for ; Thu, 14 Dec 2017 14:59:01 -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=eB3dXO3QEDvUH2apXtpbNpvjEY81MonOUFkV0WhkVps=; b=jeLhMhFI949xQMBuKdewRTjJL7d8q6ANM6vk4h5v7dYMumqH9P2q6sH7IZTXKMBl6G vusXGjKVF7dH2/tDhWkV4xBNzI1yBAmoCtOZu9nXHpqVTucbgp8NclXD4tmJ/WFxEBU4 O7feasFtjuqeAQ+cCl5Bqatalt8BGiDKutqxwCEjfTTqrsvaQdMFL50uQ7dBGPTkr38g RbIPy435Uo6LPBIKbN6YgXo2ZDnMdkG4lonGZiAqP5CSBJNJLdDZeFiukb7Q6eWKxsIF XvHfY+wuuZWJWpDETDG38GT1RBH4fK+KIbhevZYvX9TQYsD1uaE+Uhp+DhEldXmK8Wp9 nPBA== 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=eB3dXO3QEDvUH2apXtpbNpvjEY81MonOUFkV0WhkVps=; b=rWhoYZZ7WEs5L8arPJOW3R+uFKmAtt7K/GWd28a0+BO4tz2HdVOcpTulw3DN1uFYIZ A5U/Bei+h4h2rImv56SPv/88oj8IxCWJjnE549yORl2Fsgp9jvWCMJIF8LIPs+9rOvqQ 6qriIvZsEzMZnKblrREsASNUwU0NH5rmLk/tzbCPZgAH//Kd19HMUKHP73AnN43IOaqp 6AagE0YX6y3j6T+TVCRokCEx5Mu0FjlJD07rMtl75u3FQ0yzuN00r1xDDEEisBBOYz9I o4mUusYUYOQFgjcwXMF3OxfGOYwpHYi6Bjyj0NWel6D3k9e4DLTw1MWQ3pHVLtaZMqoW BfeQ== X-Gm-Message-State: AKGB3mIQ9EkNZM4uF12MTFHjpJnE02D/qsKsfArsWRQRrdaRz4er3Nua 57q1gdBE0n7q13bK4Gp++EFa1Ir882h5bv08rTyh2g== X-Google-Smtp-Source: ACJfBotV9jW+NcyZNZr1OjauhCbRJwxWt3XSoWpd7RlayITmcAjp8SSz+xZhkknoAwel/R2U49PehgYtBDiIh67bNUs= X-Received: by 10.31.135.197 with SMTP id j188mr12194296vkd.34.1513292340395; Thu, 14 Dec 2017 14:59:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.41.164 with HTTP; Thu, 14 Dec 2017 14:58:59 -0800 (PST) In-Reply-To: References: From: Watson Ladd Date: Thu, 14 Dec 2017 14:58:59 -0800 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2017 22:59:11 -0000 Let's not forget defense 0: migrating away from broken algorithms (which means turning them off). The fact that we didn't switch MTI away from RSA encryption in TLS 1.1 after these attacks were disclosed, or even in TLS 1.2, means that we've got a very long time before some sites can turn off these algorithms. Given that some places can't turn off SSL v3, it's not clear we can ever turn off a widely implemented protocol. Sincerely, Watson Ladd From nobody Thu Dec 14 16:46: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 33473126C3D for ; Thu, 14 Dec 2017 16:46:00 -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=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTncS9jF-ri2 for ; Thu, 14 Dec 2017 16:45:58 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E7A1200F3 for ; Thu, 14 Dec 2017 16:45:58 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id z11so4946074ybm.1 for ; Thu, 14 Dec 2017 16:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jL79D8vsy2w9ljXAZSE4RqJbszIEOlQOkWqQljDQAMQ=; b=gMUt2t0uOTZy4w4ZZjytHL+Sloyz8QtPGkItlH1Q4zBBqAk9YWZ2kITM53dMAPRU7r /duuje9va21BMp//4Ts+zzTTwD3pvfH0lzrr/v/Dn3CpUMh521W8Jy94MlJ9fdmdEraR RCyP7/JMFNoKiHJ/RXLTd5yDcJT5v+VXD05Fvdrn7q2M6m3fFrElPgV10ECCexwD0cdy LV71LBgEpfIg5hvKjvlCO2MsuZ11h6g4xB3YBPCDBPTe6e11INNV3YcKB5W0ED/dfCNC Xvhqt6D2uRfQYnw7SJLZW1L2CGl8wKRZMIZIQt3NjVEQdTPgVEXLgdK0j8MOL3jWORGi HLsg== 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=jL79D8vsy2w9ljXAZSE4RqJbszIEOlQOkWqQljDQAMQ=; b=UvsNgr84kqQX5Oa5++Olw1q7/RTRGKiw1LUR+gw18uCCaKa6ZE5Dh5pGDfH0pOhP/1 62xzxZVM/PHDCyY33aT6kXiHXJPF5xtzOhSj0w0zn+m8mQcK58LDhtccvFHcfcd1f0+T 1/7i7QXwkzwtSF0zjDZ+YSFNaavXU5++ok+z0WLzfp0n2o0de2ktRTFGPiva1KIl6Zxq WDLypGFhkiRJkWvng1T5uIoe6v/NpC+h+qZefqdjMn5o5F527CBMr3JPRrmStfjy5h9W 5IRx6D2M0M+vq/2HW5u1brvZJYZK8ez6xFR3chY86hZHb2n8hD5n5FG8vJMcLeAz19bP v2DA== X-Gm-Message-State: AKGB3mJ/cYwXUQwwjFdjSybkAg42Y51f7BH4DHqlafPsLE1TJJ2GrApb zUMmnHBNMQXuLh+t6UifGSKwCOvq0HRFPNZ4CX+EoQ== X-Google-Smtp-Source: ACJfBosGyOFOt0UqhzmRA0QIl89G7h2qvcJ+M1rpbW7me+a6GtKi2MwAg8BVG7kSZA8coFZxcKc5JmYrOFuiVwmO1Lk= X-Received: by 10.37.89.68 with SMTP id n65mr5704610ybb.168.1513298757842; Thu, 14 Dec 2017 16:45:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.70 with HTTP; Thu, 14 Dec 2017 16:45:57 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 14 Dec 2017 16:45:57 -0800 Message-ID: To: Watson Ladd Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1140f874e688d205605652e9" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 00:46:00 -0000 --001a1140f874e688d205605652e9 Content-Type: text/plain; charset="UTF-8" Bringing this back to TLS-WG territory. Deprecating algorithms is hard work and can take a long time. Having been through MD5, RC4, 3DES, SHA1 deprecations and CBC de-prioritisations, it was a lot of work and network effects work against rapid changes. What else could we be doing here? One option might be to say that implementations should aways maintain at least two active algorithms for everything, both used with some frequency, and hence both likely to be optimized, the goal being to be able to turn off one at a moments notice with no availability or performance impact. But what would that look like? What would we do now, in advance, to make it easy to turn off AES? For example. On Thu, Dec 14, 2017 at 2:58 PM, Watson Ladd wrote: > Let's not forget defense 0: migrating away from broken algorithms > (which means turning them off). The fact that we didn't switch MTI > away from RSA encryption in TLS 1.1 after these attacks were > disclosed, or even in TLS 1.2, means that we've got a very long time > before some sites can turn off these algorithms. Given that some > places can't turn off SSL v3, it's not clear we can ever turn off a > widely implemented protocol. > > Sincerely, > Watson Ladd > -- Colm --001a1140f874e688d205605652e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bringing this back to TLS-WG territory. Dep= recating algorithms is hard work and can take a long time. Having been thro= ugh MD5, RC4, 3DES, SHA1 deprecations and CBC de-prioritisations, it was a = lot of work and network effects work against rapid changes.=C2=A0

<= /div>
What else could we be doing here? One option might be to say that= implementations should aways maintain at least two active algorithms for e= verything, both used with some frequency, and hence both likely to be optim= ized, the goal being to be able to turn off one at a moments notice with no= availability or performance impact.

But what woul= d that look like? What would we do now, in advance, to make it easy to turn= off AES? For example.=C2=A0

<= br>
On Thu, Dec 14, 2017 at 2:58 PM, Watson Ladd = <watsonbladd@gmail.com> wrote:
Let's not forget defense 0: migrating away from broken algorit= hms
(which means turning them off). The fact that we didn't switch MTI
away from RSA encryption in TLS 1.1 after these attacks were
disclosed, or even in TLS 1.2, means that we've got a very long time before some sites can turn off these algorithms. Given that some
places can't turn off SSL v3, it's not clear we can ever turn off a=
widely implemented protocol.

Sincerely,
Watson Ladd



--
Colm
--001a1140f874e688d205605652e9-- From nobody Thu Dec 14 17:01:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C761270AE for ; Thu, 14 Dec 2017 17:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFVZsL21e2Ji for ; Thu, 14 Dec 2017 17:01:21 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A7F126D85 for ; Thu, 14 Dec 2017 17:01:21 -0800 (PST) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 15 Dec 2017 02:01:27 +0100 id 000000000000007D.000000005A331EE7.00001800 Date: Fri, 15 Dec 2017 02:01:16 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20171215020116.04f9ae15@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 01:01:24 -0000 On Thu, 14 Dec 2017 16:45:57 -0800 Colm MacC=C3=A1rthaigh wrote: > But what would that look like? What would we do now, in advance, to > make it easy to turn off AES? For example. I think this is the wrong way to look at it. =46rom what I'm aware nobody is really concerned about the security of AES. I don't think that there's any need to prepare for turning off AES. The problem with PKCS #1 v1.5 is that it survived so long *after* its was known that it was bad. I really recommend everyone who wants to know how protocols go bad to read up on the Bleichenbacher countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last one. The chapter in 1.2 is a nightmare and I seriously fail to understand how anyone could have seen that and think it's a good idea to do that in order to stay compatible with a standard that was already deprecated at that point. We know that when this group decided to deprecate both PKCS #1 1.5 and RSA encryption that there were people trying to lobby against that. I'm glad that this wasn't successful. I think the takeaway is just as simple as this: If you know an algorithm is bad get rid of it and don't try to "rescue" it over into the next protocol. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Thu Dec 14 17:05: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 D6B5A126DFF for ; Thu, 14 Dec 2017 17:05:40 -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=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL19qLKKS2Vk for ; Thu, 14 Dec 2017 17:05:39 -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 2AFEB1200F3 for ; Thu, 14 Dec 2017 17:05:39 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id 69so4954453ybc.6 for ; Thu, 14 Dec 2017 17:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IjJcDs/Zgf0s4/2c0yX19oldStZzb0QLdHgwOc/sZOA=; b=WQldgwI6I3BBG1knr+C9yb6H7rKj9AgnIOjbvN8d2yTyKTqhPhW4MXwL3eoV2ATf9P TK96ROlzRaiFnyn6SbVqxr6LLd0mmRwnuFAmSFJW+rS2stqKWAcUiZ2EvSOmf0vVrY9k wfUmz8cmmMI8Oiu+O01isrklTb7eY1mp2bWM3wPxW2ktaTnW66+xagk8ZC1RMsxBewEL JxJV3Iz/6cqV4leEi7cIzFksACIh8fJNqJjjjAiEv7ja9+McA5Ot4SniYgpvsmtEwuRY IbPiMc+IZuILb8DcFr5OdrVaz3FyyIMQ7HnP3TQHqfVvkAkx3fDR3yvQ0n+S1kzGQSZd vljA== 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=IjJcDs/Zgf0s4/2c0yX19oldStZzb0QLdHgwOc/sZOA=; b=Nh6KQMDYV4zXtEAP0gYt6UuMxp60A/pVT5N+oJvgl3Na6mSGt3RR2xPQHumsHrymR3 rKPfDFt3bsosTKg0HNholfbjyNBgi4MTP0PLV77kYRge+mkCmDB1E349FvbyaxolRUot MJgH80B7ZhpGbfHgo18A1upKYwv2dr53NTqmjEij+XJqpDOFtWUqPH7bTDfnbbak+Hk2 zzSl+ITl8qlzv60qyfmpN7APBMnozxqsO6q5ERk9t+HzVb1kUcVROH/qDCWDa1BrA2CV e7um057j41dwhOHCp+2NxndYuXUyAy+1TcTNEXZlI2vR4Thjwtt3KP1LMQvbhVxrwjfs LFhg== X-Gm-Message-State: AKGB3mIt5u6RMjYCcTkhBR0xIGVtepdojbASA7NfcxgkrCq/T5aoWrFf e9QypSmqtON5kpVz5Mf8dGGlbd7CU3CbGEl77dw50w== X-Google-Smtp-Source: ACJfBosRGLwZvwmgt7Zc2pqSCbZzQRLLN+iM82R9gdCjxog1rx25j0Ar/Rgg4vUG9i5MJfYGJddNeScax61wYvnuTIY= X-Received: by 10.129.138.67 with SMTP id a64mr5853862ywg.35.1513299938369; Thu, 14 Dec 2017 17:05:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.70 with HTTP; Thu, 14 Dec 2017 17:05:37 -0800 (PST) In-Reply-To: <20171215020116.04f9ae15@pc1> References: <20171215020116.04f9ae15@pc1> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 14 Dec 2017 17:05:37 -0800 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1148a7a643fa3005605699c4" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 01:05:41 -0000 --001a1148a7a643fa3005605699c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2017 at 5:01 PM, Hanno B=C3=B6ck wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacC=C3=A1rthaigh wrote: > > > But what would that look like? What would we do now, in advance, to > > make it easy to turn off AES? For example. > > I think this is the wrong way to look at it. > > From what I'm aware nobody is really concerned about the security of > AES. I don't think that there's any need to prepare for turning off AES. > Well, DJB is a notable concerned critic of AES and its safety in some respects ... but I was using AES as kind of a worst-case scenario since so many things do depend on it and it's especially hard to leave. I'm not aware of some ground-breaking cryptanalysis :) But I do think the question is worth having an answer for. I think we *do* need to prepare for turning off AES, there's always a chance we might have to. --=20 Colm --001a1148a7a643fa3005605699c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 14, 2017 at 5:01 PM, Hanno B=C3=B6ck <= hanno@hboeck.de>= ; wrote:
On Thu, = 14 Dec 2017 16:45:57 -0800
Colm MacC=C3=A1rthaigh <colm@allcos= ts.net> wrote:

> But what would that look like? What would we do now, in advance, to > make it easy to turn off AES? For example.

I think this is the wrong way to look at it.

>From what I'm aware nobody is really concerned about the security of AES. I don't think that there's any need to prepare for turning off= AES.

Well, DJB is a notable concerned = critic of AES and its safety in some respects ... but I was using AES as ki= nd of a worst-case scenario since so many things do depend on it and it'= ;s especially hard to leave. I'm not aware of some ground-breaking cryp= tanalysis :) But I do think the question is worth having an answer for. I t= hink we *do* need to prepare for turning off AES, there's always a chan= ce we might have to.=C2=A0

--
Colm
--001a1148a7a643fa3005605699c4-- From nobody Thu Dec 14 20:51:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91185126FB3 for ; Thu, 14 Dec 2017 20:50:58 -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, 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 mcjyavfETz1A for ; Thu, 14 Dec 2017 20:50:56 -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 3303C126C22 for ; Thu, 14 Dec 2017 20:50:56 -0800 (PST) Received: by mail-wr0-x241.google.com with SMTP id z34so6961836wrz.10 for ; Thu, 14 Dec 2017 20:50:56 -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=U47s6t0m+CFNrqF6Li0btdNxlJ/A7buo0hVgSqREv58=; b=amLImGF1SV37GJMWMeo5U3ZPZFl8hinJH5HKsTjtkqnumRyI4OKmDwYU/Ylsm2fMRM 9I+SlIty1sUdI0r9Ne3W+jXdraa+h8TNL4n1kOaOs4PHsax3nMosXh53lWdA2p0IFScw xdtZTUyhs2Q4mARbjIvPJz6Ft4+qpsOFGJPmlGHlf40BBdCrIwymfnD8fxAvBnuAwP9c +gkz4UaIIG3ssP0QveHhDYIVD+l6W27OufjVLlaxTX6QbGTTVs4Iqk2xFyfZHIs8/VHK 41fZdgXOFSPJf0dby7Ewaep+D5Mpnt/BsKNMMqGXLVefBDM3TZOW0yzCjL60Jme72Tuf RfJw== 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=U47s6t0m+CFNrqF6Li0btdNxlJ/A7buo0hVgSqREv58=; b=I/UrNsdy350bOHl9hP6Xf6QqpyOXAKkyNRZ7pPWW6Uck3bV2PTkO4VI3B8q6GGUWBQ rGa3INNG4zFS4YpgpcJ+HQBHg+xccfFNORRdddR9qXSc6BMGJu/YmLsafhOneTKLFe5g HHsZ+fJuahFJtVFs+C/dwMXTHX93Sau8jriv8jeavoJqmRvQCcRhOjCkXPSlR/6TngmJ xOSl/7El90WTYuE9pUIN3J8a0XA7OxlL2ZT+GoLJd1X7jtJ15RzMXFmzi/6p3zz7IMKx d/ZV4Na8pXIGc03xwe2L7gpk1AQicmFpu0m3GLkERlmxaSFKgDMetsQmNQhqho3cnMpJ yr7g== X-Gm-Message-State: AKGB3mLsdOYTFnzp1tNlfmvO1qCjn41fozUuCMjtvtxpIM+Wjm4J1VLk 9IahMGLuFP9foNMDQr8chSh1Ui8o X-Google-Smtp-Source: ACJfBotUuTNoRNz2KyH77vwJhKRxi8Mga93QvbVXsA6gDhZd6xotq9yoVHB/1EaGZF0tH9dninr69Q== X-Received: by 10.223.143.50 with SMTP id p47mr7875365wrb.104.1513313454700; Thu, 14 Dec 2017 20:50:54 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i65sm18873642wme.20.2017.12.14.20.50.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 20:50:53 -0800 (PST) From: Yoav Nir Message-Id: <14591ED5-4238-4578-9D31-899E713C425B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_10D9055E-1371-4105-B31D-A1E86E3C5355"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 15 Dec 2017 06:50:50 +0200 In-Reply-To: Cc: =?utf-8?Q?Hanno_B=C3=B6ck?= , "tls@ietf.org" To: =?utf-8?Q?Colm_MacC=C3=A1rthaigh?= References: <20171215020116.04f9ae15@pc1> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 04:50:58 -0000 --Apple-Mail=_10D9055E-1371-4105-B31D-A1E86E3C5355 Content-Type: multipart/alternative; boundary="Apple-Mail=_20C9F20F-0B3C-4EB1-B60C-F9E8123AC72E" --Apple-Mail=_20C9F20F-0B3C-4EB1-B60C-F9E8123AC72E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Dec 2017, at 3:05, Colm MacC=C3=A1rthaigh = wrote: >=20 >=20 >=20 > On Thu, Dec 14, 2017 at 5:01 PM, Hanno B=C3=B6ck > wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacC=C3=A1rthaigh > = wrote: >=20 > > But what would that look like? What would we do now, in advance, to > > make it easy to turn off AES? For example. >=20 > I think this is the wrong way to look at it. >=20 > >=46rom what I'm aware nobody is really concerned about the security = of > AES. I don't think that there's any need to prepare for turning off = AES. >=20 > Well, DJB is a notable concerned critic of AES and its safety in some = respects ... but I was using AES as kind of a worst-case scenario since = so many things do depend on it and it's especially hard to leave. I'm = not aware of some ground-breaking cryptanalysis :) But I do think the = question is worth having an answer for. I think we *do* need to prepare = for turning off AES, there's always a chance we might have to. I think that was the point of standardizing ChaCha20-Poly1305. In fact, = that=E2=80=99s what is says in the second paragraph of the introduction = in RFC 7539: https://tools.ietf.org/html/rfc7539#section-1 = Yoav --Apple-Mail=_20C9F20F-0B3C-4EB1-B60C-F9E8123AC72E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 15 Dec 2017, at 3:05, Colm MacC=C3=A1rthaigh <colm@allcosts.net> = wrote:



On Thu, Dec 14, 2017 at 5:01 PM, = Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
On Thu, 14 Dec 2017 16:45:57 = -0800
Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:

> But what would that look like? What would we do now, in advance, = to
> make it easy to turn off AES? For example.

I think this is the wrong way to look at it.

>=46rom what I'm aware nobody is really concerned about the security = of
AES. I don't think that there's any need to prepare for turning off = AES.

Well, DJB is a notable concerned critic of AES and its safety = in some respects ... but I was using AES as kind of a worst-case = scenario since so many things do depend on it and it's especially hard = to leave. I'm not aware of some ground-breaking cryptanalysis :) But I = do think the question is worth having an answer for. I think we *do* = need to prepare for turning off AES, there's always a chance we might = have to. 

I think that was the point of standardizing = ChaCha20-Poly1305.  In fact, that=E2=80=99s what is says in the = second paragraph of the introduction in RFC 7539:

Yoav
= --Apple-Mail=_20C9F20F-0B3C-4EB1-B60C-F9E8123AC72E-- --Apple-Mail=_10D9055E-1371-4105-B31D-A1E86E3C5355 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlozVKoACgkQuEkLFQpY zJmxnwgAyymElbFAss+TcHp96wwbNDB90u0dMbHyzASBQnIuwPn1asxGUCywUQfv b/Yv8xFx/XtxNELv3Vt7uj7T9Zc4TXpUiGR6nnbokjyX/Pmo9+eYoUyaYqAjRxy6 8RoE6h6oMYYsfAnFR9C5FZtsFYP60h2WYDZl3WjV4HCMY4nXaH4D78MBDvnPmoe6 OhbEjQciOmtbRrDijyM4wZSrw75cSYpCChR/DDYg/X0ucafD5jQ/BY7UXe9a+nZS G8LAkdx4hnnX0XBiT+g270ccEoCKTnNw64f0Xe92OWWZ5KPLslY8QEdO+0VxX7QS RDZQLeZMcoXLGmsivKBlBrJRsCAz0w== =KZx3 -----END PGP SIGNATURE----- --Apple-Mail=_10D9055E-1371-4105-B31D-A1E86E3C5355-- From nobody Fri Dec 15 06:20: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 4C437128B93 for ; Fri, 15 Dec 2017 06:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 SZsIfPy5zu9M for ; Fri, 15 Dec 2017 06:19:59 -0800 (PST) Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39062128C9C for ; Fri, 15 Dec 2017 06:19:59 -0800 (PST) Received: by mail-wr0-f171.google.com with SMTP id o2so8183426wro.5 for ; Fri, 15 Dec 2017 06:19:59 -0800 (PST) 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=7Y0GS7yn5pc4N4DQv2cFajHpXZSvcKz/5ETrFM0KFmc=; b=b8vR/6vDqMQ4HuUzqWAdY2HQv402v5kCA8Ik7AB+4XjIKN7JaL4mdNZNiXvR805Ppu SXPX6ElffaM0l5rb22Z/cUXyXhXkRrsDwZ1Z5IUfQgUaR0MoOQxhfuJ/uDUm6oPXxf+k Xf6jg/Hj+mBacz3JpEnE/Ur34o23O1fQROQF+Olse3JoOxYWQ3pxB01OolTwIgUjwqDA mbijxGKoWVzD016psv4SpxfM5HXP68+//IlRFUnTkHd5ogQP3+9zG95yoGXkDr70sAzj W4UscSqdfIE4xn/J47ETPovv7ST45Ts94O3p6WvkwNF3UCUCAIjuNIXjJp/OnIf1zmef UpKg== X-Gm-Message-State: AKGB3mLsv11TNBLmFC7uVTOzjnhC7aFOVDLhOvG1/lv71J+TEKnFUTxk 3IHDucpFXke9tGhgZtKJ3Oj7T24SMP5yJAygxGAbow== X-Google-Smtp-Source: ACJfBosC6ImMxClwvCoAfbMj1DwnFUIboBCMwbhBPQyIttB7PrVYtrU098XQDNE1kOUsQp+FDFwU/4IUpL4zknS3qjo= X-Received: by 10.223.154.19 with SMTP id z19mr1610430wrb.260.1513347597647; Fri, 15 Dec 2017 06:19:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.19.2 with HTTP; Fri, 15 Dec 2017 06:19:56 -0800 (PST) In-Reply-To: <20171215020116.04f9ae15@pc1> References: <20171215020116.04f9ae15@pc1> From: Nikos Mavrogiannopoulos Date: Fri, 15 Dec 2017 15:19:56 +0100 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="f403045f54acfad5ba056061b145" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 14:20:04 -0000 --f403045f54acfad5ba056061b145 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 15, 2017 at 2:01 AM, Hanno B=C3=B6ck wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacC=C3=A1rthaigh wrote: > > > But what would that look like? What would we do now, in advance, to > > make it easy to turn off AES? For example. > > I think this is the wrong way to look at it. > > From what I'm aware nobody is really concerned about the security of > AES. I don't think that there's any need to prepare for turning off AES. > > The problem with PKCS #1 v1.5 is that it survived so long *after* its > was known that it was bad. I really recommend everyone who wants to > know how protocols go bad to read up on the Bleichenbacher > countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last > one. The chapter in 1.2 is a nightmare and I seriously fail to > understand how anyone could have seen that and think it's a good idea > to do that in order to stay compatible with a standard that was already > deprecated at that point. > > We know that when this group decided to deprecate both PKCS #1 1.5 and > RSA encryption that there were people trying to lobby against that. I'm > glad that this wasn't successful. > RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact the security of TLS 1.3 is heavily tied to these primitives if servers support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice if we can only deprecate RSA PKCS#1 1.5 at some point. regards, Nikos [0]. https://github.com/tlswg/tls13-spec/pull/1123 --f403045f54acfad5ba056061b145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 15, 2017 at 2:01 AM, Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
On Thu, 14 Dec 2017 16:45:57 -0800
Colm MacC=C3=A1rthaigh <colm@allcos= ts.net> wrote:

> But what would that look like? What would we do now, in advance, to > make it easy to turn off AES? For example.

I think this is the wrong way to look at it.

>From what I'm aware nobody is really concerned about the security of AES. I don't think that there's any need to prepare for turning off= AES.

The problem with PKCS #1 v1.5 is that it survived so long *after* its
was known that it was bad. I really recommend everyone who wants to
know how protocols go bad to read up on the Bleichenbacher
countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last
one. The chapter in 1.2 is a nightmare and I seriously fail to
understand how anyone could have seen that and think it's a good idea to do that in order to stay compatible with a standard that was already
deprecated at that point.

We know that when this group decided to deprecate both PKCS #1 1.5 and
RSA encryption that there were people trying to lobby against that. I'm=
glad that this wasn't successful.

R= SA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact t= he security of TLS 1.3 is heavily tied to these primitives if servers suppo= rt TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice if we= can only deprecate RSA PKCS#1 1.5 at some point.

regards= ,

--f403045f54acfad5ba056061b145-- From nobody Fri Dec 15 06:31: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 3F652124205 for ; Fri, 15 Dec 2017 06:31:06 -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] 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 dBJ76IlIc09K for ; Fri, 15 Dec 2017 06:31:04 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A481250B8 for ; Fri, 15 Dec 2017 06:31:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2ABA897B72; Fri, 15 Dec 2017 16:31:01 +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 WpEs0_n7_HP4; Fri, 15 Dec 2017 16:31:00 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D349672; Fri, 15 Dec 2017 16:30:57 +0200 (EET) Date: Fri, 15 Dec 2017 16:30:57 +0200 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Cc: Hanno =?utf-8?B?QsO2Y2s=?= , "tls@ietf.org" Message-ID: <20171215143057.GA17121@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> 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.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 14:31:06 -0000 On Thu, Dec 14, 2017 at 05:05:37PM -0800, Colm MacCárthaigh wrote: > But I do think the question > is worth having an answer for. I think we *do* need to prepare for turning > off AES, there's always a chance we might have to. Even nastier dependency: SHA-2. If that breaks, currently both TLS 1.2 and 1.3 break. There are no alternatives defined. Yes, sure SHA-2 has taken a lot of cryptoanalysis without serious trouble (I think one reason for starting SHA-3 process was preceived weakness in SHA-2, that later turned out not to be the case). -Ilari From nobody Fri Dec 15 06:46:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7AE126E01 for ; Fri, 15 Dec 2017 06:46: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 CFgVxWMtpqMD for ; Fri, 15 Dec 2017 06:46:25 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB205124205 for ; Fri, 15 Dec 2017 06:46:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C9EF35371D; Fri, 15 Dec 2017 16:46:22 +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 Etlz5x8O1kEk; Fri, 15 Dec 2017 16:46:22 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 71424286; Fri, 15 Dec 2017 16:46:19 +0200 (EET) Date: Fri, 15 Dec 2017 16:46:19 +0200 From: Ilari Liusvaara To: Watson Ladd Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" Message-ID: <20171215144619.GB17121@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 14:46:27 -0000 On Thu, Dec 14, 2017 at 02:58:59PM -0800, Watson Ladd wrote: > Let's not forget defense 0: migrating away from broken algorithms > (which means turning them off). The fact that we didn't switch MTI > away from RSA encryption in TLS 1.1 after these attacks were > disclosed, or even in TLS 1.2, means that we've got a very long time > before some sites can turn off these algorithms. Given that some > places can't turn off SSL v3, it's not clear we can ever turn off a > widely implemented protocol. I think the main problem in way of just deleting static RSA code is those "visibility" folks. Because vast majority of clients that are not utter garbage for other reasons support PFS with decent key sizes. (And then there are folks that interpret MTI in insane ways). -Ilari From nobody Fri Dec 15 06:57: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 82FC2128B93 for ; Fri, 15 Dec 2017 06:57: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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 lGJEzKKpx2U8 for ; Fri, 15 Dec 2017 06:57:37 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0118.outbound.protection.outlook.com [104.47.36.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F9B120721 for ; Fri, 15 Dec 2017 06:57: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=b1leLPKPvyTKwz1jdPpk1wJpWxbtMrNAqIQVIwPQUgA=; b=Rj9my1C2i54vdmvDNLZWe296CInFeYCqhB5gUCHo0qv3hGophau/WTPHcwfsH5Ox15/4FXonOFhOLJ+DjjUg5BWkq17Mqa10FkCKGY9GlI+YROS7PBZ+pFk2iESUI84NHZN5P4cZzglUvSXjyPM5GRn4+gKJ8Z38i9slqTC4BG0= Received: from MWHPR21MB0189.namprd21.prod.outlook.com (10.173.52.135) by MWHPR21MB0479.namprd21.prod.outlook.com (10.172.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.2; Fri, 15 Dec 2017 14:57:34 +0000 Received: from MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) by MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) with mapi id 15.20.0345.002; Fri, 15 Dec 2017 14:57:34 +0000 From: Andrei Popov To: Ilari Liusvaara , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= CC: "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSqavAlrna8BzEyYxpCWE2aK26NDc+uAgAAd44CAAARHAIAAATeAgADhAoCAAAcvAA== Date: Fri, 15 Dec 2017 14:57:33 +0000 Message-ID: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> In-Reply-To: <20171215143057.GA17121@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=andreipo@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-12-15T14:57:50.0660470Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [50.47.136.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0479; 6:dXLMyFUx1PyNyULvTGsGlejUxb0EzWNZioGgebhBIGAVPEIZ8N8p0OfV+V8O0ehQMQ1lAc/HdOI7ef0zHZko6wrc+DKMFTlh0zHhnvGCQ0uFL6YDuGyd+c5h5TB5ZYxctlCdOy+waR3GzZSFFwa6T1sqaQZCL7juhBNMOCPjqPwbTw1XqK7ytSqcDO1Si6fyluyoT7b766UaJ+m8HjU+0blavet2vHalDXPvYVYE8qhgBlNRGW5u28HUHAwqhbV92UjFjiVOwbKbuo6CRQ2ql1IUyvr9G9KAumGtOANwgcdfPapgafpdKN+GFtjX5m0SdSgckAGMnpVM8w7uHTw+tK5N/y4PO7Z6WG2s5VE9qoE=; 5:QY+ReArpCXFWXTcLGdq9eKbnvPMBR5B6kO2LCuIpzvaJameQohELAz+u8TsmQc6jRel3+21O6408DQOKkudpCcYcxuGnwE0hc0eiBizA/EO/xXQMGqAlDkdws39sHDlw19ZQn9eyJPUzTmBgOHFrh+4eTh1eLFMtRwzyUvjgQ44=; 24:DRs1PFNVKWoYnUdGl4jTj6SOL2vmqnxmyio5vEMFgeLQYLOLshOC63mdC23ACtA2w46B1KvnrMvicgBUSueya2rvRA0q3s1FYIVmuM/Q5Yg=; 7:GvHAz0H9mH3AQiw9609s5th26qlR+LapMFQ2m1Xt0Rm6iQLDqeLVgRgLDdvLqjICIwgXyNlTcUv66FDJ3GUrrmw37Yh0VZr81N1y1395JwM10mMp9MaBFl5LBQ85rzeTy9BjluXcjl/xWTAFEHTDkMDttlNPOjhr1RNZ+jAsJLRXdMrTXnnTIyk/b9lSA425TSFKrDhuPz6yvLJ7FBrB2hZDjtdFVrOHA6pwQrWhtZApJY4+lXOHx+jgAcKYnVfj x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 075ff05d-a822-40af-a48b-08d543cc2c6f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:MWHPR21MB0479; x-ms-traffictypediagnostic: MWHPR21MB0479: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231023)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:MWHPR21MB0479; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR21MB0479; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(396003)(376002)(13464003)(24454002)(199004)(189003)(86612001)(3280700002)(99286004)(5660300001)(7696005)(105586002)(66066001)(2900100001)(10090500001)(106356001)(53546011)(102836003)(3846002)(2950100002)(6306002)(3660700001)(9686003)(2906002)(8936002)(6506007)(110136005)(68736007)(22452003)(93886005)(6116002)(316002)(76176011)(8990500004)(55016002)(229853002)(33656002)(6436002)(72206003)(77096006)(25786009)(6246003)(81166006)(8676002)(10290500003)(478600001)(14454004)(97736004)(575784001)(86362001)(4326008)(305945005)(966005)(7736002)(74316002)(81156014)(53936002)(29543002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0479; H:MWHPR21MB0189.namprd21.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 075ff05d-a822-40af-a48b-08d543cc2c6f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 14:57:33.9759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0479 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 14:57:39 -0000 SGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lIGEgU0hBLTIgYWx0ZXJuYXRpdmU6IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13Y29ubmVyLWJsYWtlMnNpZ3MtMDENCg0KQ2hlZXJz LA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRMUyBbbWFp bHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWxhcmkgTGl1c3ZhYXJhDQpT ZW50OiBGcmlkYXksIERlY2VtYmVyIDE1LCAyMDE3IDY6MzEgQU0NClRvOiBDb2xtIE1hY0PDoXJ0 aGFpZ2ggPGNvbG1AYWxsY29zdHMubmV0Pg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtUTFNdIEEgY2xvc2VyIGxvb2sgYXQgUk9CT1QsIEJCIEF0dGFja3MsIHRpbWluZyBhdHRhY2tz IGluIGdlbmVyYWwsIGFuZCB3aGF0IHdlIGNhbiBkbyBpbiBUTFMNCg0KT24gVGh1LCBEZWMgMTQs IDIwMTcgYXQgMDU6MDU6MzdQTSAtMDgwMCwgQ29sbSBNYWNDw6FydGhhaWdoIHdyb3RlOg0KDQo+ IEJ1dCBJIGRvIHRoaW5rIHRoZSBxdWVzdGlvbg0KPiBpcyB3b3J0aCBoYXZpbmcgYW4gYW5zd2Vy IGZvci4gSSB0aGluayB3ZSAqZG8qIG5lZWQgdG8gcHJlcGFyZSBmb3IgDQo+IHR1cm5pbmcgb2Zm IEFFUywgdGhlcmUncyBhbHdheXMgYSBjaGFuY2Ugd2UgbWlnaHQgaGF2ZSB0by4NCg0KRXZlbiBu YXN0aWVyIGRlcGVuZGVuY3k6IFNIQS0yLiBJZiB0aGF0IGJyZWFrcywgY3VycmVudGx5IGJvdGgg VExTIDEuMiBhbmQgMS4zIGJyZWFrLiBUaGVyZSBhcmUgbm8gYWx0ZXJuYXRpdmVzIGRlZmluZWQu DQoNClllcywgc3VyZSBTSEEtMiBoYXMgdGFrZW4gYSBsb3Qgb2YgY3J5cHRvYW5hbHlzaXMgd2l0 aG91dCBzZXJpb3VzIHRyb3VibGUgKEkgdGhpbmsgb25lIHJlYXNvbiBmb3Igc3RhcnRpbmcgU0hB LTMgcHJvY2VzcyB3YXMgcHJlY2VpdmVkIHdlYWtuZXNzIGluIFNIQS0yLCB0aGF0IGxhdGVyIHR1 cm5lZCBvdXQgbm90IHRvIGJlIHRoZSBjYXNlKS4gDQoNCg0KLUlsYXJpDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpU TFNAaWV0Zi5vcmcNCmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG dGxzJmRhdGE9MDQlN0MwMSU3Q0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0MyMjc3OWY5 YTM4ODM0NzgxOTI4MjA4ZDU0M2M4N2Y5NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY0ODk0NTA4MDUwMTA1MDMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aWZRJTNE JTNEJTdDLTEmc2RhdGE9eVZIc0YwMjFBR3RYR1IwRERwbTJtVjA3Z3NDVGhQamslMkJHc0RtOFI0 VXlFJTNEJnJlc2VydmVkPTANCg== From nobody Fri Dec 15 08:48: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 51B84126CF9 for ; Fri, 15 Dec 2017 08:48:37 -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 gYadnedLdHSA for ; Fri, 15 Dec 2017 08:48:35 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 2C9F7120227 for ; Fri, 15 Dec 2017 08:48:35 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id p84so6531072pfd.3 for ; Fri, 15 Dec 2017 08:48:35 -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=gDivDt9TmeaOWW5lt0SMPUqINt27U463P5wI9oaAIO4=; b=kjYSq/7nRz1ew5rNJ/1rjjp+pZU3VTexeDDK04rBkPxpPr1ssPvNVVnRL4hwCpTgN1 OQ+0BErSYz93p35vMWfmEwN7UDQ62Ld9Sjl0aZ4jq/6X4a1/utnsK9LNu/ZpAfUAU3jC ofyZ5O0Qb08GOrNicl50EkR5YKr3AUeMr6dyX4hr7woqM6kZCmpUwxk5jhEZwO8PKDDP /WjK3HPWqm1w7XjCUWkm5T3FBwjUJ54tIl/Ookljq1EbVAPwQOrGmWl5RtCoGtqoPeOL jM5x5mJbgSG0/9p1aHZusEz1QzORB8Y9G9lbTVha/vkQh67br9LljQHuS6Sels3JIqwB fFqg== 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=gDivDt9TmeaOWW5lt0SMPUqINt27U463P5wI9oaAIO4=; b=OQ4do1flCZtPUQ4zAg77KwaYrL84d91xSOifxjNeE3gP7jhRl/dEJ6vzUQ8ivXVN91 vISv87bDc06CJ78s4kDr6/I0w5nAFArQVyEIsAvNCY74XP3NCVtX2ZTqyO81S2VHWkqS uv5xGLuOXlCi6xmVPJ8N7ZEK3hrojdTfA2IY4tv8vItx15Q/9qFtz19qM8kpfUqEj655 Mfhmj/nSvVchGXOsqZavwLEyqpX9NGhszZybe3Qx9vXiXqylY7veyHSkNV5HM+58RZyO Yk8FLSbrQ08sR4nWt/EfQVojfvE79OqX15sC8QQfmjxHPox3PCnd3nFUP+TxCk6CFmeY ib+A== X-Gm-Message-State: AKGB3mJcleXnhSOnIijRxnkSX3DsZ7pFrTvHN/TyoQTcSsj8EkAycuRa JqNfUqXhDimiC6/ZT7jd6eHSJTsdPngcVmYkaezALw== X-Google-Smtp-Source: ACJfBosPuGlaZkXeJPmCO4SeCdVdILcBrk6UKqPWa03AwPVq8zBY8NnVXzO09/5QJYILh6b4tkg+bMd7mc4BHfesV74= X-Received: by 10.159.241.20 with SMTP id q20mr13713953plr.225.1513356514754; Fri, 15 Dec 2017 08:48:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Fri, 15 Dec 2017 08:47:54 -0800 (PST) In-Reply-To: References: <20171215020116.04f9ae15@pc1> From: Kathleen Moriarty Date: Fri, 15 Dec 2017 11:47:54 -0500 Message-ID: To: Nikos Mavrogiannopoulos Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 16:48:37 -0000 On Fri, Dec 15, 2017 at 9:19 AM, Nikos Mavrogiannopoulos wrote: > On Fri, Dec 15, 2017 at 2:01 AM, Hanno B=C3=B6ck wrote: >> >> On Thu, 14 Dec 2017 16:45:57 -0800 >> Colm MacC=C3=A1rthaigh wrote: >> >> > But what would that look like? What would we do now, in advance, to >> > make it easy to turn off AES? For example. >> >> I think this is the wrong way to look at it. >> >> >From what I'm aware nobody is really concerned about the security of >> AES. I don't think that there's any need to prepare for turning off AES. >> >> The problem with PKCS #1 v1.5 is that it survived so long *after* its >> was known that it was bad. I really recommend everyone who wants to >> know how protocols go bad to read up on the Bleichenbacher >> countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last >> one. The chapter in 1.2 is a nightmare and I seriously fail to >> understand how anyone could have seen that and think it's a good idea >> to do that in order to stay compatible with a standard that was already >> deprecated at that point. >> >> We know that when this group decided to deprecate both PKCS #1 1.5 and >> RSA encryption that there were people trying to lobby against that. I'm >> glad that this wasn't successful. > > > RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fac= t > the security of TLS 1.3 is heavily tied to these primitives if servers > support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nic= e > if we can only deprecate RSA PKCS#1 1.5 at some point. Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS 1.2 and prior? I haven't noticed any discussion on that previously. Is it just the code base and not those using it being unwilling to upgrade supporting libraries? >From RFC8017: To avoid implementation weaknesses related to the way errors are handled within the decoding operation (see [BLEICHENBACHER] and [MANGER]), the encoding and decoding operations for RSAES-OAEP and RSAES-PKCS1-v1_5 are embedded in the specifications of the respective encryption schemes rather than defined in separate specifications. Both encryption schemes are compatible with the corresponding schemes in PKCS #1 v2.1. And, yes, I know deprecation is very hard, but if there's been no effort, it should be considered as TLS 1.2 isn't going away anytime soon. Thanks, Kathleen > > regards, > Nikos > > [0]. https://github.com/tlswg/tls13-spec/pull/1123 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen From nobody Fri Dec 15 08:57: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 322A8129407 for ; Fri, 15 Dec 2017 08:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nFXJ3Z13Fgl for ; Fri, 15 Dec 2017 08:57:54 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12808129400 for ; Fri, 15 Dec 2017 08:57:53 -0800 (PST) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 15 Dec 2017 17:58:01 +0100 id 000000000000001F.000000005A33FF19.000052F1 Date: Fri, 15 Dec 2017 17:57:48 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Kathleen Moriarty Cc: Nikos Mavrogiannopoulos , "" Message-ID: <20171215175748.4e54ace8@pc1> In-Reply-To: References: <20171215020116.04f9ae15@pc1> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 16:57:57 -0000 On Fri, 15 Dec 2017 11:47:54 -0500 Kathleen Moriarty wrote: > Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS > 1.2 and prior? I haven't noticed any discussion on that previously. Is > it just the code base and not those using it being unwilling to > upgrade supporting libraries? It depends... particularly if we talk about encryption or signatures. With Bleichenbacher attacks there are plenty of cross-protocol attack possibilities, this was one of the papers at the TRON workshop: https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAt= tacks.pdf While I believe we certainly can't get rid of PKCS #1 1.5 signatures any time soon, I think we can get rid of PKCS #1 1.5 encryption (at least on the server side for HTTPS). The number of legit connections is really low. If you run servers please check if you can do that. (I'm also considering writing an RSA-kex-diediedie RFC when I find time for it.) --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Fri Dec 15 09: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 1D33B1200CF for ; Fri, 15 Dec 2017 09:02:28 -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] 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 NJE9-RStNiGK for ; Fri, 15 Dec 2017 09:02:24 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F6B127241 for ; Fri, 15 Dec 2017 09:02:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 1A12397B65; Fri, 15 Dec 2017 19:02:23 +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 LNfA0KVaQFyM; Fri, 15 Dec 2017 19:02:22 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BAFB727F; Fri, 15 Dec 2017 19:02:19 +0200 (EET) Date: Fri, 15 Dec 2017 19:02:19 +0200 From: Ilari Liusvaara To: Kathleen Moriarty Cc: Nikos Mavrogiannopoulos , "" Message-ID: <20171215170219.GA17423@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 17:02:28 -0000 On Fri, Dec 15, 2017 at 11:47:54AM -0500, Kathleen Moriarty wrote: > > Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS > 1.2 and prior? I haven't noticed any discussion on that previously. Is > it just the code base and not those using it being unwilling to > upgrade supporting libraries? > > >From RFC8017: > > To avoid implementation weaknesses related to the way errors are > handled within the decoding operation (see [BLEICHENBACHER] and > [MANGER]), the encoding and decoding operations for RSAES-OAEP and > RSAES-PKCS1-v1_5 are embedded in the specifications of the respective > encryption schemes rather than defined in separate specifications. > Both encryption schemes are compatible with the corresponding schemes > in PKCS #1 v2.1. > > And, yes, I know deprecation is very hard, but if there's been no > effort, it should be considered as TLS 1.2 isn't going away anytime > soon. The problem is that handling a decryption fault in TLS 1.2 and prior is hard. The TLS 1.2 RFC already discusses how to do that. Basically, if decryption fails, you need to carry on as nothing had happened, but then cause Finished MAC check to fail. In _constant_ time. Which is not easy, and even if your code looks constant time, compiler "optimizations" can really ruin your day. I think there should be a draft which formally deprecates RSA, recommends the support to be removed (at least from server side) and updates TLS 1.2 to change the MTI ciphersuite. Of course, certain ("visibility") folks would scream about that. -Ilari From nobody Fri Dec 15 09:46: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 51945127522 for ; Fri, 15 Dec 2017 09:46:37 -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] 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 rJgwp9aLrO90 for ; Fri, 15 Dec 2017 09:46:35 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0C41273B1 for ; Fri, 15 Dec 2017 09:46:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id AB8AAB51E5; Fri, 15 Dec 2017 19:46:32 +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 6j54J1pXJKaD; Fri, 15 Dec 2017 19:46:32 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E8C99C4; Fri, 15 Dec 2017 19:46:28 +0200 (EET) Date: Fri, 15 Dec 2017 19:46:28 +0200 From: Ilari Liusvaara To: Andrei Popov Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" Message-ID: <20171215174628.GA17601@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 17:46:37 -0000 On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote: > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > > Even nastier dependency: SHA-2. If that breaks, currently both TLS > > 1.2 and 1.3 break. There are no alternatives defined. > > Here's an attempt to define a SHA-2 alternative: https://tools.ietf.org/html/draft-wconner-blake2sigs-01 Also would need TLS ciphersuite codepoints with alternative handshake hash algorithms. -Ilari From nobody Fri Dec 15 10:03: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 6D5B91273B1 for ; Fri, 15 Dec 2017 10:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_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 ZNhzXrrmJo8n for ; Fri, 15 Dec 2017 10:03:49 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0099.outbound.protection.outlook.com [104.47.37.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 3E9B9126CC7 for ; Fri, 15 Dec 2017 10:03:49 -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=HnBRHlm8ZDTFVQS11kVQkYG9gQtmUfmi6v+gHJEaitc=; b=SmRJOBfzAlhI8YnZy+9WgWfAO2PQrWnf+O8McxZv5hK/ctcrJCcAxDgUgjST2MmzoZaT9hcJZMnHzGrjsp6WVBVMeHrrTsKUHLrYJFfckm4QSltbXndjvyhql51JaKkuHepmYu42i9FyKROuAYVBBOdv0XrZXGsxU6WDcrKjMmc= Received: from MWHPR21MB0189.namprd21.prod.outlook.com (10.173.52.135) by MWHPR21MB0189.namprd21.prod.outlook.com (10.173.52.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.2; Fri, 15 Dec 2017 18:03:47 +0000 Received: from MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) by MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) with mapi id 15.20.0345.002; Fri, 15 Dec 2017 18:03:47 +0000 From: Andrei Popov To: "ilariliusvaara@welho.com" CC: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSqavAlrna8BzEyYxpCWE2aK26NDc+uAgAAd44CAAARHAIAAATeAgADhAoCAAAcvAIAAL3IAgAAEuuA= Date: Fri, 15 Dec 2017 18:03:46 +0000 Message-ID: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> In-Reply-To: <20171215174628.GA17601@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0189; 6:/atbhfHlaXXtiiYJIJMHdrFwRlEAuhEBIMJxGw++XIrVpk0kV7OCP/ZrrLSUMYaMCoXRHqrPIamNt2lDuh3jFTesASsvFUrodvqPGpoCfksdZty00/tBBPEsT2+a2+dSjgSzP4lutysQz3WJ65UyNsKSAlp95M7cGIkD6X8uh0e06pi5gA4BwMXfHBPaqr8jTGU0AJa55yio5Ozu35/LHb7jZ9mKV1cI2Pjnr8v+7wheubR3EScbdUf3LNfALyHyach9QZRmN1DfjqB6jmfynyviSD1RKVx9WfEBMvARxsnYX8H6SuIa567ETRl8ZAzkhpQPmzPVieVF8FevfIbTCllRQeAFFHr230hTZAIz0es=; 5:pa4P6ZcKw/cUTVIP6usHtRAK+4EB5KsAoJDqFW9hu+PQKRAjaO8yAmWgllIUubLyKIjf/9H+n7QZUjlm4xNYkh97xPU5ZaNQ0C88xDoFdFMzzdNXMQeZldD2jia8aE/mIOaozL8x4zwVdAr+GngnfD1zbp2dX27zcb6zkODu8xI=; 24:ujkdmZkdq33MXIHON68aHnqpu3Ny9bSRhUG7HXBtusf5icvuR5L1yyPQ62HF3QBCPNOE2mQE+ENMJbCneFsqdETyoM30Vn3iS7R3aN6xwxk=; 7:rp5ekSf+jO1EpnUSSkRxTBYzLNo67/S5qKMBuGbIFm1k4c5vQZZTqv/XNr2FAERreIJWRDFEplEZkLSGDwdHbacF2HYh9pLhvYRXIGheTInAX96fzb2HfovQ825PvZA7n15mSdGzE+jWh1+7gEBknVNaZSwk/s9LkhfJS24pCtZGPJn9Kb3hUhpsCFY7Ko21XUgQ61fQ57X/O5o3t1ON1+heonWMgub07mWs6UEDGSlezVJVDqDENRCrSOvMMfBL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0e13c569-3ace-42cd-4dcb-08d543e63008 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:MWHPR21MB0189; x-ms-traffictypediagnostic: MWHPR21MB0189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(89211679590171)(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231023)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:MWHPR21MB0189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR21MB0189; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(396003)(13464003)(199004)(189003)(24454002)(4326008)(6246003)(53936002)(25786009)(33656002)(8990500004)(105586002)(106356001)(2351001)(2900100001)(6116002)(102836003)(10090500001)(5660300001)(2501003)(6916009)(2950100002)(97736004)(3660700001)(3280700002)(229853002)(7696005)(76176011)(10290500003)(2906002)(1730700003)(316002)(14454004)(81166006)(81156014)(575784001)(77096006)(8936002)(54906003)(8676002)(22452003)(99286004)(86362001)(86612001)(6436002)(6506007)(966005)(68736007)(6306002)(53546011)(9686003)(74316002)(7736002)(93886005)(478600001)(305945005)(5640700003)(55016002)(72206003)(29543002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0189; H:MWHPR21MB0189.namprd21.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e13c569-3ace-42cd-4dcb-08d543e63008 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 18:03:46.7839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0189 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:03:51 -0000 Q29ycmVjdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlsYXJpbGl1c3Zh YXJhQHdlbGhvLmNvbSBbbWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbV0gDQpTZW50OiBG cmlkYXksIERlY2VtYmVyIDE1LCAyMDE3IDk6NDYgQU0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IENvbG0gTWFjQ8OhcnRoYWlnaCA8Y29sbUBhbGxj b3N0cy5uZXQ+OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBBIGNsb3NlciBsb29r IGF0IFJPQk9ULCBCQiBBdHRhY2tzLCB0aW1pbmcgYXR0YWNrcyBpbiBnZW5lcmFsLCBhbmQgd2hh dCB3ZSBjYW4gZG8gaW4gVExTDQoNCk9uIEZyaSwgRGVjIDE1LCAyMDE3IGF0IDAyOjU3OjMzUE0g KzAwMDAsIEFuZHJlaSBQb3BvdiB3cm90ZToNCj4gRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJbGFyaSBMaXVzdmFhcmENCj4gPiBFdmVuIG5hc3Rp ZXIgZGVwZW5kZW5jeTogU0hBLTIuIElmIHRoYXQgYnJlYWtzLCBjdXJyZW50bHkgYm90aCBUTFMN Cj4gPiAxLjIgYW5kIDEuMyBicmVhay4gVGhlcmUgYXJlIG5vIGFsdGVybmF0aXZlcyBkZWZpbmVk Lg0KPiANCj4gSGVyZSdzIGFuIGF0dGVtcHQgdG8gZGVmaW5lIGEgU0hBLTIgYWx0ZXJuYXRpdmU6 IA0KPiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnRvb2xzDQo+IC5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC13Y29ubmVyLWJs YWtlMnNpZ3MtMDEmZGF0YT0wNCU3QzAxJTdDQW5kcmVpLlANCj4gb3BvdiU0MG1pY3Jvc29mdC5j b20lN0MzMGRlNmUzYTQ4MDI0MTEwNDQxNjA4ZDU0M2UzYzhiNyU3QzcyZjk4OGJmODZmMQ0KPiA0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDg5NTY3OTY5MDQwODIyJTdDVW5rbm93 biU3Q1RXRnBiR1pzDQo+IGIzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpZlElM0QlM0QlN0MtMSYNCj4gc2RhdGE9ZjcyTXZYMHlkdzVXdmprdm5n YlkzOXNhaTh2OW9PYzVaVVlaT1FJM1htSSUzRCZyZXNlcnZlZD0wDQoNCkFsc28gd291bGQgbmVl ZCBUTFMgY2lwaGVyc3VpdGUgY29kZXBvaW50cyB3aXRoIGFsdGVybmF0aXZlIGhhbmRzaGFrZSBo YXNoIGFsZ29yaXRobXMuDQoNCg0KLUlsYXJpDQo= From nobody Fri Dec 15 10: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 1969C12706D for ; Fri, 15 Dec 2017 10:08:01 -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 0CeUtK6nubH7 for ; Fri, 15 Dec 2017 10:07:58 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016051288B8 for ; Fri, 15 Dec 2017 10:07:58 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id j7so6727170ybl.3 for ; Fri, 15 Dec 2017 10:07: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=LwdWejrHqQLiJLGJ10CKns4ygZ93AI78pmGFof3qKbs=; b=dA09gL5NcH25FLF5gVGTrqmaEdMbnGRpy/MWrLwWhK4usBlcKMyrwM643O9NKtbX6/ 1OMeKz87xZrK9NFbWa4A/Rmc1p5S1jKHYmWP8w/5laX97qxndesVC7CdBKOm2JviDK2w phUBAHDZNa1qqnpZPl9idgOhcxBd3Yya6cVpqIpyBkpwmGe+28m9Or28Q+MD3Lq4aYPM OrJed9WakKCX//MHdxm/nr9heV7YcDi0oJpfKzCOgHn4tHPA5hgRABsCnwTTMgCCmH2n ZuW6m4bGsUSXfzQdTH8NmSeiiRuQuX0RLQdZPt4dM0aUB+invV5eDTZQ04Hx1A1diRC1 Buww== 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=LwdWejrHqQLiJLGJ10CKns4ygZ93AI78pmGFof3qKbs=; b=GHF+lOVZfFRzJ+KWbhBlTyc0bNYiq6tLCRw1B/fFgR007SI7UZWUemn193Q/SvvXDk 4hNgtuj4zQahVoIMjuEF4Fxa57FZLMME7X/57DUJoAxrpWo5YqdFqkCDnvzYSSZ4EeYW JruOia104LMqNj6vQ7bkSGjDqIZHK8qRoI7FBwX5ACmS2kFvTPmt87ejDT+mwVy2cjv7 9K5KR0PJzbbdELloWn2KHIrGqAORJRY7oGtzkLkBGUJB85zuW8PKCGL5o89fqF0BKRjQ ASx9NGPpgfSElfvlgiy3gyqLmQM772pj9PCNys4Zl8XL8ZqtBrBgwIbsnw+ztFuWqgdz 7Z5w== X-Gm-Message-State: AKGB3mJbfKUdfmflL7FtNMVhbKmxQwcZ4+rsc31EcW1OQejx91yNYQXA N8jqz/I/amGC5Ukw9mm/HEbSghkIydYrO1po+XY4Dg== X-Google-Smtp-Source: ACJfBotM5xhasfoK0RyT38dhEZ9kxxnpmxX3UhcbrnziPhSZ8k71v6bKdcEUh2y/1U2SQr21i+8HxJuK7hpzm3oPtKM= X-Received: by 10.129.48.202 with SMTP id w193mr7795870yww.378.1513361277139; Fri, 15 Dec 2017 10:07:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 15 Dec 2017 10:07:16 -0800 (PST) In-Reply-To: <20171215174628.GA17601@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 15 Dec 2017 10:07:16 -0800 Message-ID: To: Ilari Liusvaara Cc: Andrei Popov , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11409cfa575a9f056064e198" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:08:01 -0000 --001a11409cfa575a9f056064e198 Content-Type: text/plain; charset="UTF-8" I'm not quite following how this helps. It's true that if SHA-256 is broken, we're in serious trouble, but that's largely because of the fact that that's what people's certificates have, so clients really can't refuse to support SHA-256 certificates. So, how does adding new algorithms help? (That's why I would argue that the existing SHA-384 support doesn't help). -Ekr On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara wrote: > On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote: > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > > > Even nastier dependency: SHA-2. If that breaks, currently both TLS > > > 1.2 and 1.3 break. There are no alternatives defined. > > > > Here's an attempt to define a SHA-2 alternative: > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 > > Also would need TLS ciphersuite codepoints with alternative handshake > hash algorithms. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11409cfa575a9f056064e198 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not quite following how this helps. It's true = that if SHA-256 is broken, we're in serious trouble, but that's lar= gely because of the fact that that's what people's certificates hav= e, so clients really can't refuse to support SHA-256 certificates. So, = how does adding new algorithms help? (That's why I would argue that the= existing SHA-384 support doesn't help).

-Ekr


On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara <ila= riliusvaara@welho.com> wrote:
On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote:
> From: TLS [mailto:tls-bounces@= ietf.org] On Behalf Of Ilari Liusvaara
> > Even nastier dependency: SHA-2. If that breaks, = currently both TLS
> > 1.2 and 1.3 break. There are no alternatives defined.
>
> Here's an attempt to define a SHA-2 alternative: https://tools.ietf.org/html/draft-wconner-blake2si= gs-01

Also would need TLS ciphersuite codepoints with alternative handshake
hash algorithms.


-Ilari

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

--001a11409cfa575a9f056064e198-- From nobody Fri Dec 15 10:13: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 84A8D127419 for ; Fri, 15 Dec 2017 10:13:03 -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 aeVHgJynWubm for ; Fri, 15 Dec 2017 10:13:01 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB7812706D for ; Fri, 15 Dec 2017 10:13:01 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id j192so6124169vkc.1 for ; Fri, 15 Dec 2017 10:13:01 -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=HOBa9w4cIivmiJEs1OAXoLJyAESwnqd6fQHY1hKwxs0=; b=brrYkk85QPCkVT6lvNdDe3xPMLcndPGjkC994hBH7lFEnXyKPuifbT7HQ70wSEwCac waFkrxshB4CArgGnufsXWWE77pBm1fJxRddW7kKGRx5pHayZ7mRrGM1mPJmzHNRGZb76 qaOgMJRYjhtlJJV0lsep1Vge/LetlOag81hc9uu924Cv/4KcVCHoZUp3ZxHetPaFb4gY 9NMXsHSkz8Fu5Z9UCKVRO/FQ2wouBj/fEeGr5O7B6mxTC19ls16GbVQtOSWnm+wjm0FL hwxpVeO3HYngQxt/8wMTHfv/bagqz9bd2DCA2pmU52MKi1y+InHEo/jdfBJrdrETxH8a noXg== 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=HOBa9w4cIivmiJEs1OAXoLJyAESwnqd6fQHY1hKwxs0=; b=ZGCGLQa6ozdJ2koZkJl7Up4Qb1r935Isf8BR6RwBWAMF7mXfBXZSBI2WGzHEHAXBDa hzR0yGJaY02tvHO/l8PN6sTzUIGx0R3Mcsu6LhWRkeQSB6CUbBDnHfAAdoM05+vr7Im3 4n/yQo5EB0UHvSzswDYNCt/ORlD/4ZwqplzIPOo2BWlOhBfagaH5wvcMpTGA7MHFgWmM FcsdrnNiV2cv7iHBgbcDgMTQ0km8p97fGWuTe6C3EFzCjcLEHEFJIrblwiVpKM0UaFeB hjdDxwDl74/XzHEHp1vhFBe1WAFXEX3CIaRcUskOoG2pTN+S7B0rC5G8V970wYJV0ylC 9LoQ== X-Gm-Message-State: AKGB3mLcPjbkLGbS2Sj1xBrz9OCS8OhKKbuhcKaVpzedM92pJygEoUcI M2iKVFM0SNRWv6gCxv+/q7G8qH8i0FDSdHoMOBs= X-Google-Smtp-Source: ACJfBovVr8IY2izjCPHA1AMfuaKwBEnxAgBt1W9YyfxczMNaAOR8XcEK1MHZl5IlL7ntngtKLMfbNeD1/9FpB6JsUHU= X-Received: by 10.31.8.145 with SMTP id 139mr14715878vki.25.1513361580557; Fri, 15 Dec 2017 10:13:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.41.164 with HTTP; Fri, 15 Dec 2017 10:12:59 -0800 (PST) In-Reply-To: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> From: Watson Ladd Date: Fri, 15 Dec 2017 10:12:59 -0800 Message-ID: To: Eric Rescorla Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:13:03 -0000 We can force a rotate of all certs in 90 days, and I don't think most people will notice. On Fri, Dec 15, 2017 at 10:07 AM, Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is broken, > we're in serious trouble, but that's largely because of the fact that that's > what people's certificates have, so clients really can't refuse to support > SHA-256 certificates. So, how does adding new algorithms help? (That's why I > would argue that the existing SHA-384 support doesn't help). > > -Ekr > > > On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara > wrote: >> >> On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote: >> > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara >> > > Even nastier dependency: SHA-2. If that breaks, currently both TLS >> > > 1.2 and 1.3 break. There are no alternatives defined. >> > >> > Here's an attempt to define a SHA-2 alternative: >> > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 >> >> Also would need TLS ciphersuite codepoints with alternative handshake >> hash algorithms. >> >> >> -Ilari >> >> _______________________________________________ >> 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 > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Dec 15 10:14: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 E5E4B1288B8 for ; Fri, 15 Dec 2017 10:14:39 -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] 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 6cLgF6tBuQ_F for ; Fri, 15 Dec 2017 10:14:37 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A503B12706D for ; Fri, 15 Dec 2017 10:14:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1877DB53FE; Fri, 15 Dec 2017 20:14:36 +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 VfLuRrg9jE7z; Fri, 15 Dec 2017 20:14:35 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id ADA19C4; Fri, 15 Dec 2017 20:14:32 +0200 (EET) Date: Fri, 15 Dec 2017 20:14:32 +0200 From: Ilari Liusvaara To: Eric Rescorla Cc: Andrei Popov , "tls@ietf.org" Message-ID: <20171215181432.GA17685@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:14:40 -0000 On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is > broken, we're in serious trouble, but that's largely because of the fact > that that's what people's certificates have, so clients really can't refuse > to support SHA-256 certificates. So, how does adding new algorithms help? > (That's why I would argue that the existing SHA-384 support doesn't help). TLS handshake assumes the hash function is strongly collision- resistant. So if SHA-256/SHA-384 breaks, the handshake hash function needs to be replaced. This is separate from certificate signatures. Transitioning this would be much more nasty than TLS handshake hash, because there is no backward-compatible way of changing the hash. This is one major reason why SHA-1 transition took over 10 years (oh, then there is the "fun" post-quantum transition possibly coming up). -Ilari From nobody Fri Dec 15 10:16:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD13E12706D for ; Fri, 15 Dec 2017 10:16:06 -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 DPrGB6BTEhTr for ; Fri, 15 Dec 2017 10:16:05 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDDA1270A7 for ; Fri, 15 Dec 2017 10:16:04 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id b15so3110631ybn.0 for ; Fri, 15 Dec 2017 10:16:04 -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=y07jJkTkYR7aau/q2LRwHLDHmH837FDuOOwJsFSTtPY=; b=T7T7lrNkdIb6OVQfx3zV0NYjThAFLBYvZbL6f48uXmvJa+4iXmwXVD/bVV9uiCR28M 7d88t1ieLXVGM6biBiorg7IWwEcImLSLAzFySVhnEWm1cJDlVrBk22MOrGUM8QjC82Cf XAGnsWgF2fNuJcCFavVbTwR/DxRhdeK/dtyOv1iu9YKaBKYIZgVTVbr6HRn6miUzqVIX mq/fAiLY3rx2JLwxsGOGfiooeDVSdP4fMcSUHP/mWtpRVdRBqsLaHXhwiZmQ96+gACqi k/KlW59aVPtoqP5YfJeuf8CZ/UY26gHx/y9rAFKM0u6DPhJMRGrs8rJPvX002CJs+aR5 w4sw== 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=y07jJkTkYR7aau/q2LRwHLDHmH837FDuOOwJsFSTtPY=; b=g3yl9sO4OVEcnqmayzcn05zQ+U1yrX+JZhHgCzF1Qss6LQv6LSMXjOG/EzeW4CV0UB 4GMlV/35btMrb/cYy6cNXDcSpppwKB1zB9edIJh4yV7K7sBLaWkAvUj1etyDn61Q88iL udfHVlzwDjxfv6Mgoa70xZRPTH3EYQPQBT8N9mDHeoIpBpavYHIt1xFnXihHmxkgyuUT Xq19AsevCaIaYUp/OKoINIC2JFCuQXOgwmynZ3dBm3vK3bLIF/FIRCSDROWjxoCrRawp BS5jzYd5SExvqlghZqilFi70SsXKIgxIHsibT8tDJu6DJoKECuYCG9JwgL1NAnFIapQn T1bQ== X-Gm-Message-State: AKGB3mJ+GIjyAkIxoX5BscSSRxmpA/Ejv3x9KA3850U66bGMqReX/YOm X98MvKYQ5HaJoIrHm6GrtqNHk0ovOqKjHiHKX5eKSg== X-Google-Smtp-Source: ACJfBotn5msnlfgyPkKh4Kj+mwdOyVjxk7T7BhfhD47T0tTrrP5GKd6ccC8cDU2aAbj5NzN38X4ohhGSCfcnQEgMCCk= X-Received: by 10.37.16.134 with SMTP id 128mr7932272ybq.474.1513361763915; Fri, 15 Dec 2017 10:16:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 15 Dec 2017 10:15:23 -0800 (PST) In-Reply-To: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 15 Dec 2017 10:15:23 -0800 Message-ID: To: Watson Ladd Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11c0125a5b0332056064fe7e" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:16:07 -0000 --001a11c0125a5b0332056064fe7e Content-Type: text/plain; charset="UTF-8" On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote: > We can force a rotate of all certs in 90 days, and I don't think most > people will notice. > Unfortunately, there are plenty of longterm certificates with lifetimes >> 90 days. -Ekr > > On Fri, Dec 15, 2017 at 10:07 AM, Eric Rescorla wrote: > > I'm not quite following how this helps. It's true that if SHA-256 is > broken, > > we're in serious trouble, but that's largely because of the fact that > that's > > what people's certificates have, so clients really can't refuse to > support > > SHA-256 certificates. So, how does adding new algorithms help? (That's > why I > > would argue that the existing SHA-384 support doesn't help). > > > > -Ekr > > > > > > On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > >> > >> On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote: > >> > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > >> > > Even nastier dependency: SHA-2. If that breaks, currently both TLS > >> > > 1.2 and 1.3 break. There are no alternatives defined. > >> > > >> > Here's an attempt to define a SHA-2 alternative: > >> > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 > >> > >> Also would need TLS ciphersuite codepoints with alternative handshake > >> hash algorithms. > >> > >> > >> -Ilari > >> > >> _______________________________________________ > >> 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 > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --001a11c0125a5b0332056064fe7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd <watsonbladd@gmail.c= om> wrote:
We can force a r= otate of all certs in 90 days, and I don't think most
people will notice.

Unfortunately, ther= e are plenty of longterm certificates with lifetimes >> 90 days.

-Ekr
=C2=A0

On Fri, Dec 15, 2017 at 10:07 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> I'm not quite following how this helps. It's true that if SHA-= 256 is broken,
> we're in serious trouble, but that's largely because of the fa= ct that that's
> what people's certificates have, so clients really can't refus= e to support
> SHA-256 certificates. So, how does adding new algorithms help? (That&#= 39;s why I
> would argue that the existing SHA-384 support doesn't help).
>
> -Ekr
>
>
> On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>>
>> On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote:
>> > From: TLS [mailto:tls= -bounces@ietf.org] On Behalf Of Ilari Liusvaara
>> > > Even nastier dependency: SHA-2. If that breaks, currentl= y both TLS
>> > > 1.2 and 1.3 break. There are no alternatives defined. >> >
>> > Here's an attempt to define a SHA-2 alternative:
>> > https://tools.ietf.org/html/draft-wconner-blake2sigs-01
>>
>> Also would need TLS ciphersuite codepoints with alternative handsh= ake
>> hash algorithms.
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> 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
>



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

--001a11c0125a5b0332056064fe7e-- From nobody Fri Dec 15 10:17: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 EDA7E127419 for ; Fri, 15 Dec 2017 10:17:41 -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 rWBhASGWAxmc for ; Fri, 15 Dec 2017 10:17:40 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE23127077 for ; Fri, 15 Dec 2017 10:17:40 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id x83so6731392ybg.8 for ; Fri, 15 Dec 2017 10:17: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=wRKA8KZvj29WpazxTzkYA2nmAt6rWB3JMO/zmVV/bvk=; b=O+7QZA5bPHsJD3zKlgJt5Zxzm1zRk78qs7Y4RXYPva0VbYKRw6COMl11DVL8OrsJnZ KjgcJRA7h1/C/cdhV4g7PKTJ1FOvaN0I8wqB2SQQ5y9BaaWXc8ij4OHO1aNmKUiH5NiB zDozqhFlYme22wO3itjVUR8V5WPOwomTp1xNRVg6W1K8O6VFGs5eQ4qtBMZVLJrGFIlh FRjCk0l9Mp5hKdDRUFOFJE59COarUUc+U2BWVdsd6dpFy9YPVNlAa2xiUpGKXbt2pDhv +SZ14O//qR94+XaObl0VpyPEYC3z8a1jfritZERKElZDvz069LBo6arYY4PvyX2R1V6i 1FsA== 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=wRKA8KZvj29WpazxTzkYA2nmAt6rWB3JMO/zmVV/bvk=; b=LFukLQrKf7gc98TyWEt3pxXVntCG3CGWHHsjhsR5vvxtuGgzW4Jmntc4lYoMHvyBH0 8yijZ639uphB2Zb1yzPSyLwkScZbRjO/3VWqG2b7bS07+kCXI+Xo7LetQDD2MPp6bOt9 6LUDzB6OD5o7hAzF+rNtfhs40rImB4YGqijU0qqMd66Srvvd/QwYbdLUcV9LWDPgq8aG 0spkbW5cGKke0o+FLnLhi90/y0bqdRrf3HxcLTnu9Qy0wUNglvFZvLfYQpQl1WxfTMKQ XBU0PjGrV2MhEzmwo2vA4A8gFmOSqBcWmvKHwtAnrUkWEkUzc9rEiXpN041WKtJG1JPX 1roA== X-Gm-Message-State: AKGB3mJwlyvQD70gZWA6+Aem1xjvLvsOKACsOWczLXP1IDE0T0o01Py8 O3izMVbCHVaIidZeZAUTcpPDNhRMyzOdANwy868RjA== X-Google-Smtp-Source: ACJfBotExxkYg9AyOWvSNa0xyKkRsdASSgQk12TQl+1oBLlxW2LR/LceF9ndRBkcrGjje9u3/Y2XSoO6VQXmw51kvr4= X-Received: by 10.129.85.198 with SMTP id j189mr7529148ywb.504.1513361859878; Fri, 15 Dec 2017 10:17:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 15 Dec 2017 10:16:59 -0800 (PST) In-Reply-To: <20171215181432.GA17685@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215181432.GA17685@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 15 Dec 2017 10:16:59 -0800 Message-ID: To: Ilari Liusvaara Cc: Andrei Popov , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f169e13289905606504e0" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:17:42 -0000 --001a113f169e13289905606504e0 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 15, 2017 at 10:14 AM, Ilari Liusvaara wrote: > On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote: > > I'm not quite following how this helps. It's true that if SHA-256 is > > broken, we're in serious trouble, but that's largely because of the fact > > that that's what people's certificates have, so clients really can't > refuse > > to support SHA-256 certificates. So, how does adding new algorithms help? > > (That's why I would argue that the existing SHA-384 support doesn't > help). > > TLS handshake assumes the hash function is strongly collision- > resistant. So if SHA-256/SHA-384 breaks, the handshake hash function > needs to be replaced. > Yes. In 1.3, you would define new cipher suites with the new hash. But of course you then have to worry about downgrade if clients jointly support the weakest hash and it's weak enough. -Ekr This is separate from certificate signatures. Transitioning this would > be much more nasty than TLS handshake hash, because there is no > backward-compatible way of changing the hash. This is one major reason > why SHA-1 transition took over 10 years (oh, then there is the "fun" > post-quantum transition possibly coming up). > > > -Ilari > --001a113f169e13289905606504e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 15, 2017 at 10:14 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-= 256 is
> broken, we're in serious trouble, but that's largely because o= f the fact
> that that's what people's certificates have, so clients really= can't refuse
> to support SHA-256 certificates. So, how does adding new algorithms he= lp?
> (That's why I would argue that the existing SHA-384 support doesn&= #39;t help).

TLS handshake assumes the hash function is strongly collision-
resistant. So if SHA-256/SHA-384 breaks, the handshake hash function
needs to be replaced.

Yes. In 1.3, you = would define new cipher suites with the new hash. But of course you then ha= ve to worry about downgrade if clients jointly support the weakest hash and= it's weak enough.

-Ekr


This is separate from certificate signatures. Transitioning this would
be much more nasty than TLS handshake hash, because there is no
backward-compatible way of changing the hash. This is one major reason
why SHA-1 transition took over 10 years (oh, then there is the "fun&qu= ot;
post-quantum transition possibly coming up).


-Ilari

--001a113f169e13289905606504e0-- From nobody Fri Dec 15 10:34:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A8F12940C for ; Fri, 15 Dec 2017 10:34:32 -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] 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 nkdY4Ii359ik for ; Fri, 15 Dec 2017 10:34:29 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFB412706D for ; Fri, 15 Dec 2017 10:34:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 019B848844; Fri, 15 Dec 2017 20:34:28 +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 y0EW1QEkllTC; Fri, 15 Dec 2017 20:34:27 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 985E6289; Fri, 15 Dec 2017 20:34:24 +0200 (EET) Date: Fri, 15 Dec 2017 20:34:24 +0200 From: Ilari Liusvaara To: Eric Rescorla Cc: Watson Ladd , "tls@ietf.org" Message-ID: <20171215183424.GA17780@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:34:32 -0000 On Fri, Dec 15, 2017 at 10:15:23AM -0800, Eric Rescorla wrote: > On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote: > > > We can force a rotate of all certs in 90 days, and I don't think most > > people will notice. > > > > Unfortunately, there are plenty of longterm certificates with lifetimes >> > 90 days. Yes, currently the lifetime limit for public certificates is 39 months, and will be reduced to 825 days (~27 months) effective March 2018. Then there is backdating to consider. It was seen in both MD5 and SHA-1 deprecations. So maximum certificate lifetime sets limit on how fast features can be flushed out. And then there would be enormous amounts of endpoints not supporting anything better. Those would have to be upgraded. All in all, a real mess. -Ilari From nobody Fri Dec 15 10:41: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 6A97F1270A7 for ; Fri, 15 Dec 2017 10:41:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 GJWrmaPFjV39 for ; Fri, 15 Dec 2017 10:41:09 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0119.outbound.protection.outlook.com [104.47.42.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A385312706D for ; Fri, 15 Dec 2017 10:41:08 -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=+3We7bAVOYFAb6jPrJN13Oi9WDpSc+3IsWzZyXVCm14=; b=l9nJdYHNkiJD6rRMgFdBjMdtQ3Q7qSY2uFOfy6vELNCF2rpb2+ieckFyIQ4DvUXQNbFQokdEpUb9DnZ1h4pjHJ8t7d8cZw+2wW+Yrek1x+CKqCClV3khGzFf1d432ZgZ3z8AVbPJAoiwhNc6H7vzXnr8fgYfVO5TftBfSR/m1do= Received: from MWHPR21MB0189.namprd21.prod.outlook.com (10.173.52.135) by MWHPR21MB0173.namprd21.prod.outlook.com (10.173.52.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.1; Fri, 15 Dec 2017 18:41:06 +0000 Received: from MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) by MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) with mapi id 15.20.0345.002; Fri, 15 Dec 2017 18:41:06 +0000 From: Andrei Popov To: Ilari Liusvaara , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSqavAlrna8BzEyYxpCWE2aK26NDc+uAgAAd44CAAARHAIAAATeAgADhAoCAAAcvAIAAL3IAgAAF0ACAAAGYgIAAAKyAgAAFUACAAADZAA== Date: Fri, 15 Dec 2017 18:41:06 +0000 Message-ID: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> In-Reply-To: <20171215183424.GA17780@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0173; 6:GkeTewFVCVD20H/lKr5BNlS0wL44wBSVj8IpFd0bDNqk0p8QhVH9uyxWvs7EQshwXggQ14cpGXbN1yKTw8XQmXH/98r0+ihgIiFUNazCFJ8itaA1SyVLnH89Nq5+sGBqniayNAGg29tPhz791B9ZOdDw5UqvlDrmpntX3zo1rmaheMWmbAUeeN6nOglRDeu904MPKWqbgzb2cZL2rvNxnTkUvfFdga7wOnvLQruxQ5d+nGbw3VABqnkPo00Fp9K3CNyP0WslFuyszH2KmfADVkMXY305S75riPEbBaarNhE9k6G4ZUFzcNqDKg06DzlzXpYhHIN/jxTVcnq/VK5gEba+2qjTJAc8AUmV1bU+qzM=; 5:fCTiugRNOOo2Xfx8Rb2mhGoDpQ4L2hRS7r1rVDM4CvVKs51XZ/4v9two7s+pkyRf3LhhJt/USjXbCB8QwjLjkscXhkIEWgoqXqLJzM392vBUvG16+Mwu52FiZ/6f+Kwo31LRXk0qkLbyOlnERKhPJf+uwU0TiOx97udhmDG26fM=; 24:ZiORk10VQO0podkzG2G/o5thl4IAAhXSrNKTB+8QbUUVlf7ATScljUs95fcopV5gCo4bXMO9WABaszzu3CiCXMvKYHn/dKdFxk89e3W9AQA=; 7:DdIAnSumAenFhGisx0odkD2tSYMAymKPLG+qlpAERvDMp5EOhrbIh7ZPQ+8hFgz91MGuTAABPSgxDnI+l5kbvXetOSv9ynAaRStld9eN52Xs/6ItKyo1wfrrAON3YCZzzENJrRgHm4BNP2prVh+zXqeNc8F9MRBPBTM4t8kQ2cyl0UTP/ZhhHxxuZHKhrAovdNDsoVCU/SSFrgKkwyjTMdxRTIyID+j0VMJqgn5/q2tIv8e9EjUIiX0aO2gw5CM+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67706bf5-548e-4738-6038-08d543eb6723 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:MWHPR21MB0173; x-ms-traffictypediagnostic: MWHPR21MB0173: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231023)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011); SRVR:MWHPR21MB0173; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR21MB0173; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(396003)(366004)(39860400002)(346002)(376002)(189003)(199004)(24454002)(13464003)(68736007)(74316002)(6116002)(7736002)(305945005)(81166006)(2950100002)(6506007)(22452003)(59450400001)(8990500004)(316002)(102836003)(25786009)(53546011)(4326008)(53936002)(966005)(2900100001)(6246003)(86362001)(72206003)(86612001)(9686003)(110136005)(5660300001)(97736004)(508600001)(81156014)(8676002)(10290500003)(8936002)(105586002)(7696005)(99286004)(3660700001)(77096006)(3280700002)(6306002)(55016002)(76176011)(14454004)(93886005)(6436002)(229853002)(33656002)(2906002)(10090500001)(106356001)(29543002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0173; H:MWHPR21MB0189.namprd21.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 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-Network-Message-Id: 67706bf5-548e-4738-6038-08d543eb6723 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 18:41:06.7509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0173 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:41:11 -0000 It's true, the migration will be slow, but IMHO it still makes sense to def= ine and implement an alternative hash. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, December 15, 2017 10:34 AM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in ge= neral, and what we can do in TLS On Fri, Dec 15, 2017 at 10:15:23AM -0800, Eric Rescorla wrote: > On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wro= te: >=20 > > We can force a rotate of all certs in 90 days, and I don't think=20 > > most people will notice. > > >=20 > Unfortunately, there are plenty of longterm certificates with=20 > lifetimes >> > 90 days. Yes, currently the lifetime limit for public certificates is 39 months, and= will be reduced to 825 days (~27 months) effective March 2018. Then there is backdating to consider. It was seen in both MD5 and SHA-1 dep= recations. So maximum certificate lifetime sets limit on how fast features = can be flushed out. And then there would be enormous amounts of endpoints not supporting anythi= ng better. Those would have to be upgraded. All in all, a real mess. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Ftls&data=3D04%7C01%7CAndrei.Popov%40microsoft.c= om%7C248257e4202549b54e9208d543ea7ff7%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636489596817634560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=3DviW%2F6xW3bJoG6SlxgENwp%2= BFH8%2Bqnb%2BFynkE4Yxfq%2Bjc%3D&reserved=3D0 From nobody Fri Dec 15 10:49: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 918B1126E3A for ; Fri, 15 Dec 2017 10:49:58 -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] 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 WnM6MNpEQBun for ; Fri, 15 Dec 2017 10:49:56 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AA1124BAC for ; Fri, 15 Dec 2017 10:49:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id AD68D53726; Fri, 15 Dec 2017 20:49:54 +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 Dzdf8OPzqqR0; Fri, 15 Dec 2017 20:49:54 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5911928B; Fri, 15 Dec 2017 20:49:51 +0200 (EET) Date: Fri, 15 Dec 2017 20:49:51 +0200 From: Ilari Liusvaara To: Andrei Popov Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20171215184951.GB17780@LK-Perkele-VII> References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 18:49:58 -0000 On Fri, Dec 15, 2017 at 06:41:06PM +0000, Andrei Popov wrote: > It's true, the migration will be slow, but IMHO it still makes sense > to define and implement an alternative hash. Agreed. However, on certificates front, we need a method to perform backward-compatible algorithm transition. Because non-backward- compatible ones are just too hard. As we have seen _twice_. On TLS handshake hashes, the transitions are already backward- compatible. But that does not mean the transition will be easy. -Ilari From nobody Fri Dec 15 11:14: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 CF50C126C19 for ; Fri, 15 Dec 2017 11:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAOOpM3eP6uL for ; Fri, 15 Dec 2017 11:14:06 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0C812706D for ; Fri, 15 Dec 2017 11:14:06 -0800 (PST) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta-12.messagelabs.com id 78/92-15086-DFE143A5; Fri, 15 Dec 2017 19:14:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGe2emw0ioGQvIsQLGJibY2AYQI0a N+qAhKpEYMKYh6CBDW+1COsXgixADBMGgLLGIKEQalSpowH2FugIaFI0IuIDiBiKCG5Jq7PTW 7WXy3fv/557/3jkMKR+gFQyfZeOtZs6opP2pDk1totodHqONPPpgTux4aQUZO3LRTsWOdRSip WScw/GdiMs798Mvrreoik4gtVKDOdWStVGqr+l+QmQ4VmaNHttL5SD7ikLkz1DsCAHtjz+Q4k LOlhHw/G0+wovrCHJfNNKFaBJDs5Hw6PItQuQgVgvH+yYokUl2Jox0HvRyIGuEA/XNFPaYoGG ozw/zduh4XC4VmWJnQcmRJq9HxibDjituX+edUiitGkaiMImNgav1Y97GiJ0K39qOE7hZCPQM VHsZ2CDov99OYw6Gdy9/SrE/GQ58cvn2ldBbP44wh0FndZH3ZsC6/OBVSz+JBQ2cLhn2meKh7 FsdjU2HEbyqPUlhQQW3Xfk+0xbY2zXsKWY8vAqchRHYf42E7uJLPk8oHGpwSrFQQEPdqQJvJD mbBuVOHC+QVcDThzvRHjS78p/bYa5GULYnodL7TFOgdd8AhffVcOFKM4l5BpwdrvLxQqiYaKE rfb+kvKjfD/M8GLoximoQ40QRAm/dylvV0Qs0qVaDTm8zcQajOioqWmPiBYHT8UYuVdBsspga kWfKsiUSdA79/BzvQtMYQhksszVGa+WTUy1p2/ScoN9gzTTygguFMowSZB1hMVr5FCuv47PSD UbPqP6WgQlQBslCRVkmZHAmwaDDUhtawNxsfOAmGPelHs/39b6hHFJOmS1mXhEi6xILWLFAn2 n+c9zv4e9EYYpAGZJIJPKADN5qMtj+1wdRCIOUgbJ68ZQAg9n2p+ugJxDhCTSgmysGsnF/JUU OumNatuZg39RibmmxEOpIz509mh1xd0nily0m1e42f/dt1b038RVJ5R+dCZ2DpUmZfcHr+nep t3EZiZUR+yMr1ibPXz1mswuLpj98fb61yX/z+I3mu8trZrXMSKptSFmvep+XMtZlX+9oKrU/y z5z/+vMEupDCuq2BISdmFj89OP08HAlJei5KBVpFbhfv6QIefcDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1513365242!196769649!1 X-Originating-IP: [207.46.163.84] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29982 invoked from network); 15 Dec 2017 19:14:04 -0000 Received: from mail-bl2nam02lp0084.outbound.protection.outlook.com (HELO NAM02-BL2-obe.outbound.protection.outlook.com) (207.46.163.84) by server-7.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Dec 2017 19:14:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5Ovs5OMy19XdNBgsio8CsjiY8jvW675j5qxc/gHNo4s=; b=A1wpgOEHUmIbCsXqSG+bRsBhURgqsCpa8vRMCYwsPfyqHH8qhxQqtSEfCCfYtiUq7ZbqlC2S2hwan+4HscFAs9rapS6KzKESpFnViMYqRAgZKKfZJpwLy1mHPnx80w1ywzfWFex/AqZQof3r25rgMTkTXq/eLg6EAF8Pr10QkpY= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 15 Dec 2017 19:14:01 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0302.012; Fri, 15 Dec 2017 19:14:01 +0000 From: Tim Hollebeek To: Ilari Liusvaara , Andrei Popov CC: "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSnZboSBNXzd9E6O2/oU/bBgd6NDc+yAgAAd44CAAARIAIAAATeAgADhAoCAADa3EYAABbkAgAABmYCAAACsgIAABVAAgAAEZ/+AAAJE8A== Date: Fri, 15 Dec 2017 19:14:00 +0000 Message-ID: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> In-Reply-To: <20171215184951.GB17780@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1289; 6:7jzAa3hJ4NAbpUT38LtQjGfjpo07hILDe7CSUbyaKmMnpbPOOcyOVoAoqQeI/ZmpStul6COMnxd9PCrIvvBfCMhGz8Q2Bn4Xvj7k/TTGx6bvPWwfvx9kM0CC0++SuJnopj37kDHtmX5NTI17bdXQYtxaW/PQFlxQ0M6+dkhEV9KzXY/ln7S8AUoCy6vbIfq1aFVQlXSnEFg2u/YPktpZqtD9MWIgzSUbHdwHdrhuw2hGS/ZpjL3b7nnvxHtQhXvD0/zY8KW2bvifYU75nWJazZQW9matMuAIaL2CejYGIDg+Wlci52UOEgoJHDmc06PR59L0Fp21beFzdrqtmdVjER8TZQFVh+ohrIVUuQTFSrs=; 5:OIouTF/h9lbrv9MmIALTF5pM6kXvANWRLTyWzTak/kEwYVCYMUSEMWYDlYTUA1GnqcFyHm5jRvFDAE584Ixeu03Ew2peD44IsjUUYQH2sFhLs9CXunE+VFu0WsiqAQ1KZxwIwHzt2cQ8No6ryX8MGqO7xCsunrtuq3P8T3+kvTI=; 24:JrHPm3iuhkPjKjjq5bWyFVPLRNPHych7jiCXqS7RdUBqFZXzdnyGaO1Ua5FzVPBNjMQ6Dv0MJW7CQqXq+LACoi2PM1PRd4kjn6IF+8ZuzRM=; 7:W70a3d1rTgTU82QR8b4TcwSqag/4Eqqs3J+5VkbQRuOJT3ykOtd5OwyOXsdaE2ipgu0mcxW5SNnqdl57KnjuFSb1ghqhQ5yY9xh9I9sm713IMbakHHVLcCwRM91xAUM9te8WROumMdCEkfkkqZu/gQBBSz606OQV85v+8GZbK83yMkZl1p+3+CAaUSzYvpKHw095dlxYaDv26ndDLJhGJNj+NNyZ+Fodyawvb/FHXYLP+EVHQ7wZj5RS3lOiOHsU x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 803656d0-7add-4811-05df-08d543efffd2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(49563074); SRVR:DM5PR14MB1289; x-ms-traffictypediagnostic: DM5PR14MB1289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(89211679590171)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6041248)(2016111802025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6043046)(6072148)(201708071742011); SRVR:DM5PR14MB1289; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1289; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(376002)(199004)(24454002)(13464003)(189003)(966005)(229853002)(3280700002)(93886005)(86362001)(6116002)(2950100002)(14454004)(4326008)(110136005)(6506007)(77096006)(478600001)(2906002)(99936001)(76176011)(316002)(59450400001)(102836003)(2561002)(305945005)(8666007)(7696005)(25786009)(106356001)(66066001)(105586002)(2421001)(3846002)(8936002)(1511001)(74316002)(81166006)(6436002)(8676002)(81156014)(9686003)(99286004)(5660300001)(33656002)(53936002)(68736007)(97736004)(3660700001)(7736002)(6246003)(2900100001)(55016002)(53546011)(6306002)(29543002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1289; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_04A8_01D3759E.2D366B20" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 803656d0-7add-4811-05df-08d543efffd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 19:14:00.9898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1289 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 19:14:09 -0000 ------=_NextPart_000_04A8_01D3759E.2D366B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So, this has been discussed extensively at the CA/Browser forum, for obvious reasons. In my mind, it is not so important to identify and define and implement an alternative hash. What *is* important is that the protocol and associated software is able to support a smooth transition period where people are moving from one algorithm to another. Ideally, you'd want certificates to be able to have two signatures during the transition period, in order to support clients who have transitioned and those who have not. Unfortunately RFC 5280 is deficient in that regard. Hosting multiple certificates and switching based on the client is feasible, but requires some technical wizardry and isn't possible in all situations. A lot of these transitions are painful because with the way things currently work, algorithms have to reach near ubiquity before the transition can begin (the popularity of Windows XP was a huge problem). The transition will happen at different rates for various industries and use cases that have different security requirements, so everyone needs to be able to move at a pace that makes sense for their needs. It needs to be carefully coordinated, and yes, transitions will take years. The current maximum certificate lifetime is a compromise between the speed at which changes can be made, and the pain imposed by replacement, which largely still isn't automated. I know people are working to improve that, but we are where we are. -Tim > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Friday, December 15, 2017 11:50 AM > To: Andrei Popov > Cc: tls@ietf.org > Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in > general, and what we can do in TLS > > On Fri, Dec 15, 2017 at 06:41:06PM +0000, Andrei Popov wrote: > > It's true, the migration will be slow, but IMHO it still makes sense > > to define and implement an alternative hash. > > Agreed. However, on certificates front, we need a method to perform > backward-compatible algorithm transition. Because non-backward- > compatible ones are just too hard. As we have seen _twice_. > > On TLS handshake hashes, the transitions are already backward- compatible. > But that does not mean the transition will be easy. > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_04A8_01D3759E.2D366B20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE1MTkxMzU0WjAvBgkqhkiG9w0BCQQxIgQgZsCnc+U1fhgpzkbwCxv8nL7XpbyQ 2ZdPHgPYp7IILoEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBACiT97G9HJXhuf4O7qw6QQ3VtF3Q+BtSZfLMyjfnXnJr6yQMrMzZgDZdJrfkicoEzeXoTyg9 SURbAt9BtzgdNRgq6Z6/OOg8NKxGaKN9DI1yNZuPx53YlAYdAOcin5UrHjLc9Mb1/jbaMn0f8cyj DHtpoc4+FA9LXl7ix6P4qFMTXRWROmNxESYJHEQJr/qGjj5HHzNpOqeWwria6jRbDFpmbb6//Np8 Nnkd8MOyutQaDWrGAeJX8zNw9O4zFJWBVG936F0cj3tDxzA4tKOvHkvu+rBDmuu10hX1LcW5ehsY WBHxalJL1lN2wbK+p1sA+Duhv1KD9C1a9C+7FILBrFkAAAAAAAA= ------=_NextPart_000_04A8_01D3759E.2D366B20-- From nobody Fri Dec 15 11:25:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714DE12706D for ; Fri, 15 Dec 2017 11:25:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4d8mnv7P19ie for ; Fri, 15 Dec 2017 11:25:22 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35482126C19 for ; Fri, 15 Dec 2017 11:25:22 -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=ZIpVIZvtVFmQPj3EVTUxQ3x2VeehYxbHw5Ya4I52drs=; b=a7CjElXBCNqwikJkxOd0vFBEXLYCT1x14hcfZzfTfMR5MYhnK6V6Dg+HgV+AImHJNN8EAKN2UAUjOoBtTGLQOlRz8h7O0FUnAmeB6cR2A3PFrf7MjJhHiVf3rN6Gy9khWuAMwCAAseXhohfQKPA5Uxn3nGGUCoES9aMtI47E4gE= Received: from MWHPR21MB0189.namprd21.prod.outlook.com (10.173.52.135) by MWHPR21MB0768.namprd21.prod.outlook.com (10.173.51.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.3; Fri, 15 Dec 2017 19:25:20 +0000 Received: from MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) by MWHPR21MB0189.namprd21.prod.outlook.com ([10.173.52.135]) with mapi id 15.20.0345.002; Fri, 15 Dec 2017 19:25:20 +0000 From: Andrei Popov To: Tim Hollebeek , Ilari Liusvaara CC: "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSqavAlrna8BzEyYxpCWE2aK26NDc+uAgAAd44CAAARHAIAAATeAgADhAoCAAAcvAIAAL3IAgAAF0ACAAAGYgIAAAKyAgAAFUACAAADZAIAAA3iAgAAGwACAAAHlUA== Date: Fri, 15 Dec 2017 19:25:20 +0000 Message-ID: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0768; 6:dt9eqERHTkGTHpOTqenYb2Nef2yFH8Kq3k1PUZsIUG2kE57GHZvQFMg7JqcBlMFGxueHo76UFOTmq3Y0yq8UozQ/jB2OlJqYT2iNYT9Gy52qSPdZSckNDTvZ0U6J9cbvoBlWZATxd9KWGXt7tR3y0FwAyxMyf0HZK80h2/F0t+yDMIiA722DgAmgC4nXN6GTZalzeKIx4CnG+KgUVl+DfOOghlKLFhuqya4ZSW45KduvmhqQYL/xDHSHqQSydbVXHAnQOrSw6kZyj2gXVhbkGOBAxMOAjZQIHwRGl6t7yuu8VDtXkem7el6MBhgE8C3AQlfeiGGIboKASo5zr12Re8PJIqmmg/PodyEuAhK+Pmc=; 5:Ulztf45ojdFBJLiynXRy/kucUJOywW+/HKH7osq1bM/WJ6PKoskL6BL6uziVuSP1f4M3DwfaCFn7Ie0w5+ww6Y+jM19sMPX665nW3idvlZ8BYDmx5sVo6xaNl0cDDOFCndopq49Tr4QFMNmXmGPf0yZqwjm9A5qELQ8NwbIWV4o=; 24:k0MCeEmHEjNAuwqSgx7zFgaz2EnlgoiFvRVIXtJdRgBUIKmO1bIgfG2v5PQ1toyt+Hqx7nBxAUcM6DHJUHwlAT8XRbO6b4XGTnK6U7CkOKw=; 7:i9bo7aqqpL1frFhKQ4Uh0jVWHERk1xy0NNmp5N4EqP67FvgtY8bqt1+MAVfb6CvPr3Wjmr5f410ACBjUDqy2Yr6JuvSyqzfKHgoHoGDWKd4YYqkIwEeIASr5WmR7e0nsFwzmcghlbgPOzbzIvSxnUQifANU0ivTLsOrYHz4QAHgkss8WouxllWfi6Z6erC2iVF/MzPe8K+wDHhskWPlMu5C8q1s5tT8qfWyBTn8+2vlN2B9XN6UvYSEGb/u2scY0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0a41c4a6-a1b0-42ed-84bd-08d543f194ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:MWHPR21MB0768; x-ms-traffictypediagnostic: MWHPR21MB0768: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123564025)(20161123558100)(6072148)(201708071742011); SRVR:MWHPR21MB0768; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR21MB0768; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(376002)(39860400002)(366004)(346002)(396003)(199004)(189003)(10090500001)(93886005)(9686003)(6506007)(2950100002)(7696005)(76176011)(68736007)(106356001)(14454004)(97736004)(72206003)(508600001)(53936002)(6116002)(8990500004)(2900100001)(4326008)(5660300001)(316002)(3660700001)(22452003)(2906002)(99286004)(110136005)(59450400001)(8936002)(25786009)(102836003)(6246003)(3280700002)(86612001)(86362001)(33656002)(81166006)(8676002)(81156014)(7736002)(74316002)(305945005)(105586002)(77096006)(55016002)(229853002)(6436002)(10290500003)(29543002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0768; H:MWHPR21MB0189.namprd21.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a41c4a6-a1b0-42ed-84bd-08d543f194ae X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 19:25:20.2031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0768 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 19:25:24 -0000 > Ideally, you'd want certificates to be able to have two signatures during > the transition period, in order to support clients who have transitioned = and > those who have not. > Hosting multiple certificates and switching based on the client is feasib= le, > but requires some technical wizardry and isn't possible in all situations= . For my understanding, why is the former (double-signed certs, where either = signature is trusted) better than the latter (multiple certs with different= algorithms)? The latter is currently supported by some TLS servers. Cheers, Andrei From nobody Fri Dec 15 11:34: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 D330012706D for ; Fri, 15 Dec 2017 11:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KANPytr4tV2M for ; Fri, 15 Dec 2017 11:33:47 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 8BA18126DCA for ; Fri, 15 Dec 2017 11:33:47 -0800 (PST) Received: from [216.82.242.46] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-8.messagelabs.com id BF/68-03583-A93243A5; Fri, 15 Dec 2017 19:33:46 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSeUgUYRjG99uZHUfbrWlc823RjumgLBdLq4U IrKD8J7A0gs2O2XbaXdrDdrawW6iQtKILUtM2OoQ0I4TW7DSzRKXLoqDM1ETQddGK8q529puu /37f+7zf+zwz30sTbAulo4Usj+B28naOiiCf6y+Niy+YlmRMOFY01zBwKp8w9N45Sxq+PM9Fy UTK5cuDypTDt0bDUt7nFVGphFFlc5pcWZtV1ro7/VRm2YqsG8PtKBv5l+WicJpkepVQ1zw2F0 XQLHNaCfcbX4ThQy2C0eoqSuqimAR4c69OKbGWMcJ3X1uoTjBTobfpPClxJGOH4vJqEvc44Lq /NTRIy+QiONzlQ9huBrT7KgmJNUwG/Dw3LLuVU3DjQo9KEsKZDXC03htqQswE6G+4psRu0fCu wxtiYLTQ9rKRwhwFXZ9+qHB/BhR/rZHrHLwvH0CYY6HJmydzTRg0n3Jh1sPNkwG5vgq8ra2UF AiYEgR9vm5ZiIPGxgF56DYY/NpAYl4MV7v7VPjCIwJyRt8QWIiBi9dLZWFIBQcH+0K3WcYMZ0 pxvEhGBx9eH0En0OzCf74OsxfB8OmowtBvGg/1BR0krsfD7fvVBObJUBkoknkx5A89pArlNzm T1xaGeQH4H39GFxBdimaJgnun4I5PXKA3uW0Wq8fB2+zx8xIMeocgirxFsPMmUb/F5ahAwS07 oFCgWyhQsr4GTaSVXJTGUzHfyI41ucy7rLxo3eTeYRfEGhRD0xxoRrkkIzveLViErK02e3BVf 8tAqzmtZmFwWVmNmMk7RJsFSw0okR65+25ESXcW+LMJlnS6nIIuWlMrTWKkVusO559Bv9e+Cc XqIjVIoVCw6kzB7bB5/te7UTSNuEiNVjJU25yeP37dwSjKYJQOS6IUxcP/lXTZ6MHcypL65HU rixJbKr7n7+/hZh7f2/+gKvzJxo9q86HeTUk9Zt32t9MvliyfXBabnDMnIWZfGTWjszYjtmXE kJYWsXXPE+bVysJ2X7FjaMrqgfSqb2WV0WsDt52muCX96WPMk5qJV/va2WdrAldeLlXvfnulr jNu+tGZT1sXdR1JXevP4UjRys+LI9wi/wtqdjdB8QMAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-6.tower-96.messagelabs.com!1513366425!115980343!1 X-Originating-IP: [207.46.163.15] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32364 invoked from network); 15 Dec 2017 19:33:45 -0000 Received: from mail-dm3nam03lp0015.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.15) by server-6.tower-96.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Dec 2017 19:33:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZZ7UlUYrtpqGdGi0xgWOqTTPcbB4VuqAnE0xbmJi4Zk=; b=CvfcG01mxSrDtCEMwg7rVZ1omfpA1/ok9Zhta3/MuZ05ZEpmodu4Wc9t6WbmozFjqcPL3tm4ibFP4Wvp0LKIzNyyb4o8nNKa6hE6o/eGS7OPyqm3EmPtVMO/oDPT07EwX7gjRyprVPsb+DfwsTF7FlKCIKTypAasLgVwLfBziw8= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1292.namprd14.prod.outlook.com (10.173.132.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 15 Dec 2017 19:33:44 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0302.012; Fri, 15 Dec 2017 19:33:44 +0000 From: Tim Hollebeek To: Andrei Popov , Ilari Liusvaara CC: "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSnZboSBNXzd9E6O2/oU/bBgd6NDc+yAgAAd44CAAARIAIAAATeAgADhAoCAADa3EYAABbkAgAABmYCAAACsgIAABVAAgAAEZ/+AAAJE8IAAB5AAgAAAUyA= Date: Fri, 15 Dec 2017 19:33:44 +0000 Message-ID: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1292; 6:PofrdohfCHay0Kz1SYPOTzBhvcRLz2/UgOBORG0G750M81S0BDTU1TpKs012d6/OXa8ktH9hibo+zW1SuZZuNhhV550NlRFvDXEMng/Q5/rBjl0CR5hyRXSJw4FymPepD5qj8jGmfe9Lh3oDMt+2FdrTnN+zLhs02S7z3Yoybuf0x2WWbJBjZpijOR4OqZBM0pW3bmDBBSrURnw0yZBbGjWbiLbIy+WVO8pujzIBcVzzxGwlqqr6Izq/+i0FzXaXSl7+SKKy+t9upMkgyMrHhpmuhez9+h6TTIqZPKowabEzJwVzRItdrLP+MzShxCty182Q5bkZeg1TTWfpeqOywmRcdD8umaX1C3Qmd6plCfU=; 5:3JUVLgPmygpXbdfPFFySBbLZW8kzi55PHJw4jQZR4ZlWUOW0sf+Ll5kxe/8cNKLhc2CWrbX4WqUc3zfmhAKuf5XAfVhJWatTWcZB+H+LvonR0EkryQVrXp+FwPUtsahJOGxE4LoITOY3RbiJN3UIU+23oAmQHvNDPBh0QdsiEWY=; 24:tQRyUvt5cbEIIElfSGLFBCOEM94w++Dj5gz/xIzDihIrR/yikQHGDzg4gKTvOGc4DCyO7hyEt5EzXkTG8PJvr+9wQ2Km11G5xStl5ahFKF0=; 7:p2u8vj53a/0GX45NnG+3oITnHCTqkG1Ynb65XZzbqXI4ux7xaVW8Z8FNn3eol1rf6ISjFp/MCIe3ntJY+e661bYzSKP+Q328r5n5JedNLPltOaXZ0AzhpWM4gK0VV30WZWsXgIdaLNyK94SCKNW+mSuzKRrWEmdeRV/sZFYgvsGrtSJf1m7+3fpdw2uZ6HPhdwThwWp1lma2a9QIxpNy3KEe38tdOG3IEFI+DzM1ABspT3MzxEhU0X2qVitE/PD8 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5ff57a15-29ef-4340-e2d2-08d543f2c0ff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(49563074); SRVR:DM5PR14MB1292; x-ms-traffictypediagnostic: DM5PR14MB1292: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6041248)(2016111802025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6043046)(6072148)(201708071742011); SRVR:DM5PR14MB1292; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1292; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(346002)(366004)(376002)(396003)(13464003)(189003)(199004)(8936002)(7696005)(53936002)(68736007)(9686003)(59450400001)(8676002)(305945005)(2906002)(316002)(3660700001)(81166006)(86362001)(2900100001)(76176011)(74316002)(93886005)(7736002)(66066001)(81156014)(3280700002)(2561002)(110136005)(3846002)(14454004)(33656002)(105586002)(478600001)(99936001)(2950100002)(5660300001)(2421001)(102836003)(6436002)(229853002)(25786009)(45080400002)(97736004)(6116002)(106356001)(8666007)(55016002)(99286004)(77096006)(6506007)(6246003)(4326008)(1511001)(53546011)(29543002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1292; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_04AD_01D375A0.EE65EA30" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ff57a15-29ef-4340-e2d2-08d543f2c0ff X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 19:33:44.1153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1292 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 19:33:52 -0000 ------=_NextPart_000_04AD_01D375A0.EE65EA30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Because it's easier for the client to decide what the client understands than it is for the server to decide what the client understands. Less complexity = less failures. Note that this is how XP was handled for code signing. The Authenticode spec actually made it so if you did things in the right order, XP would only see the SHA-1 signature, while more recent operating systems would see both the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the SHA-2 signature. This allowed doubly-signed binaries that worked both on XP and non-XP systems. Unfortunately the technical steps to do so weren't widely publicized, but I know some companies took advantage of it. However, servers are easier to upgrade than clients, which is why you see some of the server side support you mention. I know CloudFlare in particular helped a lot of people cope with communicating with clients who had different certificate capabilities. It isn't a bad thing that both approaches exist. -Tim > -----Original Message----- > From: Andrei Popov [mailto:Andrei.Popov@microsoft.com] > Sent: Friday, December 15, 2017 12:25 PM > To: Tim Hollebeek ; Ilari Liusvaara > > Cc: tls@ietf.org > Subject: RE: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in > general, and what we can do in TLS > > > Ideally, you'd want certificates to be able to have two signatures > > during the transition period, in order to support clients who have > > transitioned and those who have not. > > > Hosting multiple certificates and switching based on the client is > > feasible, but requires some technical wizardry and isn't possible in all > situations. > > For my understanding, why is the former (double-signed certs, where either > signature is trusted) better than the latter (multiple certs with different > algorithms)? > The latter is currently supported by some TLS servers. > > Cheers, > > Andrei ------=_NextPart_000_04AD_01D375A0.EE65EA30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE1MTkzMzM3WjAvBgkqhkiG9w0BCQQxIgQgvp4OBCH5q49rHMeofniyP9O/ap6s JaVQs92c3pe/W10wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFpgiSbvHMBtEVuXLBZghk0DsyFh51DDOmCgD/jcXeZS99RiNIT8GPmN/4UV4q3ph4nWckW7 pZI35YE5Ucgn03Yo8SX3wOnvG8BXqVix5R/QrQRLNwxJnrv7gV/DRE42JReZ6zpp/V54UjGfjN7/ hDIgZ4L/FvNXqHnOZ1rG1ULFmhz+PfGR/c8Cs8zn1dleUWj7I8/W1raJn8oGyGnM6zbhbr9YAM08 ysOelQuSM7/RcNAabUlscVLm7XzOMymrAFK7nwu1BVLScS6PI5Y6AoU8VixitjMIKSXdZdCp/pbF DO7ZBGWhmu68yfdeYkHVt80DZpfHLYRNuob3nWD9jfsAAAAAAAA= ------=_NextPart_000_04AD_01D375A0.EE65EA30-- From nobody Fri Dec 15 11:37: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 ADBE1126DCA for ; Fri, 15 Dec 2017 11:37:40 -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] 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 4DLzRb7Aq6q0 for ; Fri, 15 Dec 2017 11:37:38 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30159126C19 for ; Fri, 15 Dec 2017 11:37:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C86B453728; Fri, 15 Dec 2017 21:37:35 +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 llAcoTdwG3iX; Fri, 15 Dec 2017 21:37:35 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 71F3827F; Fri, 15 Dec 2017 21:37:32 +0200 (EET) Date: Fri, 15 Dec 2017 21:37:32 +0200 From: Ilari Liusvaara To: Tim Hollebeek Cc: Andrei Popov , "tls@ietf.org" Message-ID: <20171215193732.GA18690@LK-Perkele-VII> References: <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 19:37:41 -0000 On Fri, Dec 15, 2017 at 07:14:00PM +0000, Tim Hollebeek wrote: > So, this has been discussed extensively at the CA/Browser forum, for obvious > reasons. > > In my mind, it is not so important to identify and define and implement an > alternative hash. Well, I would think that having ready to go backup would cut fair amount of time from transitions. It should be noted that the two transitions we have seen had backup algorithm already (SHA-1 in case of MD5 and SHA-2 in case of SHA-1). > What *is* important is that the protocol and associated software is able to > support a smooth transition period where people are moving from one > algorithm to another. Yes, that is what I was referring with "backward-compatible algorithm transition". > Ideally, you'd want certificates to be able to have two signatures during > the transition period, in order to support clients who have transitioned and > those who have not. Unfortunately RFC 5280 is deficient in that regard. > Hosting multiple certificates and switching based on the client is feasible, > but requires some technical wizardry and isn't possible in all situations. Yes, there are enormous amount of stacks that have problems with multiple certificate chains. Ranging from OCSP stapling not working properly (Nginx+openSSL) to dual-cert not working at all (too many to list). -Ilari From nobody Fri Dec 15 11:45:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EECB126DCA for ; Fri, 15 Dec 2017 11:45:24 -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] 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 OM-qP2iijfKl for ; Fri, 15 Dec 2017 11:45:22 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4970F126C19 for ; Fri, 15 Dec 2017 11:45:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id AEA84B53D8; Fri, 15 Dec 2017 21:45:20 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id U1WKNNKqCbW6; Fri, 15 Dec 2017 21:45:20 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5D07E2308; Fri, 15 Dec 2017 21:45:17 +0200 (EET) Date: Fri, 15 Dec 2017 21:45:17 +0200 From: Ilari Liusvaara To: Andrei Popov Cc: Tim Hollebeek , "tls@ietf.org" Message-ID: <20171215194517.GB18690@LK-Perkele-VII> References: <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 19:45:24 -0000 On Fri, Dec 15, 2017 at 07:25:20PM +0000, Andrei Popov wrote: > > Ideally, you'd want certificates to be able to have two signatures during > > the transition period, in order to support clients who have transitioned and > > those who have not. > > > Hosting multiple certificates and switching based on the client is feasible, > > but requires some technical wizardry and isn't possible in all situations. > > For my understanding, why is the former (double-signed certs, where either > signature is trusted) better than the latter (multiple certs with different > algorithms)? The latter is currently supported by some TLS servers. Because the latter is only supported by some TLS servers. And even if the TLS server nominally supports multiple certificates, there may be other issues. E.g., OCSP stapling does not work correctly with multiple certificates. -Ilari From nobody Fri Dec 15 11:55: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 41E12124F57 for ; Fri, 15 Dec 2017 11:55:37 -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] 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 qwnFYW7v6LYu for ; Fri, 15 Dec 2017 11:55:35 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CC5124D6C for ; Fri, 15 Dec 2017 11:55:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 352C197AEB; Fri, 15 Dec 2017 21:55:33 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Fe3Zm5ktIFKE; Fri, 15 Dec 2017 21:55:33 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id DFE4A231B; Fri, 15 Dec 2017 21:55:29 +0200 (EET) Date: Fri, 15 Dec 2017 21:55:29 +0200 From: Ilari Liusvaara To: Tim Hollebeek Cc: Andrei Popov , "tls@ietf.org" Message-ID: <20171215195529.GA20237@LK-Perkele-VII> References: <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 19:55:37 -0000 On Fri, Dec 15, 2017 at 07:33:44PM +0000, Tim Hollebeek wrote: > > However, servers are easier to upgrade than clients, which is why you see > some of the server side support you mention. I know CloudFlare in > particular helped a lot of people cope with communicating with clients who > had different certificate capabilities. It isn't a bad thing that both > approaches exist. Also, it should be noted that the past two migrations needed to be compatible with TLS 1.0 and 1.1, which have much less advanced signature negotiation than TLS 1.2 (and 1.3). However, there are enormous amount of very badly configured servers out there, so it is doubtful how quickly things change. -Ilari From nobody Fri Dec 15 15:15: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 D65C9126DEE for ; Fri, 15 Dec 2017 15:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4Mh2aMWSQAy for ; Fri, 15 Dec 2017 15:15:35 -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 D4BA11241FC for ; Fri, 15 Dec 2017 15:15:34 -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 3yz5rP208xz1JS2; Sat, 16 Dec 2017 00:15:33 +0100 (CET) X-purgate-ID: 152705::1513379733-0000088A-A21D674F/0/0 X-purgate-size: 1109 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 3yz5rN642GzGpGl; Sat, 16 Dec 2017 00:15:32 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BA45D404B; Sat, 16 Dec 2017 00:15:32 +0100 (CET) In-Reply-To: References: <20171215020116.04f9ae15@pc1> <20171215143057.GA17121@LK-Perkele-VII> <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> To: Tim Hollebeek Date: Sat, 16 Dec 2017 00:15:32 +0100 (CET) CC: Andrei Popov , Ilari Liusvaara , "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171215231532.BA45D404B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 23:15:37 -0000 Tim Hollebeek wrote: > Because it's easier for the client to decide what the client understands > than it is for the server to decide what the client understands. Less > complexity = less failures. > > Note that this is how XP was handled for code signing. The Authenticode > spec actually made it so if you did things in the right order, XP would only > see the SHA-1 signature, while more recent operating systems would see both > the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the > SHA-2 signature. This allowed doubly-signed binaries that worked both on XP > and non-XP systems. Unfortunately the technical steps to do so weren't > widely publicized, but I know some companies took advantage of it. Now that sounds weird. If I look at the code signatures on my Windows 7 machine, e.g. C:\windows\ccm\CcmExec.exe it carries one single digital signature & timestamp _from_Microsoft_ created 01-November-2017 and both with sha1RSA. So it seems some vendors haven't really started migrating away from SHA-1. -Martin From nobody Fri Dec 15 15:30: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 8FA8A126D73 for ; Fri, 15 Dec 2017 15:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8vRVZn2b1Zq for ; Fri, 15 Dec 2017 15:30:09 -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 072951241FC for ; Fri, 15 Dec 2017 15:30:08 -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 3yz69C0Wztz26HX; Sat, 16 Dec 2017 00:30:07 +0100 (CET) X-purgate-ID: 152705::1513380607-00000805-4996A440/0/0 X-purgate-size: 1252 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 3yz69B6WJ1zGpFj; Sat, 16 Dec 2017 00:30:06 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CF046404B; Sat, 16 Dec 2017 00:30:06 +0100 (CET) In-Reply-To: <20171215195529.GA20237@LK-Perkele-VII> References: <20171215174628.GA17601@LK-Perkele-VII> <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> <20171215195529.GA20237@LK-Perkele-VII> To: Ilari Liusvaara Date: Sat, 16 Dec 2017 00:30:06 +0100 (CET) CC: Tim Hollebeek , "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171215233006.CF046404B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2017 23:30:10 -0000 Ilari Liusvaara wrote: > On Fri, Dec 15, 2017 at 07:33:44PM +0000, Tim Hollebeek wrote: >> >> However, servers are easier to upgrade than clients, which is why you see >> some of the server side support you mention. I know CloudFlare in >> particular helped a lot of people cope with communicating with clients who >> had different certificate capabilities. It isn't a bad thing that both >> approaches exist. > > Also, it should be noted that the past two migrations needed to be > compatible with TLS 1.0 and 1.1, which have much less advanced > signature negotiation than TLS 1.2 (and 1.3). There is an awfully large installed base of borked TLSv1.2 servers. If those servers are equipped with a sha256WithRsaEncryption server cert, the handshake results are: - TLSv1.0 for SSLv3 ClientHello w/ client_version = (3,1) - TLSv1.1 for SSLv3 ClientHello w/ client_version = (3,2) - TLSv1.1 for SSL VERSION 2 CLIENT-HELLO offering (3,3) - chokes and drops network connection for SSLv3 ClientHello w/ client_version = (3,3) i.e. there exists a serious interop problem for TLSv1.2 with such servers, but there is no problem interoperating with TLSv1.0 or TLSv1.1 -Martin From nobody Sat Dec 16 02:21: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 EE5A01242F7 for ; Sat, 16 Dec 2017 02:21:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 optD6H5mkJHd for ; Sat, 16 Dec 2017 02:21:35 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A4D1205F1 for ; Sat, 16 Dec 2017 02:21:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9231F41895; Sat, 16 Dec 2017 12:21:32 +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 z_2tqzH48EU7; Sat, 16 Dec 2017 12:21:32 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2555EC4; Sat, 16 Dec 2017 12:21:29 +0200 (EET) Date: Sat, 16 Dec 2017 12:21:28 +0200 From: Ilari Liusvaara To: Martin Rex Cc: Tim Hollebeek , "tls@ietf.org" Message-ID: <20171216102128.GA22257@LK-Perkele-VII> References: <20171215183424.GA17780@LK-Perkele-VII> <20171215184951.GB17780@LK-Perkele-VII> <20171215195529.GA20237@LK-Perkele-VII> <20171215233006.CF046404B@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171215233006.CF046404B@ld9781.wdf.sap.corp> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2017 10:21:38 -0000 On Sat, Dec 16, 2017 at 12:30:06AM +0100, Martin Rex wrote: > Ilari Liusvaara wrote: > > On Fri, Dec 15, 2017 at 07:33:44PM +0000, Tim Hollebeek wrote: > >> > >> However, servers are easier to upgrade than clients, which is why you see > >> some of the server side support you mention. I know CloudFlare in > >> particular helped a lot of people cope with communicating with clients who > >> had different certificate capabilities. It isn't a bad thing that both > >> approaches exist. > > > > Also, it should be noted that the past two migrations needed to be > > compatible with TLS 1.0 and 1.1, which have much less advanced > > signature negotiation than TLS 1.2 (and 1.3). > > There is an awfully large installed base of borked TLSv1.2 servers. > > If those servers are equipped with a sha256WithRsaEncryption server cert, > the handshake results are: > > - TLSv1.0 for SSLv3 ClientHello w/ client_version = (3,1) > - TLSv1.1 for SSLv3 ClientHello w/ client_version = (3,2) > - TLSv1.1 for SSL VERSION 2 CLIENT-HELLO offering (3,3) > - chokes and drops network connection > for SSLv3 ClientHello w/ client_version = (3,3) > > i.e. there exists a serious interop problem for TLSv1.2 with such servers, > but there is no problem interoperating with TLSv1.0 or TLSv1.1 What I meant is that in TLS 1.2, one could signal the client transition status, whereas that is not possible in TLS 1.0 and 1.1. E.g. suppose we need to transition from SHA-2 to SHA-3. Pre-transition: signature_algorithms=...,ecdsa_secp256r1_sha256,... In-transition: signature_algorithms=...,ecdsa_secp256r1_sha3256,ecdsa_secp256r1_sha256,... Post-transition: signature_algorithms=...,ecdsa_secp256r1_sha3256,... And server with apropriate SHA-3 certificate chain can send it to the client. The similar works across signature algorithms. But this is not possible with TLS 1.0 and 1.1 without very nasty hacks. However, as noted, many servers do not correctly deal with having two certificates at the same time. Or server owners think it is too difficult to deal with them. Dual-signature certificates would be valuable for those cases. -Ilari From nobody Mon Dec 18 11:35:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7FD12D862 for ; Mon, 18 Dec 2017 11:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=amoPl2Q6; dkim=pass (1024-bit key) header.d=chromium.org header.b=jQkbK1r4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqEoOsoE5y_g for ; Mon, 18 Dec 2017 11:35:34 -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 7215112D853 for ; Mon, 18 Dec 2017 11:35:34 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id r184so12091059qke.8 for ; Mon, 18 Dec 2017 11:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=+ZA7RHknDpaubGY2ox0ks9cxQGe1zSUuRW1i9E8bDao=; b=amoPl2Q61IUB1r0x3kmOxP7rhPUKDX+7zL3pZAqczPs/b1Qh4tCwyWpQn+vimIah/G 5LFEHr2FywNTw3h6B8UUyxKnov9YdzBzVf+tiJhwq71JHI5Y9hyd8tzgTUIRGr2wu5Ke brlG4qzoWl8ATn3XOLzTAQSNBEkaPG61yvJde6HmEbBbsyrq4O5YgZym+htHUzlKaoW3 SQhR3my3rFZ6XUCrD9DmizGaaddEIlDNa4ow4YWgwsBJpkWSDbe0YCzMsknTSS6o/UNw NLxR1mJ11vgIJEM5/U+NKym9CBITzuhii9dJLAPLl45zKATkJDgaI/XisyFQ3l/ygW/+ rr4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=+ZA7RHknDpaubGY2ox0ks9cxQGe1zSUuRW1i9E8bDao=; b=jQkbK1r41oaJnrsUMZOqG5XDFuw0oZMVxsHTMhM9YFuZR2D7ohxv2V+bH6kYGSmh6c PhnxVgDirlUbQ9IePY23OTa8Z3kbESGqYvXikfmWRSVONKTo4rtfhBRl2zgnd2wWvIxq DbvHG9dmru5h7yasePBoDnkbU/OhsAIOxPcEo= 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:content-transfer-encoding; bh=+ZA7RHknDpaubGY2ox0ks9cxQGe1zSUuRW1i9E8bDao=; b=orKDOcCkVcyV8H6Hl/fMr8XM7CCvrJOawsM38T21kuz3GMjhyYQeq0XYHRNcMVuOFB kT013++GApdNjyh3Rtk6WV98jLKD2JuLAxUZd09liKu3bTsHJZnIpXE2VL9mlnJDwAJI T/FopEBA7SIY3rn92bLKrzIt+yr3LBYpANA0VfCZoZiVZZQPKXhxknRjqbplW81e+XCb vlBjXaZHClMtowKIz6BoZkKFVmhZi229sX6B90WJtniKXEy7G1AOza/Al+C4fBg24PMj 9P4kaEOeBNANY0XvTNon10wt1xiTaOmytjiwUB80YjKDg8Y9u3KiZ5p3pb9vVAoBxbnU jQwA== X-Gm-Message-State: AKGB3mIssHpKjHdQ5y2h6cp47EwtaHsaZhLwcTVpj9dNJqMzkr31NBNp lEpPHWO5uKuQi4GyArEiiuBZFLgPgeCMEebIlPoFBr3Q0w== X-Google-Smtp-Source: ACJfBovGhIqynhpQxY4CpnJpQZmUX3a7hiebH84MttGvh/A5HyqlcAQA7g+Yu88FUcAC2a3RN8jShsWe47L2XZTpqVo= X-Received: by 10.55.181.66 with SMTP id e63mr1284938qkf.130.1513625732997; Mon, 18 Dec 2017 11:35:32 -0800 (PST) MIME-Version: 1.0 Sender: davidben@google.com Received: by 10.237.57.10 with HTTP; Mon, 18 Dec 2017 11:35:12 -0800 (PST) From: David Benjamin Date: Mon, 18 Dec 2017 14:35:12 -0500 X-Google-Sender-Auth: M8Y0SaMjUs7OwyoCYxNJMfCXAbk Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2017 19:35:36 -0000 Dear all, The recent release of Google Chrome 63 enabled (effectively) TLS 1.3 draft 22 for 95% of stable channel users who updated. (Our previous results were on our beta channel.) While, in the past, we have demurred[1] from providing details about problematic products we now plan to alter that stance. It is late in the game for TLS 1.3 and we have likely exhausted the scope of wire-format tricks to improve deployment viability (although there is one more helpful tweak below). Since other vendors will also be seriously deploying TLS 1.3 soon, we want to share all that we have learned from Chrome. We note, however, that even being included in a stable release of Google Chrome doesn=E2=80=99t provide a full picture of any issues. For example, enterprise customers may choose not to release any new versions of software into their organisations in the run-up to Christmas and New Year=E2=80=99s. Also, we are aware that only a tiny fract= ion of issues result in user reports. This experiment in Chrome 63 will end on 2017-12-19, hopefully ensuring a quiet Christmas. BSAFE The web interface on some Canon printers breaks with 1.3-capable ClientHello messages. We have purchased one and confirmed this with a PIXMA MX492. User reports suggest that it also affects PIXMA MG3650 and MX495 models. It potentially affects a wide range of Canon printers. These printers use the RSA BSAFE library to implement TLS and this library implements the extended_random extension and assigns it number 40. This collides with the key_share extension and causes 1.3-capable handshakes to fail. We understand that this has been fixed in BSAFE =E2=89=A5 4.1, but older versions still exist in the world. Canon is aware of this and is planning on issuing firmware updates, although the uptake of firmware for printers is typically poor. However, since extension numbers are essentially infinite, this WG may consider renumbering key_share to avoid the issue. Dymo (the label-printer manufacturer) is experiencing a similar[2] issue with some of their software. We have not been able to reproduce but one guess is that they are also using BSAFE. (Lastly, we note that in the paper "On the Practical Exploitability of Dual EC in TLS Implementations", the authors remarked that they had no evidence that a version of BSAFE with extended_random support ever shipped. TLS 1.3 appears to have tripped over it.) Cisco Firepower After receiving a report of issues with a Cisco =E2=80=9CFirepower=E2=80=9D= device we purchased one to try and reproduce the issue. We found that Firepower middleboxes in "Decrypt - Resign" mode terminate TLS connections, but do not send a compliant ClientHello: They modify the original ClientHello to remove unknown ciphersuites, EMS, and NPN, but incorrectly forward most other fields from the original ClientHello, including unknown extensions (supported_versions and key_shares), and the client random. This breaks TLS 1.3 servers. Additionally, these devices forward the server random rather than generating their own (which will break when deploying the TLS 1.3 anti-downgrade feature), and forward unknown signature algorithms (which will break when deploying, e.g., Ed25519). Disabling "Decrypt - Resign" mode appears to work around this issue. To fix this mode, these devices will need to stop forwarding unknown extensions and generate their own random values. We have provided Cisco with this information. Avast Antivirus We have received one report that Avast=E2=80=99s HTTPS scanning feature bre= aks connections that negotiate TLS 1.3. The user reported that disabling HTTPS scanning solved the issue. We were not able to reproduce so this might only occur with older versions of Avast. [1] https://www.ietf.org/mail-archive/web/tls/current/msg24535.html [2] http://developers.dymo.com/2017/12/12/err_ssl_version_interference-in-c= hrome-63-using-the-js-sdk/ From nobody Mon Dec 18 13:04:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB32912D940 for ; Mon, 18 Dec 2017 13:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 g5CLY59gdlhO for ; Mon, 18 Dec 2017 13:04:48 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94FF12D953 for ; Mon, 18 Dec 2017 13:04:33 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id c15so3330651ybl.0 for ; Mon, 18 Dec 2017 13:04:33 -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=5v4H+nnaSIwHONk4YV5yQmT3LAP2sTc3Xx0rzNhBAIE=; b=wi+qcLar6fVyHI4I2aUseqEAU+IX1mJ+XqVJiEGSpZhCEc0mPq4iG0F0PUv+qfEHIB 4Ze6uHETv9jtppPNW4RTdWkxFQAlBSLKqTNd8idqufT3K0nFJjTVFy8nBCpub5dTIl4E zvcGHMrbnp0DOVhEc5o/fmb21SFdcKD4jGAAznZ2sbSsXhUdgI5IfqtI+S6sroWjtRum 2ivqKjgfZMTZlmnFeNJOc4h/1mgQFYKkI4p6psQGve3Xc4lUYtKziy9KHYh4Y2or2erM D6jmEhd02nbNozdloGbElOq9kRMK9uh+isxq+x/86GyRiZCh3lieLCOXQ718h+4GBPsV aSWA== 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=5v4H+nnaSIwHONk4YV5yQmT3LAP2sTc3Xx0rzNhBAIE=; b=uWU/y5i68my5qguy4ckbj4vcW4iZICEIh8TmpeX+VwqhnEMYbzCnw8G/irfTlmDuz2 vcXlCIhiJkiyWL4TbKAcQFjLipzvyJP43oW9q5GJl5iieGvOkm2GZGb2yThGFawwiLkt JWGJE188L5V/eiAZVN/GSnO+Dl3f5Sla0inm8IDmToxUIuk3UdfOJMlB9fB59uNK6Zyr Z+6iox/fZPI8YZWA/qEn9Deq1b7wpKNLqj82ESGXbDJRzloUobI5R3gw+Yu1D7PgWQ69 BuYEpebAvoHcZpKjSv1kxDJeEMe2nYMlXzL12B/fkY2XKuFgR3Y15UxFh3t3HgmT/YHm H55A== X-Gm-Message-State: AKGB3mJUJZXmGXj/4GmE6t2/gJfDLwgRLGgRLzqdHyztNxIeK0gM7WSl rX4FLC1BpkRZ14zyc4LtnMPDBvRdaRzEtWOosFtsRQ== X-Google-Smtp-Source: ACJfBotFTURSEp0/6MQgJ0AarV+ROFnh7OkkflfP3oLS/+LZfPYNNivPp4uWaJZJdqhefeIDQb+NUrsTN4LTDkaYDF0= X-Received: by 10.37.230.195 with SMTP id d186mr887200ybh.497.1513631073092; Mon, 18 Dec 2017 13:04:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Mon, 18 Dec 2017 13:03:52 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 18 Dec 2017 13:03:52 -0800 Message-ID: To: David Benjamin Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b00c06ec9cf0560a3b2b5" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2017 21:04:51 -0000 --94eb2c0b00c06ec9cf0560a3b2b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 18, 2017 at 11:35 AM, David Benjamin wrote: > > > The web interface on some Canon printers breaks with 1.3-capable > ClientHello messages. We have purchased one and confirmed this with a > PIXMA MX492. User reports suggest that it also affects PIXMA MG3650 > and MX495 models. It potentially affects a wide range of Canon > printers. > > These printers use the RSA BSAFE library to implement TLS and this > library implements the extended_random extension and assigns it number > 40. This collides with the key_share extension and causes 1.3-capable > handshakes to fail. > > We understand that this has been fixed in BSAFE =E2=89=A5 4.1, but older > versions still exist in the world. Canon is aware of this and is > planning on issuing firmware updates, although the uptake of firmware > for printers is typically poor. > > However, since extension numbers are essentially infinite, this WG may > consider renumbering key_share to avoid the issue. > I think this would be fine, but not imperative. -Ekr > > Dymo (the label-printer manufacturer) is experiencing a similar[2] > issue with some of their software. We have not been able to reproduce > but one guess is that they are also using BSAFE. > > (Lastly, we note that in the paper "On the Practical Exploitability of > Dual EC in TLS Implementations", the authors remarked that they had no > evidence that a version of BSAFE with extended_random support ever > shipped. TLS 1.3 appears to have tripped over it.) > > Cisco Firepower > > After receiving a report of issues with a Cisco =E2=80=9CFirepower=E2=80= =9D device we > purchased one to try and reproduce the issue. > > We found that Firepower middleboxes in "Decrypt - Resign" mode > terminate TLS connections, but do not send a compliant ClientHello: > They modify the original ClientHello to remove unknown ciphersuites, > EMS, and NPN, but incorrectly forward most other fields from the > original ClientHello, including unknown extensions (supported_versions > and key_shares), and the client random. This breaks TLS 1.3 servers. > Additionally, these devices forward the server random rather than > generating their own (which will break when deploying the TLS 1.3 > anti-downgrade feature), and forward unknown signature algorithms > (which will break when deploying, e.g., Ed25519). > > Disabling "Decrypt - Resign" mode appears to work around this issue. > To fix this mode, these devices will need to stop forwarding unknown > extensions and generate their own random values. > > We have provided Cisco with this information. > > Avast Antivirus > > We have received one report that Avast=E2=80=99s HTTPS scanning feature b= reaks > connections that negotiate TLS 1.3. The user reported that disabling > HTTPS scanning solved the issue. We were not able to reproduce so this > might only occur with older versions of Avast. > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg24535.html > [2] http://developers.dymo.com/2017/12/12/err_ssl_version_ > interference-in-chrome-63-using-the-js-sdk/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0b00c06ec9cf0560a3b2b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 18, 2017 at 11:35 AM, David Benjamin <= davidben@chromiu= m.org> wrote:


The web interface on some Canon printers breaks with 1.3-capable
ClientHello messages. We have purchased one and confirmed this with a
PIXMA MX492. User reports suggest that it also affects PIXMA MG3650
and MX495 models. It potentially affects a wide range of Canon
printers.

These printers use the RSA BSAFE library to implement TLS and this
library implements the extended_random extension and assigns it number
40. This collides with the key_share extension and causes 1.3-capable
handshakes to fail.

We understand that this has been fixed in BSAFE =E2=89=A5 4.1, but older versions still exist in the world. Canon is aware of this and is
planning on issuing firmware updates, although the uptake of firmware
for printers is typically poor.

However, since extension numbers are essentially infinite, this WG may
consider renumbering key_share to avoid the issue.
I think this would be fine, but not imperative.

<= /div>
-Ekr
=C2=A0

Dymo (the label-printer manufacturer) is experiencing a similar[2]
issue with some of their software. We have not been able to reproduce
but one guess is that they are also using BSAFE.

(Lastly, we note that in the paper "On the Practical Exploitability of=
Dual EC in TLS Implementations", the authors remarked that they had no=
evidence that a version of BSAFE with extended_random support ever
shipped. TLS 1.3 appears to have tripped over it.)

Cisco Firepower

After receiving a report of issues with a Cisco =E2=80=9CFirepower=E2=80=9D= device we
purchased one to try and reproduce the issue.

We found that Firepower middleboxes in "Decrypt - Resign" mode terminate TLS connections, but do not send a compliant ClientHello:
They modify the original ClientHello to remove unknown ciphersuites,
EMS, and NPN, but incorrectly forward most other fields from the
original ClientHello, including unknown extensions (supported_versions
and key_shares), and the client random. This breaks TLS 1.3 servers.
Additionally, these devices forward the server random rather than
generating their own (which will break when deploying the TLS 1.3
anti-downgrade feature), and forward unknown signature algorithms
(which will break when deploying, e.g., Ed25519).

Disabling "Decrypt - Resign" mode appears to work around this iss= ue.
To fix this mode, these devices will need to stop forwarding unknown
extensions and generate their own random values.

We have provided Cisco with this information.

Avast Antivirus

We have received one report that Avast=E2=80=99s HTTPS scanning feature bre= aks
connections that negotiate TLS 1.3. The user reported that disabling
HTTPS scanning solved the issue. We were not able to reproduce so this
might only occur with older versions of Avast.

[1] https://www.ietf.org/mail-ar= chive/web/tls/current/msg24535.html
[2] http://developers.dymo.com/2017/12/12/err_ssl_version_interferen= ce-in-chrome-63-using-the-js-sdk/

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

--94eb2c0b00c06ec9cf0560a3b2b5-- From nobody Mon Dec 18 15:14: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 2BB2B12D94F for ; Mon, 18 Dec 2017 15:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 0wfNxw9JjiUi for ; Mon, 18 Dec 2017 15:14:25 -0800 (PST) Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 7CAB612AF77 for ; Mon, 18 Dec 2017 15:14:25 -0800 (PST) Received: (qmail 24820 invoked from network); 18 Dec 2017 23:14:23 -0000 Received: from ein.win.tue.nl (HELO hyperelliptic.org) (131.155.70.18) by cr.yp.to with SMTP; 18 Dec 2017 23:14:23 -0000 Received: (qmail 28243 invoked by uid 1004); 18 Dec 2017 23:08:06 -0000 Date: Tue, 19 Dec 2017 00:08:06 +0100 From: Tanja Lange To: David Benjamin Cc: tls@ietf.org Message-ID: <20171218230806.GX29571@ein.win.tue.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2017 23:14:27 -0000 Dear David, dear all, > These printers use the RSA BSAFE library to implement TLS and this > library implements the extended_random extension and assigns it number > 40. This collides with the key_share extension and causes 1.3-capable > handshakes to fail. > [..] > > (Lastly, we note that in the paper "On the Practical Exploitability of > Dual EC in TLS Implementations", the authors remarked that they had no > evidence that a version of BSAFE with extended_random support ever > shipped. TLS 1.3 appears to have tripped over it.) > Wow, thanks for finding this, it was really baffling us. All the best Tanja From nobody Mon Dec 18 17:59: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 284E012D95C for ; Mon, 18 Dec 2017 17:59:41 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLt1aOFWyp9v for ; Mon, 18 Dec 2017 17:59:39 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986BF1201FA for ; Mon, 18 Dec 2017 17:59:39 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJ1urSa009577; Tue, 19 Dec 2017 01:59:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=yVFaIj7YpeT7kMUVnCKQCtNbApnXKUf5WqdKn3HkM6w=; b=IN+Etxx3HQB8uQnS7RmDam6V3/W9LDm5lSg4saHrGYbCX2ZDjijavCS2B2fdKwnix+Hs 0Fj1soPr7LUScxeQ6Ynkd/A69SUi3kQV1NFQ2Db5IvqkB9r/mcF3ZneXue1q+DKkLEeL g0LXxEDcuZAEkfL+4UpifYddmZFS3f/EtgZZ6PSh2ERpgSns8IJy3udgH5ICtE7iLHaq vQQRwf+oplkxZJmXZEuAeeRyBn0U+HLO8HD6krzLp+hH3t3SzLGfTIGEMQmVgV5RhkvQ 2gAlDOzm8kstyjO/J9WoMXBx2Fj7RmCL6WnhvS3sADCCX/7yjjC5hVTvNhRP66pfi4YR ww== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2evvdkqgnd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 01:59:36 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJ1uUJF009516; Mon, 18 Dec 2017 20:59:35 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2evyq0wxmf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Dec 2017 20:59:35 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Dec 2017 20:59:34 -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.1263.000; Mon, 18 Dec 2017 20:59:34 -0500 From: "Salz, Rich" To: Eric Rescorla , David Benjamin CC: "tls@ietf.org" Thread-Topic: [TLS] Additional TLS 1.3 results from Chrome Thread-Index: AQHTeDdl/fJZIooONU+btb84ey8Do6NJ6s0AgABSnIA= Date: Tue, 19 Dec 2017 01:59:34 +0000 Message-ID: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.59] Content-Type: multipart/alternative; boundary="_000_68370EF88F21435C98F0D621D142C629akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=737 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=679 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190023 Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2017 01:59:41 -0000 --_000_68370EF88F21435C98F0D621D142C629akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93ZXZlciwgc2luY2UgZXh0ZW5zaW9uIG51bWJlcnMgYXJlIGVzc2VudGlhbGx5IGluZmluaXRl LCB0aGlzIFdHIG1heQ0KY29uc2lkZXIgcmVudW1iZXJpbmcga2V5X3NoYXJlIHRvIGF2b2lkIHRo ZSBpc3N1ZS4NCg0KPiBJIHRoaW5rIHRoaXMgd291bGQgYmUgZmluZSwgYnV0IG5vdCBpbXBlcmF0 aXZlLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGFsbW9zdCBiZSBoeXBvY3JpdGljYWwgaWYgd2UgZGlk IG5vdCBkbyBpdC4NCg0K --_000_68370EF88F21435C98F0D621D142C629akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <70E6C97540A0C14493507CA0EFF7366D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBzaW5jZSBleHRlbnNpb24g bnVtYmVycyBhcmUgZXNzZW50aWFsbHkgaW5maW5pdGUsIHRoaXMgV0cgbWF5PGJyPg0KY29uc2lk ZXIgcmVudW1iZXJpbmcga2V5X3NoYXJlIHRvIGF2b2lkIHRoZSBpc3N1ZS48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSB0aGluayB0aGlzIHdvdWxk IGJlIGZpbmUsIGJ1dCBub3QgaW1wZXJhdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRoaW5rIGl0IHdvdWxkIGFsbW9zdCBiZSBoeXBvY3JpdGljYWwgaWYgd2UgZGlkIG5v dCBkbyBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_68370EF88F21435C98F0D621D142C629akamaicom_-- From nobody Tue Dec 19 05:07: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 4CC7C127023 for ; Tue, 19 Dec 2017 05:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9TYIl1bIOWxL for ; Tue, 19 Dec 2017 05:07:06 -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 6E664126CD6 for ; Tue, 19 Dec 2017 05:07:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BFE9BE5C; Tue, 19 Dec 2017 13:07:04 +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 7B96lMIdjl4x; Tue, 19 Dec 2017 13:07:03 +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 B52F4BDD8; Tue, 19 Dec 2017 13:07:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513688823; bh=D5G2wOrd4uYZQy4/24/Bd6Y/ZKr8sElpTAOF2/VWoj4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FEN8kPi5ADQ6GjOzLBeXuago9Q6YzMdTyEoWU4VYZ+uRZ+H3LlQbbT78RuhjlKtIq h3IsN6FUJumeJgN+Ey8NGe+BZnRjbjlEcl/gLOUv2UdyL+VbIZgJO57N9GMfjLWAPO gfQH7jb3UG6InHbG1EOV2PQXXJkqiA6/exgiMpnk= To: "Salz, Rich" , Eric Rescorla , David Benjamin Cc: "tls@ietf.org" References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> Date: Tue, 19 Dec 2017 13:07:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q3ArNAr6mt9Grb3iiRW5VRtvCcViooug6" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2017 13:07:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q3ArNAr6mt9Grb3iiRW5VRtvCcViooug6 Content-Type: multipart/mixed; boundary="4vbTrOTlMGgSS6lGjupj6r0HnjB8D1Irp"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Eric Rescorla , David Benjamin Cc: "tls@ietf.org" Message-ID: <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> Subject: Re: [TLS] Additional TLS 1.3 results from Chrome References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> In-Reply-To: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> --4vbTrOTlMGgSS6lGjupj6r0HnjB8D1Irp Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 19/12/17 01:59, Salz, Rich wrote: > However, since extension numbers are essentially infinite, this WG may > consider renumbering key_share to avoid the issue. >=20 >> I think this would be fine, but not imperative. >=20 > I think it would almost be hypocritical if we did not do it. >=20 I'm not sure I agree renumbering is the right reaction, though I don't object to that. This could be a case where it's overall better that those specific devices suffer breakage, and hopefully then do get firmware updated to support TLS1.3 or TLS-without-extended-random-or-dual-ec at some point. WRT extended-random, it seems like the IETF process did work, in that we dropped the work. However, it may also be the case that the attacker's process (if one assumes that somewhere in the background (*) there was an attacker who wanted dual-ec attacks to be more efficient) also worked to at least some extent in that they got that to be deployed in some places, presumably at least partly based on the existence of the (then expired?) draft. I wonder if that argues for some kind of "dropped as a very bad idea" tombstone draft (or even RFC) for such cases? I can imagine that the IETF or TLS WG could do that, but I'm not sure if it'd have helped the developers of bsafe or those printers avoid the problem if such a thing had existed. In the case of extended-random, it is now clear that it is a very bad idea, even if that wasn't the case when the WG chose to not proceed with the work, so such a tombstone draft or RFC could be easily done and could possibly be useful. (I'm about half-convinced of that;-) One reason to think about this is that we have some more-current bad-idea drafts (e.g. draft-green) that we know are dead, but folks not involved in the WG might not be aware of that, so it could be good if those were somewhat more officially put to rest than just sitting forever as expired I-Ds. It'd be a fine thing if the authors of such drafts did that themselves of course, but if not, I'd volunteer to help:-) Cheers, S. (*) To be clear, I am not at all saying the authors of the extended-random draft were part of any attack. If I were the bad actor in such a case, I'd ensure the names that were public weren't in on the plan. --4vbTrOTlMGgSS6lGjupj6r0HnjB8D1Irp-- --Q3ArNAr6mt9Grb3iiRW5VRtvCcViooug6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaOQ72AAoJEC88hzaAX42iSK0H/0XR0ZdeSVbkffw2LQ/iT2Fc 5emhix96E8Mx4zICtqmoMv5k1Mxz/7np7co5wR1/zELEfWM7B9G9K0SXmEr+7k2q g1EclS9OX/IkEvvKDMuWhOzrrLWJO7SP0SATXMyTX+sKg/oCzBfc9Q4A1G+9zlcj DmN9OgXmpHaMElM+znkazeI8KlRrgmoRCRQFc0kIWnLa1tbjxT+YDXdBa3WEmPqN j0qs6tTrlTjBWdLop5sf+b7DQeE+YahE5uvF3pWR2M8voeSITQE/umzmPEmxGjcw q4SVGvM1IroxsFvT0eXDDlH0An6pgh1OYvdC59lyaP0KZidpZ+JVUdHX631S6l0= =ShAN -----END PGP SIGNATURE----- --Q3ArNAr6mt9Grb3iiRW5VRtvCcViooug6-- From nobody Tue Dec 19 05:57: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 DBF5F12711B for ; Tue, 19 Dec 2017 05:57:01 -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 (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcOPBgyd9lI2 for ; Tue, 19 Dec 2017 05:57:00 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4B1126579 for ; Tue, 19 Dec 2017 05:57:00 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJDpUgl008565; Tue, 19 Dec 2017 13:56:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=zz4hEo4uoyD1r3g+xu3nJJFj9gubL7B6G9mrF4EJKFI=; b=YlrUINWm+ecfECQFAhiAcVxoyVn135lgvWZrvmJWP/38S0QpkYZFO80HijjWKu7T0Td7 eHbMGu7kIJqq3zDG6LDql5MWvHL5rlXWiTgs13AjtJQVjqHyL8oTjJGaQWTDcE6gkiQL bjIcHLc/8O8JVOW2fztwX/YNiUXqzb997vOvIyMnjzQTInxWEgO65W9rWxxH6TcvH+fv ReEIFV6lU96gGfeULYWeT80hvP5fVUonMAPRG4m3Ndo3bBJlngYIHOXiDapzAtLkbBOU gsYzMIOk92Frl5R24Ip2EoR9N2chdixBm0FbYpQs9hDdPm0UVyIhA8uBjusjJ50oBqRT 9g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2evum917gx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 13:56:53 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJDuBgp030189; Tue, 19 Dec 2017 08:56:52 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2evyqdv7nd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 08:56:52 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Dec 2017 08:56:51 -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.1263.000; Tue, 19 Dec 2017 08:56:51 -0500 From: "Salz, Rich" To: Stephen Farrell , Eric Rescorla , David Benjamin CC: "tls@ietf.org" Thread-Topic: [TLS] Additional TLS 1.3 results from Chrome Thread-Index: AQHTeDdl/fJZIooONU+btb84ey8Do6NJ6s0AgABSnICAALp/AIAADeoA Date: Tue, 19 Dec 2017 13:56:50 +0000 Message-ID: <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com> References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> In-Reply-To: <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.178] Content-Type: text/plain; charset="utf-8" Content-ID: <2F786C442FC5AE428D1EA747047D0A9E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=722 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=652 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190200 Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2017 13:57:02 -0000 4oCcZHJvcHBlZCBhcyBhIGJhZCBpZGVh4oCdIGlzIGFuIGludGVyZXN0aW5nIGVuZC1zdGF0ZS4g IEFsc28g4oCcb24gaG9sZCBmb3Igbm934oCdICh3aGljaCBpcyBob3cgSSB3YW50IHRvIHNlZSB0 aGUgVExTLWJyZWFraW5nIHByb3Bvc2FscykuDQoNCkhhdmluZyBtb3JlIEktRCB3b3JrZmxvdyBv cHRpb25zIHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoZSBJRVNHIHNob3VsZCB0YWtlIHVwLiAgDQog DQoNCg== From nobody Tue Dec 19 06:19: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 80958126DFE for ; Tue, 19 Dec 2017 06:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pdqhzrMBLxlJ for ; Tue, 19 Dec 2017 06:19:46 -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 AD0341201F8 for ; Tue, 19 Dec 2017 06:19:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5F071BE51; Tue, 19 Dec 2017 14:19:43 +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 pP9iPbNIGn6X; Tue, 19 Dec 2017 14:19:43 +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 12450BE39; Tue, 19 Dec 2017 14:19:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513693183; bh=bgHw+JK/dWqa/kbz9Y38pBdt1Azr73wLHk0Z5FPjMZ4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OlxzNpqj/ZZ42HfkaGukN2leM7BlhtSI+1fBHyvRMjy3SF9YfHmLxfEeU0Tf4BhQS R3aJ8GwuS/4SDnrG3Io6JnwZs6bIXvHSmgDaLor2XYL3McWQ4xVI8Eu29iZR4nsABI t45rvtJEV3VdTzzwNJCEKTdc9bLOhSsOduy9UKX8= To: "Salz, Rich" , Eric Rescorla , David Benjamin Cc: "tls@ietf.org" References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 19 Dec 2017 14:19:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3MJUMaqTNM441VTGNESV04Qwvx3QUAVNH" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2017 14:19:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3MJUMaqTNM441VTGNESV04Qwvx3QUAVNH Content-Type: multipart/mixed; boundary="5lg7xl2idPl11k85Xf0pPGguc2nfs6kGw"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Eric Rescorla , David Benjamin Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com> In-Reply-To: <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com> --5lg7xl2idPl11k85Xf0pPGguc2nfs6kGw Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 19/12/17 13:56, Salz, Rich wrote: > =E2=80=9Cdropped as a bad idea=E2=80=9D is an interesting end-state. A= lso =E2=80=9Con hold > for now=E2=80=9D (which is how I want to see the TLS-breaking proposals= ). >=20 > Having more I-D workflow options seems like something the IESG should > take up. >=20 Well, TBH I doubt it'd be best done from the IESG down. If some WG wanted to pursue this kind of thing, I'd say it'd be much better done by the WG and then the IESG could get to decide what they think if/when such a draft is ever put forward by the WG for publication as an RFC. And for most WGs, there's little danger in expired I-Ds hanging about unchanged. For TLS, as we've seen in this case, there might be a downside to the expired I-D not containing text saying: "Don't do this! Really. And why." :-) As an aside, I'd say it'd be better to not think of this as a retraction, but more as a case of ensuring that the public record, as seen in the I-D repository, better reflects the WG consensus, for the few cases where there would be a concrete reason to not want people to write or deploy code implementing the draft concerned. For a WG draft, the WG itself can always decide that the right thing to happen is to publish a tombstone draft, so that could be handled easily enough. For a draft that's proposed for WG adoption, or that's discussed but not adopted, it might get complicated, if the authors don't agree that WG non-adoption is a good reason to put out a tombstone. (We'd likely need the WG to adopt the draft solely to put out the tombstone, which'd be a bit weird.) So as I said, I'm about half-convinced:-) Cheers, S. --5lg7xl2idPl11k85Xf0pPGguc2nfs6kGw-- --3MJUMaqTNM441VTGNESV04Qwvx3QUAVNH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaOR/9AAoJEC88hzaAX42isDcH/RRHgdMpGfgBCAZ/zfzaKf1S zkNCkNhjp0w4aRphy1XhqV8GWU8Td7zzFDbaj8Zn71d1fRZruEmCm8fPPKXypg94 k4UnmtDvLbSOVrIO/j5skxaSToOWcT2cJYiGYMDGzJUBkDIWOqOdm+6whfjI6Avh a5QUehXktFc7tc0aICkPP9suzM8vhGjO7o/OEfi1op2ertRfHj66YG226Tc0JlVM ak1FBiUSLTCEySE6Pct+PbqAqfoatwWTVabn+bVV/Ys8DYltS8Jgw1auJkVdF7XV NuxWc/R1z1i1IMp+DzqIUPZrOWflFtRxZ8SRfWNWN6GxlRvNnxGmrHcLFxyphnI= =+6PT -----END PGP SIGNATURE----- --3MJUMaqTNM441VTGNESV04Qwvx3QUAVNH-- From nobody Tue Dec 19 07:08: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 52F74129C6C for ; Tue, 19 Dec 2017 07:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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=-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=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hfPpjWfImN5 for ; Tue, 19 Dec 2017 07:08:34 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 639821241FC for ; Tue, 19 Dec 2017 07:08:34 -0800 (PST) Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-8.messagelabs.com id CE/B0-03583-17B293A5; Tue, 19 Dec 2017 15:08:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGe2em05FQM0xRjg2N2sQFtA1GiQU 10RdTH0x8UytRBx1ptS21UxTDg3WXVhRjUaxAwaCQYgUV41LRUKugRAQUY1xiCGAEJEQRxd2O U1zevnv+P+c/d6NwZohUUlyug7NbWbOajCGeTrlcp7HNSjOkBL/M1gVHUnXVA60y3c/6fEJ3o uGJTPf+oQstluqPhctx/SlnO6EPuDtJfWXlZ0x/rHs/vkJqkJqsmdm566XGls4DMtvxhbnBwB 7SifzpLhRDEfQQBtfDvYSwYGgPBlWu29FFGMFXd6vMhcZRJJ0CTxqaMEGIp4sRtJ73kIKA01N hqKOMEFhBp0H96BskcDydDtdKG6O8FArquiONqEjeNCi7NFsoy+kMqG/yy8Swrwg+7n0sFYRx 9CLwFOzDBUb0RPh0/xwmZiXAsx7fbwY6HrraW0iRJ0Bf9w+p6M+A0uFQtK6G54FRJLIKOnxuJ IQBHZLBjX5/VNDC5aODUV4Oh/xuQjSdRdBeECREIRlOf2rAhR0AvQW++7ix8sGwFxP9t3Go6T 0hEz2J8Kp0nuipkUJz22aBGXojePzicApaCS8f56NClOT9Z28i+xD8bNN4fx9SHNw72UOI9WQ oCvRHeTJcGSzBRV4AxV8aSW/0PjzuLpnIqTBw5x0qR5QfzeQ5+zbOrpmXqs20m7KMDgtrMmvm pOi0Fo7n2SzOzGby2g3Zloso8ux2SiToKvoRXhNCkyhMPUH+wKMzMOMzszfuMLK8cZ09x8zxI ZRIUWqQ+5LTDEycncvicjeZzJG3OyYDFauOlx9Jishy3sZaeFOWKN1Hc6mShmffMOr1yQEnzh DWbCunTJBbhU60YDXmWP80GvsHHUilVMiRRCJhYm2c3WJy/K/3owQKqRXyXUKXWJPV8SevPzI KFhmlaNV8YRQH+1dSOlGGtzmwwVagqB4gY6aZy9uGzUseNRs96wqLklQzbvadW1aaVN6jqV1Z eF4/4sZfGGqDzKwzj1KrFtvuqSpXt6vXdt5Kqz6cx+QkmLe/2JrxqqlCeiFu0ceWD3OdnX7Xo LIk1FXRqC+GMu3yDyOXVMfzFr6dztac2j04pcqB7u6fqSZ4IzsnGbfz7C/Me3KDAgQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-94.messagelabs.com!1513696111!202019311!1 X-Originating-IP: [216.32.181.176] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32113 invoked from network); 19 Dec 2017 15:08:32 -0000 Received: from mail-by2nam01lp0176.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.176) by server-8.tower-94.messagelabs.com with AES256-SHA256 encrypted SMTP; 19 Dec 2017 15:08:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3NaN9odGAZO0au7pD3fdt90dWAg0a7HdUDrq5ur9DsQ=; b=eqwX2K4qp+xdozDfOO4cpkkb6m3A9KiRizzQzAgN9B/5ayzGBXyD0AiQvCmnxqAwELW4eGlDkgH9hhHdC/PPNB2skAcGVMkZ+cLj+TPLgjjtTVtkD1wBCF+4Gi3DdL1i1qRsehuaam57dToK6MoQBy7FaPrQZqTCgOdehza/cs4= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1291.namprd14.prod.outlook.com (10.173.132.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 15:08:30 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 15:08:30 +0000 From: Tim Hollebeek To: Stephen Farrell , "Salz, Rich" , Eric Rescorla , David Benjamin CC: "tls@ietf.org" Thread-Topic: [TLS] Additional TLS 1.3 results from Chrome Thread-Index: AQHTeDdnoK0wVwYZnkmqGWUHphtSUKNJlvsAgABSngCAALp9AIAAIE+Q Date: Tue, 19 Dec 2017 15:08:30 +0000 Message-ID: References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> In-Reply-To: <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1291; 6:Tkd2goENRiNksClMMClKfa1QrdM/Xl83WF6tgPVYzi1jjZKaPN4rRkAOg9n+LNIqTaXaxmscTxCj9h6jnlQhHEkWtcuP+ZUI0QSWfp9k6M7d0+jS7mD7/V5Ga0lWjzdboSMu+6Xx+PAlczCHI6AKrenSzoh3nrYp544s+6LdGJ2HZbQYh9mqsw8H6YUAoRgTTTj7r+FBBZ/Z5ku4V8YQbmaBCWrDR/mCnHI6zLLke4tL1BY+mXSSs8GUDceD93tuA4pwbBX4nEys/GydvBMUBMW3Z8YB/NRkx2UBDwS6zZQ5ixwRroi+Jio/3qNEQfdqTmYViIb7mh74I8r7Uxj6K15cbw/8nDCA5FM6bd7hvw4=; 5:PBURUfAy9s1uHRcPeBHiGkxDm3AL4kPIDzbJYVM9QWVLKkenW6V9UBQYXmZcLezibgHnnI8g1+UGGWPln07b+uWWAIqPbSse7nuiJlR8CNxFa+4QrvFhGlWEWo6zF8e0Dmn79pTN6mMdfHvhSI2OqLt5d8o8UZ9/jlVVWwt9/fs=; 24:VeA0fr4F3dAtAyN4byh1fI+4mt0nl7sTvxv3lCICX4VQBrwpn56gMQeatu3fSOeIl1kmxwwZYEODhLyq6qS+LgJvdAK96T1dIsXpuusZeVY=; 7:klGBXqHbAcgkp4jBgQBiLmnBuKy9UG0ry4ph21GyWz0TXHhY5ZykKK3B4gjxdZmN+5RkdbigXYZeGU7tqPSVDm0SVXnV0wQS3fVflizZ2KMkp2T1KEzSRak4NMn3wCgNrYvp0BE5cv5sd63rADMGBpRLSciODnkdJqUNxQqgARjQHiwjzhtJGaLgla8usR21P1hD4eLZvSjLs2wCcpbmu7hZWQvbnK5zPOgzKxLsbYr2pQI2nDD++m+HxOxcfE11 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2d7e231f-bc19-497f-c53e-08d546f25d7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(49563074); SRVR:DM5PR14MB1291; x-ms-traffictypediagnostic: DM5PR14MB1291: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041248)(20161123562025)(20161123564025)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(6072148)(6043046)(201708071742011); SRVR:DM5PR14MB1291; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1291; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(366004)(189003)(199004)(2950100002)(6506007)(8676002)(81156014)(7696005)(59450400001)(93886005)(106356001)(76176011)(66066001)(86362001)(8936002)(102836003)(6116002)(3846002)(3280700002)(316002)(110136005)(5660300001)(3660700001)(7736002)(99936001)(6436002)(6246003)(305945005)(74316002)(81166006)(2906002)(9686003)(4326008)(229853002)(478600001)(2900100001)(99286004)(77096006)(25786009)(105586002)(97736004)(53936002)(68736007)(55016002)(14454004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1291; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_05E1_01D378A0.8A598760" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d7e231f-bc19-497f-c53e-08d546f25d7c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 15:08:30.6187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1291 Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2017 15:08:36 -0000 ------=_NextPart_000_05E1_01D378A0.8A598760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I'm not sure I agree renumbering is the right reaction, though I don't > object to > that. This could be a case where it's overall better that those specific > devices > suffer breakage, and hopefully then do get firmware updated to support > TLS1.3 or TLS-without-extended-random-or-dual-ec > at some point. It's never better to break large numbers of things, if it can be avoided at low cost. The reaction isn't going to be "TLS 1.3 broke my printer, it's time to upgrade my firmware.", it's going to be "TLS 1.3 broke my printer, which was working perfectly fine. TLS 1.3 is bad. I wonder what else they got wrong. People shouldn't use TLS 1.3." -Tim ------=_NextPart_000_05E1_01D378A0.8A598760 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjE5MTUwODIzWjAvBgkqhkiG9w0BCQQxIgQgEogWefirtpYrYw0Y08gu+ouN8SbX qLDzUc8bfaLlm8AwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABhoyan7Ev6Hp/wuDEf1Hngu5o1WFFWuj8hHa1VktUBHFAVPbEiRabiNh1FyUPvzrd5NrB+n ZhIUG63KLtFjySLxOM10qc6m7yaictunGSa68XMytGny7wnR+V/U4hvyGCVRQggvLqKrtlUnmn8x ROVr8sbJKyPtYY27kJNPkfcVH/Fl89RjP4jM2YUmFThaBu86oCFBqUmfg+F0LA8HA8XRvQLkCiJC c5fUoQW+rjE9xgJkC7vkHUyU+5qwuJiVryqVb07+oNOxmyVsxoNQFahz2yJ4jyM0yyA79VarwQaY 3bTg0GjYDkxWDRNsgTS46M3ktnqvmrDwNu3bGzDLZQ0AAAAAAAA= ------=_NextPart_000_05E1_01D378A0.8A598760-- From nobody Tue Dec 19 08:28: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 3DEEB1270AC for ; Tue, 19 Dec 2017 08:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99uIIJ3YkWtk for ; Tue, 19 Dec 2017 08:28:40 -0800 (PST) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::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 DBA1D129C6E for ; Tue, 19 Dec 2017 08:28:39 -0800 (PST) Received: by mail-pl0-x229.google.com with SMTP id b96so7261385pli.2 for ; Tue, 19 Dec 2017 08:28:39 -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=enM8oJfRiCdW1CtQK+SY31FnZgKN+XyIv+j/4ee5B0k=; b=HkY1ITPk3QuMrog77AAE84tCuwlEzK5MrlstlO3NdbQne9WMGvqgUWFVrmzU5vUvwL pI+4UCRyKXCsLAwsHKLvI5kWuOGzJt9TdGBFXDYYwkc7PDWIoCZkvB9JKnvzdY38Bdv2 KC/JwVhLugPPv+C9phzIsfvaSwIJREWRsVZBE7uTd3c6DCDPKDSYCEmfsvHdaq7EHM0J yFHPhQRpfdkKiakmAaScGtRFrRgmgdSMLMkb/NHBrZBL+QUekYtdcA+BJZZfu8g3pYBg dSyd49DqENaLDl25desuAjELSnuk5HD0CrXqTR2Qpkt7QWhY6gRvb0P2bQjtDvy2VHWS 95ug== 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=enM8oJfRiCdW1CtQK+SY31FnZgKN+XyIv+j/4ee5B0k=; b=Z/mtALZ5V7lFw1n/Qt/+7Pbo4K4htiahjRRUR8QhmJZqjbsB2cwK1KoUlt7/XxyrLD x+qIDEMpV9OaiPJ74eIvmEg75EKpdzdaj61yNA5nsCPVLl8yu9+x7KKJCLRTeRxuTnZD BZ4CPukpmmC83suI251xYhJxSfxVXQJz3tx2RW1Xv5QON3w5oda0T8Xrh4fhC7WLuIfW rQdD2oMhJfDCDYbqdCas7psa4DE7VtiTIVDA9Wg8ehtha2CEhn0OVJtqT6XtR78OXa42 i1vBktJn6YDvB0nuvsSi99q9upcvk1JUW9TZBBY9CXfqIQyJM8TenZw5yJR1rednLBMs d7SQ== X-Gm-Message-State: AKGB3mIIF59XiXIgY02lMAwAjcZXp9QxEpjxCJx2QhzFkAa95H3pruhB G8wpIRprERjdKgdpSrt2pyiq3OLrgLxQuSJpkiA= X-Google-Smtp-Source: ACJfBotp8KYguZa9i1tBpmVjWUoBhXiyQMdVQwupCLrbUHgeRzpGrCaxO6GL6tlcHJ+nScrIFhv/KlZmRuGXPD9Tv80= X-Received: by 10.84.196.131 with SMTP id l3mr3785009pld.194.1513700919225; Tue, 19 Dec 2017 08:28:39 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.100.149.193 with HTTP; Tue, 19 Dec 2017 08:28:38 -0800 (PST) In-Reply-To: <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> From: Adam Langley Date: Tue, 19 Dec 2017 08:28:38 -0800 X-Google-Sender-Auth: D31YYyFFMEPsUegEmtpy-oqfgs0 Message-ID: To: Stephen Farrell Cc: "Salz, Rich" , Eric Rescorla , David Benjamin , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1889469635530560b3f573" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2017 16:28:41 -0000 --94eb2c1889469635530560b3f573 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell wrote: > I'm not sure I agree renumbering is the right reaction, > though I don't object to that. This could be a case where > it's overall better that those specific devices suffer > breakage, and hopefully then do get firmware updated to > support TLS1.3 or TLS-without-extended-random-or-dual-ec > at some point. > I think we would like to avoid deliberately breaking these devices with TLS 1.3. (I think TLS 1.3 has been subject to enough friction already.) If key_share is renumbered, then presumably extension 40 would be reserved by IANA. Thus other implementations could send extension 40 if they wish not to interoperate with extended_random-supporting peers. Cheers AGL --94eb2c1889469635530560b3f573 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 19, 2017 at 5:07 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
I'm not = sure I agree renumbering is the right reaction,
though I don't object to that. This could be a case where
it's overall better that those specific devices suffer
breakage, and hopefully then do get firmware updated to
support TLS1.3 or TLS-without-extended-random-or-dual-ec
at some point.

I think we would like to= avoid deliberately breaking these devices with TLS 1.3. (I think TLS 1.3 h= as been subject to enough friction already.)

If ke= y_share is renumbered, then presumably extension 40 would be reserved by IA= NA. Thus other implementations could send extension 40 if they wish not to = interoperate with extended_random-supporting peers.


Cheers

AGL=C2=A0
--94eb2c1889469635530560b3f573-- From nobody Wed Dec 20 07:37: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 8149B1270A7 for ; Wed, 20 Dec 2017 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 JI66dnHpWGgH for ; Wed, 20 Dec 2017 07:37:50 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 3E21C126CD8 for ; Wed, 20 Dec 2017 07:37:49 -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=1513784270; x=1545320270; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dccg8mUdJVSgpPk5lZuTXRyCkeo+Tp5x6aLeYlT6tuw=; b=oWPPNy4NYZA6CxKq8pWux6SmUT1Hl9UGhn677Hx2dtqkFtB2FN6AzKV+ FaIqODHwyBiZKnYx9eNeQP5e6fv4Zw1a50Nb92agDJNRm+w8SF/gZKZWd xQDf1OVHafL9QhhNZGwGnW0l66qhdcNHKyNo8W3x6hbNmkEG7+Dm+9YTA lN1BVthepJ3KkMa9nWq/pl9n3VJlOKA7q3S1+cyNj2bgs5eceBdfucp1f 6QJntfu6JZJiForeU3f59Wi8mfp1bPPLEPchi7pgM+nD59DvipgbG7H7E kFpo/5oVNrE69sfSUADHJQV3AUlDrEAzGxCeabqA/wb/944avRXUmDkBV g==; X-IronPort-AV: E=Sophos;i="5.45,432,1508756400"; d="scan'208";a="204884956" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Dec 2017 04:37:47 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 21 Dec 2017 04:37:46 +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.1263.000; Thu, 21 Dec 2017 04:37:46 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , "tls@ietf.org" Thread-Topic: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: AQHTdSndiFmdFk2VuUqeUDLf4NX5NqNMZdeu Date: Wed, 20 Dec 2017 15:37:46 +0000 Message-ID: <1513784265636.74656@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2017 15:37:53 -0000 Colm MacC=E1rthaigh writes:=0A= =0A= >since it's important not to leak timing, we use a special=0A= >"constant_time_copy_or_dont" routine to do the over-write:=0A= >=0A= >https://github.com/awslabs/s2n/blob/master/utils/s2n_safety.c#L70=0A= =0A= Has anyone actually been able to measure the impact of issues like this? I= =0A= know about papers like "Remote timing attacks are practical" that work with= =0A= things like Montgomery modmult, but can much be practically done with a few= =0A= instructions here and there, not repeated in a loop like a modmult?=0A= =0A= The reason I ask is a combination of two things, firstly I've done timing= =0A= measurements on my own code to try and detect differences in behaviour and= =0A= couldn't find anything among the general noise of code execution, and secon= dly=0A= any constant-time code is a tradeoff between readability/auditability and= =0A= (near) constant-time operation ("near" because you have no control over wha= t a=0A= compiler will do to optimise your code, so it may not be anywhere near=0A= constant-time once it's in binary form). Something like=0A= s2n_constant_time_copy_or_dont() is barely passable, but I've seen constant= -=0A= time PKCS #1 decoding and similar that's essentially incomprehensible, ther= e's=0A= no way to look at it and see that it's correct. Even something as simple a= s:=0A= =0A= https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphe= rsuites/=0A= =0A= had errors, because the constant-time code is so difficult to audit.=0A= =0A= >Next, when the handshake does fail, we do two non-standard things. The fir= st=0A= >is that we don't return an alert message, we just close the connection. = =0A= =0A= That's actually really annoying, because it implies something other than a = TLS=0A= crypto problem, e.g. a misconfigured firewall or who knows what. I don't k= now=0A= how diversely-used s2n is, in other words whether you can assume the client= s=0A= and servers employed will know how to react to this, but in general use it'= ll=0A= make getting things working a major pain since it changes the error indicat= or=0A= from "the TLS handshake failed due to crypto issues" to "something failed= =0A= somewhere, probably at the network level".=0A= =0A= >The second non-standard thing we do is that in all error cases, s2n behave= s=0A= >as if something suspicious is going on and in case timing is involved, we = add=0A= >a random delay. It's well known that random delays are only partially=0A= >effective against timing attacks, but we add a very very big one. We wait = a=0A= >random amount of time between a minimum of 10 seconds, and a maximum of 30= =0A= >seconds. With the delay being granular to nanoseconds. =0A= =0A= I do the same thing, but I use 1s rather than 10 (although I've just bumped= =0A= this to 3 in the latest code):=0A= =0A= /* Delay by a small random amount, used to dither the results of (failed) = =0A= crypto operations to make timing attacks harder.=0A= =0A= As with anything involving randomness, there's been a lot of smoke and = =0A= not much light generated over the use of random delays to address timing= =0A= attacks. The generic answer is that it doesn't help so there's no point= =0A= in doing it and everyone should just write constant-time code, another = =0A= prime example of le mieux est l'ennemi du bien.=0A= =0A= If the arguments ever get beyond abstract theory (theoretical constant-= =0A= time code is better than theoretical random delays), the argument given = =0A= is usually that we're measuring timing differences in us or ns while the= =0A= delay functions are typically in ms. Another argument is that all an = =0A= attacker has to do is repeat the measurements in order to filter out the= =0A= delays.=0A= =0A= The counterargument for the former is that if you've got an attacker =0A= sitting on your local LAN segment making ns-scale timing measurements on= =0A= your crypto then you've got bigger things to worry about than side-=0A= channel attacks (over more distant connections, you can at best get tens= =0A= to hundreds of us using thousands of measurements, see e.g. =0A= "Opportunities and Limits of Remote Timing Attacks" by Crosby, Reid, and= =0A= Wallach, which also required multiple days of data-gathering beforehand = =0A= to characterise the network). In addition in cryptlib's case since all = =0A= operations go via the kernel, you don't have direct (timing) access to = =0A= the low-level crypto ops but only get strongly dithered results at that = =0A= level.=0A= =0A= As a result, while you can still use repeated measurements to eventually= =0A= filter out the dithering, it's now made the attacker's job much, much = =0A= harder. Since it's essentially free (it's only invoked if an operation = =0A= fails), it makes sense to add the delay.=0A= =0A= Another issue is how long to make the delay. Obviously the longer, the= =0A= better, however if we make it too long then it can end up looking like a= =0A= different problem, e.g. a networking issue rather than a crypto defence,= =0A= which will be a pain to diagnose for users. 3s seems to be a good trade= off=0A= between dithering operations and slowing down an attacker while not addi= ng=0A= an excessive delay that looks like it's caused by something else */=0A= =0A= Again, it's for ease of deployment, a 1s (or 3s) delay won't get noticed wh= ile=0A= a 10s delay looks like a network problem, and 30s looks like a major issue= =0A= somewhere.=0A= =0A= >The solutions here typically are not small routines that are rigorously=0A= >constant time, but instead rely on a degree of code-balancing: taking code= =0A= >paths that are "similar enough" in timing so as not to be measurable.=0A= =0A= Yup, that's what I try and do.=0A= =0A= >trying to be rigorously constant time on large complicated algorithms that= =0A= >were not designed to be constant time can seriously backfire by introducin= g=0A= >logic errors in the very hard-to-follow constant-time adaptations.=0A= =0A= You don't even need large complicated algorithms, you can create logic erro= rs=0A= in a few lines of code, as your cited example shows. That's why I prefer= =0A= obvious correctness (or probably-correctness :-) and defences in other plac= es.=0A= =0A= Peter.=0A= From nobody Wed Dec 20 13:50: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 0661D1205D3 for ; Wed, 20 Dec 2017 13:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 1j4uCJKb8-pS for ; Wed, 20 Dec 2017 13:50:50 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3CD1200C5 for ; Wed, 20 Dec 2017 13:50:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A8974B5258; Wed, 20 Dec 2017 23:50:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id BF_nQMf7hBWk; Wed, 20 Dec 2017 23:50:48 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 3EB6C2308; Wed, 20 Dec 2017 23:50:45 +0200 (EET) Date: Wed, 20 Dec 2017 23:50:44 +0200 From: Ilari Liusvaara To: Peter Gutmann Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" Message-ID: <20171220215044.GA10711@LK-Perkele-VII> References: <1513784265636.74656@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1513784265636.74656@cs.auckland.ac.nz> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2017 21:50:53 -0000 On Wed, Dec 20, 2017 at 03:37:46PM +0000, Peter Gutmann wrote: > The reason I ask is a combination of two things, firstly I've done timing > measurements on my own code to try and detect differences in behaviour and > couldn't find anything among the general noise of code execution, and secondly > any constant-time code is a tradeoff between readability/auditability and > (near) constant-time operation ("near" because you have no control over what a > compiler will do to optimise your code, so it may not be anywhere near > constant-time once it's in binary form). Something like > s2n_constant_time_copy_or_dont() is barely passable, but I've seen constant- > time PKCS #1 decoding and similar that's essentially incomprehensible, there's > no way to look at it and see that it's correct. Just for fun I tried to implement decoding raw decrypted PKCS#1 encoded RSA premaster secret and then checking the finished MAC. In way not vulernable to ROBOT. I started with code already implementing (EC)DHE key derivation and finished check. It was like 25-30 (depends on how one counts) lines of (not very hairy) code to implement, including modifications to existing code. And this was without any fancy libraries (including random number generation). Of course, just removing static RSA is much easier way of eliminate ROBOT. I never hooked it up to TLS proper, because that would have been hundreds of lines of code at the very least. Plus, the code is not up to my quality standards to publish, even as a hack (ocassionally absolutely incredible things make to "production"). -Ilari From nobody Fri Dec 22 12:01: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 07D3B127735 for ; Fri, 22 Dec 2017 12:01:21 -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 hwE0d8rhbteS for ; Fri, 22 Dec 2017 12:01:18 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D1812741D for ; Fri, 22 Dec 2017 12:00:54 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id q3so6521563ybg.9 for ; Fri, 22 Dec 2017 12:00:54 -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=+Xiyh/SdFgAv6rgWaOk5GY6q0pgeOgcdSeB7qSzQc90=; b=W7BOLG3P4YdbGvBEUzSLzlYxurnHwnPdwXTIMVPUpgGCdt7Jbvl4IDhbq4tt40hluo McDzpbkMfdiSk8cC809cslVlQy+dSRiBBk8oHNqBJD8iJe+DkIHt4lfKWMLVtuaFdcw1 lUjVorg0QTGHzQWzGcG616T8wqGhOGdV6rZGLyMULd//YSgTI7sF7l/opNodOZIwyH2b 8MRF9oYQ2Y0vKh+o9mOg+Kb1ufnEjN2FyNAF39z9xylvygEzGEEytdD6nJrVn8zKRnry l9oXejU7emdEZsbwDZSE6nHpKQcQTE72vTd7nmuGr+tvKFz1rSdOGvyZkCKLdNHaLuu7 A9fA== 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=+Xiyh/SdFgAv6rgWaOk5GY6q0pgeOgcdSeB7qSzQc90=; b=OILjfi8lQGxFPXMGhqmuQgOErNJrIrwul1ab7WaTtAAPiL1ZhGhra8o4hIhZi8b0/c g/z/tVPrO+MJU2GkcD5hVuT/qP/KVYhH9MU4vYG84dSiV2yyqCbuF+WKSn2RIz7WKLsG 9rqNNFhIgby7+GdgQ0C/N4mLBUz3ft832TvZHO8btkPNatkc/0qCEl/kSxpuFeAdlo8g 5wzsx2i9AUoZaakHIyY0gsf9hOihHjq7PsusypfcYoIz8/kruZKAhc3dzkaDaUJmHrWX ZbftoU62sqQ6NeX6eeqhEcGqNDtFQPgFLuJFF6I2vcO5PmhgvRcnOkcwlUfI+c57DpPD egQA== X-Gm-Message-State: AKGB3mI6ACu9hkyHhTQ41thEaMZeieI58uO1EABO6QOXZuG/Jz5v7mGD 4QtPpla3zDwn/Wmfu9tAzQrBaam1uIr5xly1D2yW6yzTOKA= X-Google-Smtp-Source: ACJfBovTYTL371Zml6GX6usN3e598dNTirtHOwgBFwhyb3NHkT7N0WGmUHaHlCkfsDhDGknCdGVywTEvAJbIWGXpLPw= X-Received: by 10.37.224.4 with SMTP id x4mr11455900ybg.200.1513972853337; Fri, 22 Dec 2017 12:00:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 22 Dec 2017 12:00:12 -0800 (PST) From: Eric Rescorla Date: Fri, 22 Dec 2017 12:00:12 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c084a941f89e20560f3461e" Archived-At: Subject: [TLS] More compatibility measurement results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2017 20:01:21 -0000 --94eb2c084a941f89e20560f3461e Content-Type: text/plain; charset="UTF-8" Hi folks, Here are the results of our experiment with Firefox Nightly (draft-22) against Facebook. EXPERIMENTAL DESIGN This is a forced experiment in which each client tries all the variants. The experiment is deployed via a system add-on (a remotely deployable, centrally managed piece of JavaScript code), and then takes measurements by trying to do an XHR to a given URL (https://www.tls13.facebook.com/) with a specific set of flags. We do the following three measurements: - TLS 1.2 - TLS 1.3 draft-22 - TLS 1.3 draft-22 in compat mode. We take five trials for each measurement, randomly shuffling the measurement order and then repeating the shuffled pattern five times. Each trial is done with a different connection and we declare "success" when any of the five trials succeeds. RESULTS This experiment was run on a 40% sample of the Firefox Nightly population who have locale set to en-US. The data below is taken from the period 20171216 to 20171222. There's a bit of contamination in the targeting because we temporarily failed to filter on "en-US", but that should mostly only affect the first day. 37716 clients started the experiment and 37430 completed it (99.2%). The results are: Success Fail Rate fb-tls12 35615 1815 0.048491 fb-tls13-draft-22 35552 1878 0.050174 fb-tls13-draft22-compat 35630 1800 0.048090 The overall failure numbers here are a lot higher than with our Beta experiment, which may be a result of different targeting on Nightly versus Beta. In particular, I'm still seeing a lot of data from China and Vietnam, which seem to have high blocking rates in general (i.e., not just for TLS 1.3). If I restrict to non China and non-Vietnam, we get: Success Fail Rate fb-tls12 35034 1176 0.032477 fb-tls13-draft-22 34960 1250 0.034521 fb-tls13-draft22-compat 35037 1173 0.032394 None of these differences are statistically significant (in the second data set, the p value for 1.2 versus -22 is .13), but this all seems consistent with saying that that -22 compat mode isn't significantly worse than TLS 1.2 and that normal -22 may be somewhat worse (unfortunately, we don't have -18 in this experiment). Taken together with the results David has reported and our previously reported Beta results, this seems fairly encouraging. We'll probably let the Nightly experiment run a little longer to see if we hit significance, but after that will start looking at a rollout of -22 to Release. -Ekr ADDITIONAL DETAILS Experimental code: https://github.com/mozilla/one-off-system-add-ons/tree/master/addons/tls13-middlebox-draft22 --94eb2c084a941f89e20560f3461e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Here are the resul= ts of our experiment with Firefox Nightly (draft-22)
against Face= book.

EXPERIMENTAL DESIGN
This is a forc= ed experiment in which each client tries all the
variants. The ex= periment is deployed via a system add-on (a remotely
deployable, = centrally managed piece of JavaScript code), and then
takes measu= rements by trying to do an XHR to a given URL
(https://www.tls13.facebook.com/) with a speci= fic set of flags. We
do the following three measurements:

- TLS 1.2
- TLS 1.3 draft-22
- TLS 1.= 3 draft-22 in compat mode.

We take five trials for= each measurement, randomly shuffling the
measurement order and t= hen repeating the shuffled pattern five
times. Each trial is done= with a different connection and we declare
"success" w= hen any of the five trials succeeds.


RESULTS
This experiment was run on a 40% sample of the Firefox = Nightly population
who have locale set to en-US. The data below i= s taken from the period
20171216 to 20171222. There's a bit o= f contamination in the targeting
because we temporarily failed to= filter on "en-US", but that should
mostly only affect = the first day.

37716 clients started the experimen= t and 37430 completed it (99.2%).

The results are:=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Success=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fail=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Rate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 fb-tls12=C2=A0 =C2=A0 =C2=A0 =C2=A0 35615=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A01815=C2=A0 =C2=A0 =C2=A00.048491
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fb-tls13-draft-22=C2=A0 =C2=A0= =C2=A0 =C2=A0 35552=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01878=C2=A0 =C2=A0 =C2= =A00.050174
=C2=A0 =C2=A0 =C2=A0 =C2=A0fb-tls13-draft22-compat=C2= =A0 =C2=A0 =C2=A0 =C2=A0 35630=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01800=C2=A0 = =C2=A0 =C2=A00.048090

The overall failure numbers = here are a lot higher than with our Beta
experiment, which may be= a result of different targeting on Nightly
versus Beta. In parti= cular, I'm still seeing a lot of data from China
and Vietnam,= which seem to have high blocking rates in general (i.e.,
not jus= t for TLS 1.3). If I restrict to non China and non-Vietnam, we
ge= t:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Success=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fail=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Rate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fb-tls12=C2=A0 =C2=A0 =C2=A0 =C2=A0 35034= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01176=C2=A0 =C2=A0 =C2=A00.032477
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fb-tls13-draft-22=C2=A0 = =C2=A0 =C2=A0 =C2=A0 34960=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01250=C2=A0 =C2= =A0 =C2=A00.034521
=C2=A0 =C2=A0 =C2=A0 =C2=A0fb-tls13-draft22-co= mpat=C2=A0 =C2=A0 =C2=A0 =C2=A0 35037=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01173= =C2=A0 =C2=A0 =C2=A00.032394

None of these differe= nces are statistically significant (in the second
data set, the p= value for 1.2 versus -22 is .13), but this all seems
consistent = with saying that that -22 compat mode isn't significantly
wor= se than TLS 1.2 and that normal -22 may be somewhat worse
(unfort= unately, we don't have -18 in this experiment).

Taken together with the results David has reported and our previously
reported Beta results, this seems fairly encouraging. We'll prob= ably
let the Nightly experiment run a little longer to see if we = hit significance,
but after that will start looking at a rollout = of -22 to Release.

-Ekr

<= br>
ADDITIONAL DETAILS

--94eb2c084a941f89e20560f3461e-- From nobody Sat Dec 23 06:07: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 ABB6712D77C for ; Sat, 23 Dec 2017 06:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 hX-ejQUxj4az for ; Sat, 23 Dec 2017 06:07:20 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5281312D779 for ; Sat, 23 Dec 2017 06:07:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id AB0295DE6D; Sat, 23 Dec 2017 16:07:17 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id KwFxQWWthOPa; Sat, 23 Dec 2017 16:07:17 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 6B0112308; Sat, 23 Dec 2017 16:07:15 +0200 (EET) Date: Sat, 23 Dec 2017 16:07:15 +0200 From: Ilari Liusvaara To: Eric Rescorla Cc: tls@ietf.org Message-ID: <20171223140714.GA29043@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] More compatibility measurement results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2017 14:07:23 -0000 On Fri, Dec 22, 2017 at 12:00:12PM -0800, Eric Rescorla wrote: > Hi folks, > > Here are the results of our experiment with Firefox Nightly (draft-22) > against Facebook. > > > RESULTS > > 37716 clients started the experiment and 37430 completed it (99.2%). > > The results are: > > Success Fail Rate > fb-tls12 35034 1176 0.032477 > fb-tls13-draft-22 34960 1250 0.034521 > fb-tls13-draft22-compat 35037 1173 0.032394 > > None of these differences are statistically significant (in the second > data set, the p value for 1.2 versus -22 is .13), but this all seems > consistent with saying that that -22 compat mode isn't significantly > worse than TLS 1.2 and that normal -22 may be somewhat worse > (unfortunately, we don't have -18 in this experiment). > > Taken together with the results David has reported and our previously > reported Beta results, this seems fairly encouraging. We'll probably > let the Nightly experiment run a little longer to see if we hit > significance, > but after that will start looking at a rollout of -22 to Release. ~3.25% baseline failure rate? That sounds quite high. ~0.2% above- baseline failure rate for non-compat? That sound fairly low, but there have been improvements here that could have caused substantial decrease. I wonder if the high baseline failure rate is due to high amount of blocking of the test server. And unfortunately, the places that blocked the test server are some of the most interesting when it comes to the compatibility. However, the results do establish that the incremential failure rates in open environments (anything that blocks the testserver very probably is not open environment) are low enough to proceed with. -Ilari From nobody Sat Dec 23 06:30:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC0C1270B4 for ; Sat, 23 Dec 2017 06:30:49 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (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 MeQI9xITsIiy for ; Sat, 23 Dec 2017 06:30:47 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 D8155126B72 for ; Sat, 23 Dec 2017 06:30:46 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id w131so20617353oiw.0 for ; Sat, 23 Dec 2017 06:30:46 -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=B+YdKx/dEbJsFVAXXr895P/5YSh2fqJb+YwwZt05EP8=; b=hSI2GODWw3/Z/3bemHQInAeGEfu/DpZsijbvRiMpYMk1CgawdoT9NJpLpIYBBTihy+ OUSAjWYQU742QftPVl5skDfXBF2fiNVmU9AeMLgsB05nao33tU09Zxtec7PajL8MfKug N6k4j/NM4fzc7tx+IlpgStRP7viJi51h8ZVfY= 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=B+YdKx/dEbJsFVAXXr895P/5YSh2fqJb+YwwZt05EP8=; b=XMDr6zAuR+Ft9WyTH1n+t5CK6uC8giAs2F1qJ/VrM8bt8ftl+6h1dZ7fakxppTwYNl B8yf2rzVsZEbCQIq8+ezQk4Ut8iwKfovYuRcIQXRyj4CyYxJBjGesLe/iINGuvMvbhW4 bcZN/5UZjBr9yDgTtxNO9Uhc4a4J+k4dss+qE9WxPaQyfg5cApaJE9emQDSCVA+uMHf6 9r9XUaDwr+249kxD/8gpDKklPbUSDKLPDfOdfe1VzrTjI9MCTrrc10MKI3rPFUNv3PHd wuFYUoOyLb7oxg9s3425SgGb3eI5N0o8mnSaale8/DAUCAJIAXZdL98ZqBwh5WW2+upZ b8KQ== X-Gm-Message-State: AKGB3mKXe9qHGyp2wybY3gkJhqdGZkncyeYugupkek9GShTh/ZO/EnPn L2m3HaD0Ho7nmFwHreDyY7NEZIgk1H4= X-Google-Smtp-Source: ACJfBouas6pctqQHVTAzxazuKMRtD0Cb9jbYFwP7CDpz+vfzZzzAlLHLkM0Iud+YGBh4NKw4Eh4YFw== X-Received: by 10.202.1.201 with SMTP id 192mr13089159oib.97.1514039446006; Sat, 23 Dec 2017 06:30:46 -0800 (PST) Received: from [10.83.5.240] (mobile-166-173-58-124.mycingular.net. [166.173.58.124]) by smtp.gmail.com with ESMTPSA id d55sm1577756otf.2.2017.12.23.06.30.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Dec 2017 06:30:45 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-294A8685-345B-4A54-B4EC-14CDFE87AAF2 Mime-Version: 1.0 (1.0) From: Sean Turner X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Sat, 23 Dec 2017 08:30:43 -0600 Cc: tls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <9480B42E-8C17-4282-93D1-9763BEAD2453@sn3rd.com> References: To: Eric Rescorla Archived-At: Subject: Re: [TLS] More compatibility measurement results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2017 14:30:49 -0000 --Apple-Mail-294A8685-345B-4A54-B4EC-14CDFE87AAF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks for these! spt Sent from my iPhone > On Dec 22, 2017, at 14:00, Eric Rescorla wrote: >=20 > Hi folks, >=20 > Here are the results of our experiment with Firefox Nightly (draft-22) > against Facebook. >=20 > EXPERIMENTAL DESIGN > This is a forced experiment in which each client tries all the > variants. The experiment is deployed via a system add-on (a remotely > deployable, centrally managed piece of JavaScript code), and then > takes measurements by trying to do an XHR to a given URL > (https://www.tls13.facebook.com/) with a specific set of flags. We > do the following three measurements: >=20 > - TLS 1.2 > - TLS 1.3 draft-22 > - TLS 1.3 draft-22 in compat mode. >=20 > We take five trials for each measurement, randomly shuffling the > measurement order and then repeating the shuffled pattern five > times. Each trial is done with a different connection and we declare > "success" when any of the five trials succeeds. >=20 >=20 > RESULTS > This experiment was run on a 40% sample of the Firefox Nightly population > who have locale set to en-US. The data below is taken from the period > 20171216 to 20171222. There's a bit of contamination in the targeting > because we temporarily failed to filter on "en-US", but that should > mostly only affect the first day. >=20 > 37716 clients started the experiment and 37430 completed it (99.2%). >=20 > The results are: >=20 > Success Fail Rate > fb-tls12 35615 1815 0.048491 > fb-tls13-draft-22 35552 1878 0.050174 > fb-tls13-draft22-compat 35630 1800 0.048090 >=20 > The overall failure numbers here are a lot higher than with our Beta > experiment, which may be a result of different targeting on Nightly > versus Beta. In particular, I'm still seeing a lot of data from China > and Vietnam, which seem to have high blocking rates in general (i.e., > not just for TLS 1.3). If I restrict to non China and non-Vietnam, we > get: >=20 > Success Fail Rate > fb-tls12 35034 1176 0.032477 > fb-tls13-draft-22 34960 1250 0.034521 > fb-tls13-draft22-compat 35037 1173 0.032394 >=20 > None of these differences are statistically significant (in the second > data set, the p value for 1.2 versus -22 is .13), but this all seems > consistent with saying that that -22 compat mode isn't significantly > worse than TLS 1.2 and that normal -22 may be somewhat worse > (unfortunately, we don't have -18 in this experiment). >=20 > Taken together with the results David has reported and our previously > reported Beta results, this seems fairly encouraging. We'll probably > let the Nightly experiment run a little longer to see if we hit significan= ce, > but after that will start looking at a rollout of -22 to Release. >=20 > -Ekr >=20 >=20 > ADDITIONAL DETAILS > Experimental code: https://github.com/mozilla/one-off-system-add-ons/tree/= master/addons/tls13-middlebox-draft22 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-294A8685-345B-4A54-B4EC-14CDFE87AAF2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for these!

spt
Sent from my iPhone

On Dec= 22, 2017, at 14:00, Eric Rescorla <ekr@r= tfm.com> wrote:

Hi folks,

Here are the results of our ex= periment with Firefox Nightly (draft-22)
against Facebook.

EXPERIMENTAL DESIGN
This is a forced experiment i= n which each client tries all the
variants. The experiment is depl= oyed via a system add-on (a remotely
deployable, centrally managed= piece of JavaScript code), and then
takes measurements by trying t= o do an XHR to a given URL
(https://www.tls13.facebook.com/) with a specific set of flags. We<= /div>
do the following three measurements:

- TL= S 1.2
- TLS 1.3 draft-22
- TLS 1.3 draft-22 in compat mo= de.

We take five trials for each measurement, rando= mly shuffling the
measurement order and then repeating the shuffle= d pattern five
times. Each trial is done with a different connecti= on and we declare
"success" when any of the five trials succeeds.<= /div>


RESULTS
This experiment wa= s run on a 40% sample of the Firefox Nightly population
who have l= ocale set to en-US. The data below is taken from the period
201712= 16 to 20171222. There's a bit of contamination in the targeting
be= cause we temporarily failed to filter on "en-US", but that should
= mostly only affect the first day.

37716 clients sta= rted the experiment and 37430 completed it (99.2%).

The results are:

         = ;                     &nbs= p;     Success         Fail    &= nbsp;    Rate
            &= nbsp;         fb-tls12        35615&= nbsp;        1815     0.048491
=              fb-tls13-draft-22  &nbs= p;     35552         1878    &n= bsp;0.050174
       fb-tls13-draft22-compat&nb= sp;       35630         1800  &= nbsp;  0.048090

The overall failure numbers he= re are a lot higher than with our Beta
experiment, which may be a r= esult of different targeting on Nightly
versus Beta. In particular= , I'm still seeing a lot of data from China
and Vietnam, which see= m to have high blocking rates in general (i.e.,
not just for TLS 1= .3). If I restrict to non China and non-Vietnam, we
get:

                &nbs= p;                   Success&nb= sp;        Fail         Rate
                   = ;   fb-tls12        35034       = ;  1176     0.032477
      &nbs= p;      fb-tls13-draft-22        34960&nb= sp;        1250     0.034521
&n= bsp;      fb-tls13-draft22-compat        3= 5037         1173     0.032394
=

None of these differences are statistically significant (= in the second
data set, the p value for 1.2 versus -22 is .13), bu= t this all seems
consistent with saying that that -22 compat mode i= sn't significantly
worse than TLS 1.2 and that normal -22 may be s= omewhat worse
(unfortunately, we don't have -18 in this experiment= ).

Taken together with the results David has report= ed and our previously
reported Beta results, this seems fairly enc= ouraging. We'll probably
let the Nightly experiment run a little l= onger to see if we hit significance,
but after that will start loo= king at a rollout of -22 to Release.

-Ekr


ADDITIONAL DETAILS

____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-294A8685-345B-4A54-B4EC-14CDFE87AAF2-- From nobody Wed Dec 27 07:02: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 C8F3012AF83 for ; Wed, 27 Dec 2017 07:02:13 -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 9SLqeJ9J1Ox4 for ; Wed, 27 Dec 2017 07:02:11 -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 AD7C41243FE for ; Wed, 27 Dec 2017 07:02:11 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id k80so7606769ywe.0 for ; Wed, 27 Dec 2017 07:02:11 -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=KyALrmcEvtK0JT91m72jWJWFxGoNU6DZYVeBSOSDYWs=; b=YcGLVCOKiYludtAYLCcFyl4QEuO9dSyl2qfvAFMYPzasuRrTi9p9UpGsqThV1Y3DP0 fMrwsY6cRK/5hZ6I/sVS7qL+UxU6UmsypeqYGwrGdqCi7iLZ1TRdt/N31MpIlBDsyOnJ PDDjJqQAuNeMzCV6uaMccdC8OOLzE+UhSvQwikRmemmQP/Yyt9n9Ap3btjickcnRcVx5 PYNLzyhvy80yRkqfCFRki8xK/WRu26QQCdUgYtdi7QKHTXQVzupL7eB+wVyrPxixmS8/ dEEjVHkuvKeiSqHBDWe77/0qs2L3n4PhCwX4w54Kc275C1EP4fTrIDkMPzeOJyvDKOhB deww== 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=KyALrmcEvtK0JT91m72jWJWFxGoNU6DZYVeBSOSDYWs=; b=FUXfJbtZOJIwnDDAt3rJl4y6QM4IA7gsBU/0B/Ag4nCPaV7cNy0O23ASCxL31kK/97 hJLr2yX08aSGwcDUDHw5g6ma+IttejoVgvnqjEnYJJDS1GU4yneFOSgIUTNldnzwanAi +ULaQN3hh6ZTTXpAxBkYOjaXEDmhuRZ8pr6NSPe8jgE2SiFQVWjw8/9m5k+gHJ9BPgnA ejW0owOgG2KJKix5e9KanKKUbrFH9SHXaQLsoe9uIZlLGrVYRNbZo5x4155uFOgzP4wu ZISXN/I9N9BjGDFykkCYwhI4qTku42PhHEfYVNTU66S5u1nSI3+N/ysnzVf0avXjF9n9 PhyA== X-Gm-Message-State: AKGB3mLW4a18jIEXlEs/Fpq8akHaOnZLwa0iDcTHIoNB/vwitVuJ4WMD wYvxGsSw5yLZXCeEYotxlQOmgFZsZ0spVnSokVjVJw== X-Google-Smtp-Source: ACJfBoujoBOXHvZC5MWE0y1BDgdB+fMVk+JJ5q7WFZucoo233nKIyopsNruP9dT3ozTOpLkT8c6NaoPVKltbL18m1ws= X-Received: by 10.129.58.1 with SMTP id h1mr19935829ywa.2.1514386930782; Wed, 27 Dec 2017 07:02:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 27 Dec 2017 07:01:30 -0800 (PST) In-Reply-To: References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> From: Eric Rescorla Date: Wed, 27 Dec 2017 07:01:30 -0800 Message-ID: To: Adam Langley Cc: Stephen Farrell , "Salz, Rich" , David Benjamin , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1137abdc0fe980056153af7f" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Dec 2017 15:02:14 -0000 --001a1137abdc0fe980056153af7f Content-Type: text/plain; charset="UTF-8" PR: https://github.com/tlswg/tls13-spec/pull/1128 I'll merge this next week, barring strong objection. -Ekr On Tue, Dec 19, 2017 at 8:28 AM, Adam Langley wrote: > On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> I'm not sure I agree renumbering is the right reaction, >> though I don't object to that. This could be a case where >> it's overall better that those specific devices suffer >> breakage, and hopefully then do get firmware updated to >> support TLS1.3 or TLS-without-extended-random-or-dual-ec >> at some point. >> > > I think we would like to avoid deliberately breaking these devices with > TLS 1.3. (I think TLS 1.3 has been subject to enough friction already.) > > If key_share is renumbered, then presumably extension 40 would be reserved > by IANA. Thus other implementations could send extension 40 if they wish > not to interoperate with extended_random-supporting peers. > > > Cheers > > AGL > --001a1137abdc0fe980056153af7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PR:
I'll merge this next week, barring strong objection.
<= div>
-Ekr


=
On Tue, Dec 19, 2017 at 8:28 AM, Adam Langley <agl@imperialviolet.org> wrote:
On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farr= ell <stephen.farrell@cs.tcd.ie> wrote:
I'm not sure I agree renumberin= g is the right reaction,
though I don't object to that. This could be a case where
it's overall better that those specific devices suffer
breakage, and hopefully then do get firmware updated to
support TLS1.3 or TLS-without-extended-random-or-dual-ec
at some point.

I think we would = like to avoid deliberately breaking these devices with TLS 1.3. (I think TL= S 1.3 has been subject to enough friction already.)

If key_share is renumbered, then presumably extension 40 would be reserve= d by IANA. Thus other implementations could send extension 40 if they wish = not to interoperate with extended_random-supporting peers.

Cheers

AGL=C2=A0
=

--001a1137abdc0fe980056153af7f-- From nobody Wed Dec 27 08:35:47 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A90BE126DFB; Wed, 27 Dec 2017 08:35:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151439254164.29725.11593056664556441021@ietfa.amsl.com> Date: Wed, 27 Dec 2017 08:35:41 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 16:35:42 -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 WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Connection Identifier Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Tobias Gondrom Filename : draft-ietf-tls-dtls-connection-id-00.txt Pages : 12 Date : 2017-12-27 Abstract: This document specifies the "Connection ID" concept for the Datagram Transport Layer Security (DTLS) protocol, version 1.2 and version 1.3. A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 27 10:35: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 91CF11242F7 for ; Wed, 27 Dec 2017 10:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 k8OfT1cRur6W for ; Wed, 27 Dec 2017 10:35:33 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22943126BF7 for ; Wed, 27 Dec 2017 10:35:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 2785148840; Wed, 27 Dec 2017 20:35:30 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id CS3oX9Qhk9Ci; Wed, 27 Dec 2017 20:35:29 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id AA2052308; Wed, 27 Dec 2017 20:35:27 +0200 (EET) Date: Wed, 27 Dec 2017 20:35:27 +0200 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20171227183527.GA24847@LK-Perkele-VII> References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Dec 2017 18:35:35 -0000 On Wed, Dec 27, 2017 at 07:01:30AM -0800, Eric Rescorla wrote: > PR: > https://github.com/tlswg/tls13-spec/pull/1128 > > I'll merge this next week, barring strong objection. > You might want to rebase that and renumber to #51, now that extension #50 is used for certificate signature algorithms. -Ilari From nobody Wed Dec 27 10: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 A961F12751F for ; Wed, 27 Dec 2017 10:46: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=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 TryC3k4Rk3Jx for ; Wed, 27 Dec 2017 10:46:22 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97AF1272E1 for ; Wed, 27 Dec 2017 10:46:21 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id a82so1682925ybg.1 for ; Wed, 27 Dec 2017 10:46:21 -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=5zvf6JEhMVl0E1Lx0NHuDDwlJj18MYvSlekYokdy7XQ=; b=P2UVopRjhkgjEgiio4I7k7TgsVtEEzSWR3sJhhFHEU1bIUfDbM1qvg+QfR1/5tRELI 7OLkAXgUir+SPEICYIznEq3aq+P4fMzcJ/387lvNrwoaa5gqh+zKjXMLFW0dNei0dJa6 fnKr/zVzYnwh22Oh+kVAJF1WMzegNRBqnBB4jq5guALqcDQuVziUETCReZ/B1VHwfioD mPT0RJly+fAJANGZtZVTMZdn2Ll4lczv4tCGK2YB6ci4dqLsiWKW5d3Ca9cY3btv4O4Q XrxEuym/IPV8BU4MWcr8WJ/FDB/19qkOdMCK8uIJjExMlEFQ2Ds6D+Z+r3Y33vifXNbI dynA== 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=5zvf6JEhMVl0E1Lx0NHuDDwlJj18MYvSlekYokdy7XQ=; b=fBeHP0zhx6RIkQEGkNc43nsrncAGm3jUD/Tmrb6jnh0h385czc/nJfoglan4sdKu/o tvC1TtQGw1zAo8JlLn5xDc9AXRBxYslblTFwqH9qKGf3Ol+QLFFH5VuoB+038RpgPgv2 Rqeof8T89wm9cRxIveZikAiHIGHoO5n/f/8kgzFdszQRPgqGLsYjSbv6edfungGekw6D pBslzKIvPsjk4nEOIS+lbbhSJLcFOBW4LtoUG68jKP0cPT81SP3f2g8n53ZNPLjH28CQ cQi5/5TBpIRRu6UzoGXb7Ltwme3S6Hy2wlwVCjPhllad4/GJfBtWWDUjV3WUHR1MDFZx 3HSA== X-Gm-Message-State: AKGB3mJqiLJpvDqKLYoh92WvrfMzOC7Bc20nw4VFY3s1NcQpjyAKzgMr Q6Vt2KV1zJX508xaVOqecC8V/5eYiKgntxqYk1gsNw== X-Google-Smtp-Source: ACJfBovetCs5EWhC8ztV2mDAmZTy4ZYskUqaRsTB2EScABLZt3dHpWig2ytwNkfeigsF3abn6PTLj95meKffwguHPoY= X-Received: by 10.37.132.18 with SMTP id u18mr1138683ybk.208.1514400381008; Wed, 27 Dec 2017 10:46:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 27 Dec 2017 10:45:40 -0800 (PST) In-Reply-To: <20171227183527.GA24847@LK-Perkele-VII> References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> <20171227183527.GA24847@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 27 Dec 2017 10:45:40 -0800 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08264fc0c20edb056156d068" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Dec 2017 18:46:24 -0000 --089e08264fc0c20edb056156d068 Content-Type: text/plain; charset="UTF-8" Good catch. Thanks. -Ekr On Wed, Dec 27, 2017 at 10:35 AM, Ilari Liusvaara wrote: > On Wed, Dec 27, 2017 at 07:01:30AM -0800, Eric Rescorla wrote: > > PR: > > https://github.com/tlswg/tls13-spec/pull/1128 > > > > I'll merge this next week, barring strong objection. > > > > You might want to rebase that and renumber to #51, now that extension > #50 is used for certificate signature algorithms. > > > -Ilari > --089e08264fc0c20edb056156d068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catch. Thanks.

-Ekr


On Wed, Dec 27, 2017 at 10:35 AM, Ilari Liusvaara &= lt;ilariliusv= aara@welho.com> wrote:
On Wed, Dec 27, 2017 at 07:01:30AM -0800, Eric Rescorla wrote:=
> PR:
> https://github.com/tlswg/tls13-spec/pull/1128=
>
> I'll merge this next week, barring strong objection.
>

You might want to rebase that and renumber to #51, now that extensio= n
#50 is used for certificate signature algorithms.


-Ilari

--089e08264fc0c20edb056156d068-- From nobody Wed Dec 27 11:17:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0AC12D7F0 for ; Wed, 27 Dec 2017 11:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 rhfrSOXD1XFf for ; Wed, 27 Dec 2017 11:17:23 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854691200FC for ; Wed, 27 Dec 2017 11:17:23 -0800 (PST) Received: from [10.44.10.6] (unknown [104.238.169.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 290C3E6F46 for ; Wed, 27 Dec 2017 19:17:21 +0000 (UTC) From: Matt Caswell To: "tls@ietf.org" Message-ID: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> Date: Wed, 27 Dec 2017 19:17:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Dec 2017 19:17:25 -0000 Consider the scenario where a server is operating statelessly (i.e. using the cookie extension) and a client is operating in middlebox compat mode. In that case the client sends an initial ClientHello and receives a ServerHello(HRR) back with a cookie in it. Before it sends its second ClientHello it first sends a dummy CCS. >From the server perspective it is operating statelessly so until it gets a ClientHello with a valid cookie in it, any message it receives is considered the "first" one. Therefore, because the server has forgotten about the initial interaction with the client, the first message it sees is a CCS. Draft-22 says this: "An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time during the handshake and MUST simply drop it without further processing." Does "any time during the handshake" include the very first message it receives? If so then this has implications for servers that accept connections from TLSv1.2 (and below) clients (regardless of whether the server is stateless or not), i.e. an incoming connection that starts with a CCS and then goes on to negotiate TLSv1.2 would be accepted which seems odd. If it doesn't mean that then a stateless server will receive a CCS as the first message and not know how to handle it. Maybe there are different rules for handling CCS for stateless servers? Or perhaps middlebox compat mode should never be used in a scenario where a stateless server is being used (e.g. QUIC). Either way it seems that some clarification of the wording would help. Matt From nobody Wed Dec 27 11:34: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 033FF1275FD for ; Wed, 27 Dec 2017 11:34:17 -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 dTx_CyG0wL01 for ; Wed, 27 Dec 2017 11:34:15 -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 26CEF1275AB for ; Wed, 27 Dec 2017 11:34:15 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id q26so7851826ywa.6 for ; Wed, 27 Dec 2017 11:34:15 -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=SvW8Ey6rl90X7r6QnsW+gbDYn53SRJU2skfX/xlxyOM=; b=gU0YMrQU8QliDCCXW+tdgjlPQCSRiHZIvwyPnNSZT+t+BgIK6P0DdGBfQYtdoVvMaE v2zIIfa92P2kufVsX5NeaX489MufUJSqekct2f0bCT1CrYHwOrPmIqWYElR7KwHF504i Rbpo082r8pJ/06BDxazdv20m3W/xC3ysTpuAtyeRpS00xENUk9siAt7DibGm88ZfXEZP t4k8WHha0QN4V3AQNoypbNXHLWZ+OVyeL6D5bmQFYainD7j7qo1EH/nswyvOwRGLEYYW zGRjlBJFoA1EgU/Wioj+U4SdWBFq+0ygh0MxW0rFa6fszlUUUHcQWdEO73c/wcfTKxso xVpw== 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=SvW8Ey6rl90X7r6QnsW+gbDYn53SRJU2skfX/xlxyOM=; b=KAWrsGSkDVMPtbRQnPHuFZeA2Bght9ibdoUF0vx6i5QAt2EcTVYabZ2kLJ40jrLObf GQgEGcuqdkKYPZvX1oAnEC3FZPoKijZIuksNWj9pjnnOP6osH0zO1k8UD8PxgsRPhhBC 8j5ogDtWjtp+XA2LT7b8/Xj/Gm+nZPIVe8yyj/lk9cjAQxtLYNks5nf7KpXuzAvSBHQH MMUskHdLgLdFuiODRdz999G+z0WQ1VWdjUP4hNRXyOquFrJG17Atl4QfK4lNKXbQJA/I jILmHEZvSH8UujvhQWD9RNU2fwW9YO2bmugw+cKfp6cjtv8gG+n91EhgnoYQoeiYtgf8 kkHw== X-Gm-Message-State: AKGB3mKa7k7D7QLX5mGgetQUJeih2SsS5ODYYGscP9SUvLuFMC1osFZ8 U0lXndcgVLnvw2r0cm5fO5AYbkLi5PcGPT3N89FgxUpD X-Google-Smtp-Source: ACJfBovptMNWzasyyem9Py/o25v+yb1fbdCZfilWMU4mT+wRoiRd/EZI9IngrwbjWPMyhNna4Hdhm1d6SKO6TfTTaHg= X-Received: by 10.129.85.198 with SMTP id j189mr19819633ywb.504.1514403254283; Wed, 27 Dec 2017 11:34:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 27 Dec 2017 11:33:33 -0800 (PST) In-Reply-To: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> From: Eric Rescorla Date: Wed, 27 Dec 2017 11:33:33 -0800 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f169e04c2390561577cff" Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Dec 2017 19:34:17 -0000 --001a113f169e04c2390561577cff Content-Type: text/plain; charset="UTF-8" On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell wrote: > Consider the scenario where a server is operating statelessly (i.e. > using the cookie extension) and a client is operating in middlebox > compat mode. > > In that case the client sends an initial ClientHello and receives a > ServerHello(HRR) back with a cookie in it. Before it sends its second > ClientHello it first sends a dummy CCS. > > >From the server perspective it is operating statelessly so until it gets > a ClientHello with a valid cookie in it, any message it receives is > considered the "first" one. Therefore, because the server has forgotten > about the initial interaction with the client, the first message it sees > is a CCS. > > Draft-22 says this: > > "An implementation may receive an unencrypted record of type > change_cipher_spec consisting of the single byte value 0x01 at any > time during the handshake and MUST simply drop it without further > processing." > > Does "any time during the handshake" include the very first message it > receives? If so then this has implications for servers that accept > connections from TLSv1.2 (and below) clients (regardless of whether the > server is stateless or not), i.e. an incoming connection that starts > with a CCS and then goes on to negotiate TLSv1.2 would be accepted which > seems odd. > > If it doesn't mean that then a stateless server will receive a CCS as > the first message and not know how to handle it. > The way that NSS handles this is to remember that the CCS was received and then if it turns out that you negotiate TLS 1.2, you throw an error in that case. With that said, in most of the cases where you are stateless, you're probably going to want to ignore bogus records anyway, which would include unexpected CCS. -Ekr Maybe there are different rules for handling CCS for stateless servers? Or perhaps middlebox compat mode should never be used in a scenario > where a stateless server is being used (e.g. QUIC). Either way it seems > that some clarification of the wording would help. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113f169e04c2390561577cff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell <matt@openssl.org>= ; wrote:
Consider the scenario whe= re a server is operating statelessly (i.e.
using the cookie extension) and a client is operating in middlebox
compat mode.

In that case the client sends an initial ClientHello and receives a
ServerHello(HRR) back with a cookie in it. Before it sends its second
ClientHello it first sends a dummy CCS.

>From the server perspective it is operating statelessly so until it get= s
a ClientHello with a valid cookie in it, any message it receives is
considered the "first" one. Therefore, because the server has for= gotten
about the initial interaction with the client, the first message it sees is a CCS.

Draft-22 says this:

=C2=A0 "An implementation may receive an unencrypted record of type =C2=A0 =C2=A0change_cipher_spec consisting of the single byte value 0x01 at= any
=C2=A0 =C2=A0time during the handshake and MUST simply drop it without furt= her
=C2=A0 =C2=A0processing."

Does "any time during the handshake" include the very first messa= ge it
receives? If so then this has implications for servers that accept
connections from TLSv1.2 (and below) clients (regardless of whether the
server is stateless or not), i.e. an incoming connection that starts
with a CCS and then goes on to negotiate TLSv1.2 would be accepted which seems odd.

If it doesn't mean that then a stateless server will receive a CCS as the first message and not know how to handle it.

<= /div>

The way that NSS handles this is to remember that = the CCS was received
and then if it turns out that you negoti= ate TLS 1.2, you throw an error in
that case. With that said, in = most of the cases where you are stateless,
you're probably go= ing to want to ignore bogus records anyway, which would
include u= nexpected CCS.

-Ekr


<= /div>

Maybe there are different rules for handling CCS for stateless servers?
Or perhaps middlebox compat mode should never be used in a scenario
where a stateless server is being used (e.g. QUIC). Either way it seems
that some clarification of the wording would help.

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

--001a113f169e04c2390561577cff-- From nobody Wed Dec 27 12:43: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 78995124234 for ; Wed, 27 Dec 2017 12:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dT4MQNV3FDIy for ; Wed, 27 Dec 2017 12:43:43 -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 5BB12126CB6 for ; Wed, 27 Dec 2017 12:43:43 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id d202so23166854qkc.9 for ; Wed, 27 Dec 2017 12:43:43 -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=7T8qMvKZ0jNG3QLST54GnPunIQnARf4BecStD4yCZio=; b=E+PHdSPmL6PsTDz4s92rdaN+eMDM+H9rJiOuK63krbiUtkM6/nfVxQy8CbBazLb+fg 5aGCHsBEyXaEnHFaxi+jsqt/QYm6cM2GLzPMdanRzTcOrkisqkwHFC7u/tMYWmk0qsYt Yg7l7MZlF2+MQJpobSesBtLj+NK75ImBfMtSjSXW1llb4US/mszCcgTAT6+7zd+NoXtw CL6JFcmtN7cKjZAMuexX1/yGKQfGCrwPSXnsVTieQR7MXE7sgXkZjp85k/waBLxBzAsr 4OOthKUexl8wnHiptmKO+npKzgxEIz1wVqF1nCI6bncEN8hfCzZdgA5Fme3JI1fiDQe8 ZsFQ== 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=7T8qMvKZ0jNG3QLST54GnPunIQnARf4BecStD4yCZio=; b=swaIXucR6t/uoAmgsrcK7Wwz2j/wNsV2wwYVzSYwwSmDf/46TG8iJnzWAB0XmReKqT TbRFOoOktM+SuKwQm6Y2HJvwvL8oUPbuEAVgP5y59eYa9LHB8CDLocDCxijnwx4aVsqi fmWKzIlO3r9KczBYZ3aDE3c0aE57owr1T7lx6JGfHHkePNTW68SkB7OESGOGngVS6C7B 7Ju/2IBFzdWm6U90slZXrdrMsy5WMv9anzZmQdWF4Q11rYBFf8ii+YVIoITtRFH+sRd5 3Kkmvv2TzJ+kkKCkPpiExVrCJXQm13pu9NS056puBKE7UAuMWqMYxdlmMzQ/RjYqTe3C /yzg== X-Gm-Message-State: AKGB3mIdthYMJbpfroU/2YkImGxZUBlWho/MBhqOa4xhznqoTEOYViJN CqwZzzGIHbDJeUM6iaAW7I9JEBWGRG2iGUp768Vwtg== X-Google-Smtp-Source: ACJfBouHUM5t+Aij8r+3Jb8tHhgFVVjrSnn1Tf7XreByck9suSlAtNo//hxGSAuUZ6xw8GDqUTexBHhC19UGxf4gqu4= X-Received: by 10.55.169.139 with SMTP id s133mr25976907qke.355.1514407422082; Wed, 27 Dec 2017 12:43:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.233.237.211 with HTTP; Wed, 27 Dec 2017 12:43:41 -0800 (PST) In-Reply-To: References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171214214650.GA15254@LK-Perkele-VII> From: Victor Vasiliev Date: Wed, 27 Dec 2017 15:43:41 -0500 Message-ID: To: David Benjamin Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0727e27108330561587463" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 20:43:45 -0000 --94eb2c0727e27108330561587463 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 14, 2017 at 5:43 PM, David Benjamin wrote: > Another observation about the middlebox issue: if we leave the text as-is, > where it is defined for TLS 1.2 server certificates, but we all silently > agree that servers should decline it at TLS 1.2, clients are still > obligated to implement it in their TLS 1.2 state machine because the > advertisement is the same. > > If we're never going to deploy it in TLS 1.2 anyway, this seems like a > waste of the complexity budget. Better to say it is not defined for TLS 1.2 > at all because of non-compliant middleboxes and avoid all this ambiguity. > This is a good point. I've written a PR to change the extension to 1.3-only: https://github.com/tlswg/certificate-compression/pull/9 --94eb2c0727e27108330561587463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--94eb2c0727e27108330561587463-- From nobody Thu Dec 28 00:54: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 060BA124D6C for ; Thu, 28 Dec 2017 00:54:31 -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 VJvTZHIckUZZ for ; Thu, 28 Dec 2017 00:54:29 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC477124B17 for ; Thu, 28 Dec 2017 00:54:29 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id e2so50497091qti.0 for ; Thu, 28 Dec 2017 00:54:29 -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=zQ9jGnhscBSZUwvWlSluOJPgauk+P96ASzEhTnWPr4w=; b=Z+6of4oEY9j8ubM5jogplo1I/k/u6P9D6yfyUgwFFK49VSMzfz8rqM3e2Hp7UmIL7f Hj+K2xKb+UlaYMqCZvK1pv3ZIa5YvFDJ3S4sV1ARXRYre2JcqpJ/+SVG+EDwCkJ72PPM BvO3SLvsd+9ognvGQ7oFJU661kWJ1jKD/npJOX+HlSKm0QhS8V5PzUlXSdAASoTaceYN Rfwb1kZs76exS5CNxC4x7lp/me+bnSyLa875AnbHhCbE8bw0IwXirI3sXHVB+SrYKqCM 4g9T4cgYO+M7NQsoSg5JuHIEjDf9XWMshhy71+F8tPnUCVwMtuYJrAHdt2qCjoaR4ii3 2w2Q== 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=zQ9jGnhscBSZUwvWlSluOJPgauk+P96ASzEhTnWPr4w=; b=tGP2LwY81zM8X9iF9XFON6UZTf0+r54p4A3I351XlA2olcOEEnNEbBXJ5F39IVg0AO W2XjL3QU/A8WOUUxJQ7rjRE4DA7VM5m1hGOcqXOxq8WWT9qW6P35ds7bFVrnYVWPtx6/ LVpLoFyt5vjKUOauRsQulQGpzrvbOI6HWpdwNmXnUYHAx8Ugk3IwZ63+2QOsMZ7QslyL 6lStgUu2Ru0EZCFHLuaRStCUrstQtJokahQuFu9JVFYzqlVHf9IGZUMTG40mM4vzDbit ArNzQVpzVgz6rLR4ZyctDkvmv0Mxyf13aXwSNMmHoAGwlppfRc55JTuA4nme9PAlW/3r HnpA== X-Gm-Message-State: AKGB3mJO01pKa+BFA60jAZMy/omPJkmmRL51mWtoHt6QbgblqZfDT8pm QbE2Pjp3s5tXES2jVVA6A+lUj1L5rkOOxpSa/QE= X-Google-Smtp-Source: ACJfBovShDJZFIeuNXpuAfxnm+ll7wKn3I2M74XRQduBZJNINYUtfjdlTtS+sXixJ83AjJYwHzr2Sm483JdUXi0nKWM= X-Received: by 10.237.59.22 with SMTP id p22mr41295037qte.34.1514451268710; Thu, 28 Dec 2017 00:54:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.106.136 with HTTP; Thu, 28 Dec 2017 00:54:28 -0800 (PST) In-Reply-To: References: <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> <20171227183527.GA24847@LK-Perkele-VII> From: David Wong Date: Thu, 28 Dec 2017 09:54:28 +0100 Message-ID: To: Eric Rescorla Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Additional TLS 1.3 results from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 08:54:31 -0000 > I think we would like to avoid deliberately breaking these devices with TLS 1.3. (I think TLS 1.3 has been subject to enough friction already.) I'm not sure I can agree with fixing TLS 1.3 so that it can work with potentially backdoored devices. Isn't it the kind of friction we would want? David From nobody Thu Dec 28 00:54:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6514A12D85F for ; Thu, 28 Dec 2017 00:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 lFY6T9Yitek2 for ; Thu, 28 Dec 2017 00:54:49 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6B112D858 for ; Thu, 28 Dec 2017 00:54:48 -0800 (PST) Received: from [10.17.10.6] (unknown [104.238.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id DA470E6F68; Thu, 28 Dec 2017 08:54:46 +0000 (UTC) To: Eric Rescorla Cc: "tls@ietf.org" References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> From: Matt Caswell Message-ID: <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> Date: Thu, 28 Dec 2017 08:54:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 08:54:51 -0000 On 27/12/17 19:33, Eric Rescorla wrote: > > > On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell > wrote: > > Consider the scenario where a server is operating statelessly (i.e. > using the cookie extension) and a client is operating in middlebox > compat mode. > > In that case the client sends an initial ClientHello and receives a > ServerHello(HRR) back with a cookie in it. Before it sends its second > ClientHello it first sends a dummy CCS. > > >From the server perspective it is operating statelessly so until it > gets > a ClientHello with a valid cookie in it, any message it receives is > considered the "first" one. Therefore, because the server has forgotten > about the initial interaction with the client, the first message it sees > is a CCS. > > Draft-22 says this: > >   "An implementation may receive an unencrypted record of type >    change_cipher_spec consisting of the single byte value 0x01 at any >    time during the handshake and MUST simply drop it without further >    processing." > > Does "any time during the handshake" include the very first message it > receives? If so then this has implications for servers that accept > connections from TLSv1.2 (and below) clients (regardless of whether the > server is stateless or not), i.e. an incoming connection that starts > with a CCS and then goes on to negotiate TLSv1.2 would be accepted which > seems odd. > > If it doesn't mean that then a stateless server will receive a CCS as > the first message and not know how to handle it. > > > > The way that NSS handles this is to remember that the CCS was received > and then if it turns out that you negotiate TLS 1.2, you throw an error in > that case. With that said, in most of the cases where you are stateless, > you're probably going to want to ignore bogus records anyway, which would > include unexpected CCS. So, do you believe that the correct interpretation of "any time during the handshake" includes the first message? I think it would be helpful to be more explicit in the text if that is the case, i.e. identify the first point in the handshake and the last point in the handshake where CCS is valid. There probably should also be some words about how servers implementing older TLS versions should handle a CCS that comes first. However, I'm concerned about the added complexity of interpreting things that way. Suddenly a CCS arriving is no longer handled by just dropping it and forgetting it - you now have to store state about that and remember it later on in the process in other TLS versions. The CCS workaround was supposed to be a simple no-op to implement and it no longer appears that way in this interpretation. Matt From nobody Thu Dec 28 04:29: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 A465012D87C for ; Thu, 28 Dec 2017 04:29:15 -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 bRzIwX3KUf8f for ; Thu, 28 Dec 2017 04:29:13 -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 984211201F2 for ; Thu, 28 Dec 2017 04:29:13 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id g191so8439116ywe.7 for ; Thu, 28 Dec 2017 04:29:13 -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=jS2SPJ7SosCoiN1vjaN+AgAliqjIIfBNay2bg99jc4E=; b=pQzdYholUjhdL9Z8tOORC0/R0C+HJyZfFbnmZRKUctQK3VaqXuY36ch0NEgfqXdgEz T+ben67cAoA+JNFmIv5G1ZFtLD5yxhIN1JFNnzJeyLgD8Hr2ulQltpsFuVsPjIquHZri umbcan34yvLcXNKa4FyjUUG19SmyS+3PEk6TACw1pxytwDrM4NUTmgJSSmEJeritYgRS jeq/snmp3bGXrD8jIK1uPUz/lQztF7kZpm2ILhD7qBdkf3J+AYXDwdKikLEI00nq00Er P3+qKMtsLWLZmw6UADJqhTnu+co5e3C0ERanWfNxLn3up8DMszcXVjmyO20zY1h2Hfe4 PBBQ== 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=jS2SPJ7SosCoiN1vjaN+AgAliqjIIfBNay2bg99jc4E=; b=I6N/FCV25XpgRO8xMjOnj09LmmiHJtZatTaalpoO4gPa8zd/4iCvPz0w38GknqsFm6 emdpnXb+rVhrfKNbcQpY9OIBEXPhoHVfWno/9U7rlNnAQ/Ln5e2+GsjurItgwBjrOlVy NNFukoijbwRjb2SNikTyutcNFGimobYnZHQoeLU/474BpOdfY44HN3QriYTz9vHrNXf9 Ptku4QZdmitNpmz8X2cRIHsauq3BBAO/0ldm+eCjy7EeVTh2UXtddR4iirSYPhpfTYox vw6bfxHyJd2CvBJSlMmAKNFM/xIDmAz/A4v/+8aS/viRRf+zm5YxzffsEiqpwbyTYnQw Bq5A== X-Gm-Message-State: AKGB3mKC9/BLoIpcXbqGB5+iv7oGe55IdObNrdrxBaqnPc/PQMFASKmf r+otWciaGXulQpywpZ/4G2V6KhYZdj89WOrBT/1zyw== X-Google-Smtp-Source: ACJfBouL+ZFO4iIszMt/MkMtFa0bR6TuagIDifOxfb9221ZAzFyEkENcoiHD2mIwM3jq7VUwJphzetfCRHVNrgQSOoU= X-Received: by 10.129.154.22 with SMTP id r22mr21046457ywg.296.1514464152834; Thu, 28 Dec 2017 04:29:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 28 Dec 2017 04:28:32 -0800 (PST) In-Reply-To: <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> From: Eric Rescorla Date: Thu, 28 Dec 2017 04:28:32 -0800 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0bb4e8daec2a056165a9c2" Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 12:29:16 -0000 --94eb2c0bb4e8daec2a056165a9c2 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 28, 2017 at 12:54 AM, Matt Caswell wrote: > > > On 27/12/17 19:33, Eric Rescorla wrote: > > > > > > On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell > > wrote: > > > > Consider the scenario where a server is operating statelessly (i.e. > > using the cookie extension) and a client is operating in middlebox > > compat mode. > > > > In that case the client sends an initial ClientHello and receives a > > ServerHello(HRR) back with a cookie in it. Before it sends its second > > ClientHello it first sends a dummy CCS. > > > > >From the server perspective it is operating statelessly so until it > > gets > > a ClientHello with a valid cookie in it, any message it receives is > > considered the "first" one. Therefore, because the server has > forgotten > > about the initial interaction with the client, the first message it > sees > > is a CCS. > > > > Draft-22 says this: > > > > "An implementation may receive an unencrypted record of type > > change_cipher_spec consisting of the single byte value 0x01 at any > > time during the handshake and MUST simply drop it without further > > processing." > > > > Does "any time during the handshake" include the very first message > it > > receives? If so then this has implications for servers that accept > > connections from TLSv1.2 (and below) clients (regardless of whether > the > > server is stateless or not), i.e. an incoming connection that starts > > with a CCS and then goes on to negotiate TLSv1.2 would be accepted > which > > seems odd. > > > > If it doesn't mean that then a stateless server will receive a CCS as > > the first message and not know how to handle it. > > > > > > > > The way that NSS handles this is to remember that the CCS was received > > and then if it turns out that you negotiate TLS 1.2, you throw an error > in > > that case. With that said, in most of the cases where you are stateless, > > you're probably going to want to ignore bogus records anyway, which would > > include unexpected CCS. > > So, do you believe that the correct interpretation of "any time during > the handshake" includes the first message? Yes, this is how we have interpreted it > I think it would be helpful > to be more explicit in the text if that is the case, i.e. identify the > first point in the handshake and the last point in the handshake where > CCS is valid. There probably should also be some words about how servers > implementing older TLS versions should handle a CCS that comes first. > I could add those. However, I'm concerned about the added complexity of interpreting things > that way. Suddenly a CCS arriving is no longer handled by just dropping > it and forgetting it - you now have to store state about that and > remember it later on in the process in other TLS versions. The CCS > workaround was supposed to be a simple no-op to implement and it no > longer appears that way in this interpretation. Well, it seems like the issue here is you want the client to send CH1, CCS, CH2 so we need the server to accept that. Am I missing something? -Ekr --94eb2c0bb4e8daec2a056165a9c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Dec 28, 2017 at 12:54 AM, Matt Caswell <matt@openssl.org> wrote:


On 27/12/17 19:33, Eric Rescorla wrote:
>
>
> On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell <matt@openssl.org
> <mailto:matt@openssl.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Consider the scenario where a server is operating s= tatelessly (i.e.
>=C2=A0 =C2=A0 =C2=A0using the cookie extension) and a client is operati= ng in middlebox
>=C2=A0 =C2=A0 =C2=A0compat mode.
>
>=C2=A0 =C2=A0 =C2=A0In that case the client sends an initial ClientHell= o and receives a
>=C2=A0 =C2=A0 =C2=A0ServerHello(HRR) back with a cookie in it. Before i= t sends its second
>=C2=A0 =C2=A0 =C2=A0ClientHello it first sends a dummy CCS.
>
>=C2=A0 =C2=A0 =C2=A0>From the server perspective it is operating sta= telessly so until it
>=C2=A0 =C2=A0 =C2=A0gets
>=C2=A0 =C2=A0 =C2=A0a ClientHello with a valid cookie in it, any messag= e it receives is
>=C2=A0 =C2=A0 =C2=A0considered the "first" one. Therefore, be= cause the server has forgotten
>=C2=A0 =C2=A0 =C2=A0about the initial interaction with the client, the = first message it sees
>=C2=A0 =C2=A0 =C2=A0is a CCS.
>
>=C2=A0 =C2=A0 =C2=A0Draft-22 says this:
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 "An implementation may receive an unenc= rypted record of type
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0change_cipher_spec consisting of the s= ingle byte value 0x01 at any
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0time during the handshake and MUST sim= ply drop it without further
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0processing."
>
>=C2=A0 =C2=A0 =C2=A0Does "any time during the handshake" incl= ude the very first message it
>=C2=A0 =C2=A0 =C2=A0receives? If so then this has implications for serv= ers that accept
>=C2=A0 =C2=A0 =C2=A0connections from TLSv1.2 (and below) clients (regar= dless of whether the
>=C2=A0 =C2=A0 =C2=A0server is stateless or not), i.e. an incoming conne= ction that starts
>=C2=A0 =C2=A0 =C2=A0with a CCS and then goes on to negotiate TLSv1.2 wo= uld be accepted which
>=C2=A0 =C2=A0 =C2=A0seems odd.
>
>=C2=A0 =C2=A0 =C2=A0If it doesn't mean that then a stateless server= will receive a CCS as
>=C2=A0 =C2=A0 =C2=A0the first message and not know how to handle it. >
>
>
> The way that NSS handles this is to remember that the CCS was received=
> and then if it turns out that you negotiate TLS 1.2, you throw an erro= r in
> that case. With that said, in most of the cases where you are stateles= s,
> you're probably going to want to ignore bogus records anyway, whic= h would
> include unexpected CCS.

So, do you believe that the correct interpretation of "any= time during
the handshake" includes the first message?

Yes, this is how we have interpreted it

=C2= =A0
I think it would be helpful
to be more explicit in the text if that is the case, i.e. identify the
first point in the handshake and the last point in the handshake where
CCS is valid. There probably should also be some words about how servers implementing older TLS versions should handle a CCS that comes first.

I could add those.

=
However, I'm concerned about the added complexity of interpreting thing= s
that way. Suddenly a CCS arriving is no longer handled by just dropping
it and forgetting it - you now have to store state about that and
remember it later on in the process in other TLS versions. The CCS
workaround was supposed to be a simple no-op to implement and it no
longer appears that way in this interpretation.

=
Well, it seems like the issue here is you want the client to send CH1,= CCS, CH2
so we need the server to accept that. Am I missing some= thing?

-Ekr

--94eb2c0bb4e8daec2a056165a9c2-- From nobody Thu Dec 28 05:01: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 AFB57127873 for ; Thu, 28 Dec 2017 05:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 BDNtIaMSTFwl for ; Thu, 28 Dec 2017 05:01:32 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395AC126D46 for ; Thu, 28 Dec 2017 05:01:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 56C48B4D20; Thu, 28 Dec 2017 15:01:29 +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 s82PRta260eX; Thu, 28 Dec 2017 15:01:29 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5FA6DC4; Thu, 28 Dec 2017 14:54:31 +0200 (EET) Date: Thu, 28 Dec 2017 14:54:31 +0200 From: Ilari Liusvaara To: Matt Caswell Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20171228125430.GA5837@LK-Perkele-VII> References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 13:01:35 -0000 On Thu, Dec 28, 2017 at 08:54:45AM +0000, Matt Caswell wrote: > > So, do you believe that the correct interpretation of "any time during > the handshake" includes the first message? I think it would be helpful > to be more explicit in the text if that is the case, i.e. identify the > first point in the handshake and the last point in the handshake where > CCS is valid. There probably should also be some words about how servers > implementing older TLS versions should handle a CCS that comes first. > > However, I'm concerned about the added complexity of interpreting things > that way. Suddenly a CCS arriving is no longer handled by just dropping > it and forgetting it - you now have to store state about that and > remember it later on in the process in other TLS versions. The CCS > workaround was supposed to be a simple no-op to implement and it no > longer appears that way in this interpretation. To me it seems like if you are doing a stateless retry, you can not fail the handshake if you receive CCS between the two CHs. In fact, more generally you can not fail the handshake if you receive arbitrary junk between the two CHs (as long as the junk does not mess framing of the later CH). Here "can not fail" does not mean requirement on implementation, it is fundamential constraint due to stateless implementation (because failing would require keeping state!). I think there should be note about this in the specification (that stateless implementations need to ignore arbitrary junk records and messages before the ClientHello message). However, this causes problems if the junk contains any handshke messages that are fragmented. Especially so if the underlying transport not reliable. This is the same problem as why fragmenting ClientHello is a bad idea. -Ilari From nobody Thu Dec 28 08:13: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 2EBBC12AF83 for ; Thu, 28 Dec 2017 08:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SBL_CSS=3.335, T_RP_MATCHES_RCVD=-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 3moxvcPnmnxI for ; Thu, 28 Dec 2017 08:12:57 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04151120721 for ; Thu, 28 Dec 2017 08:12:56 -0800 (PST) Received: from [10.75.10.6] (unknown [104.238.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 955AEE3685; Thu, 28 Dec 2017 16:12:54 +0000 (UTC) To: Eric Rescorla Cc: "tls@ietf.org" References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> From: Matt Caswell Message-ID: <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> Date: Thu, 28 Dec 2017 16:12:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 16:12:59 -0000 On 28/12/17 12:28, Eric Rescorla wrote: > I think it would be helpful > to be more explicit in the text if that is the case, i.e. identify the > first point in the handshake and the last point in the handshake where > CCS is valid. There probably should also be some words about how servers > implementing older TLS versions should handle a CCS that comes first. > > > I could add those. > > > However, I'm concerned about the added complexity of interpreting things > that way. Suddenly a CCS arriving is no longer handled by just dropping > it and forgetting it - you now have to store state about that and > remember it later on in the process in other TLS versions. The CCS > workaround was supposed to be a simple no-op to implement and it no > longer appears that way in this interpretation. > > > Well, it seems like the issue here is you want the client to send CH1, > CCS, CH2 > so we need the server to accept that. Am I missing something? The point is a stateless server will not know about CH1 at the point that it receives CCS. Actually, as Ilari points out, there could be any junk (including partial records) arriving between CH1 and CH2. So this feels more like a special case for stateless servers. In other words I would prefer to say that a CCS that arrives first is not allowed. That simplifies the general case and requires no special coding for servers implementing older versions of TLS. However, we add additional words around what stateless servers do with "junk" they receive that doesn't look like a ClientHello (i.e. they ditch it). That "junk" would include a CCS. That seems like a much cleaner solution. Matt From nobody Thu Dec 28 09:43: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 1906E1243FE for ; Thu, 28 Dec 2017 09:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meZ9WD-yaxAi for ; Thu, 28 Dec 2017 09:43:09 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2098C126DC2 for ; Thu, 28 Dec 2017 09:43:09 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id f16so664560ybn.0 for ; Thu, 28 Dec 2017 09:43:09 -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=s4BqBOlm51V63Okxnyl68V7E9rSV3PzPuyqflMaX16E=; b=sSMd8FrchKdm0HnYkWD6vTaUliIOq+NQvayZR7YZ8Ae3LL529SyEKRGZy79uuHyqNu n3zezEy7JpuiLuqh4c3xixVOyhlVxbWQTm7iSabp2CBHSNHf3QDO1O5bN6Ee7lga/65/ L0y2NaN6O0nOr4x0dFFH79f87kcwZ4RCusQzTpu68dhSftzCRvIshY6hKfpwuU+m0QLI 6G6tUDw7mDkVK+bzpZS5KxWstEMke2RUfN6TfrL+zFRM3xHPDwPChGHkjj/bdu3OVtek QK/iKc4iU53aom8fLOSOVPyip4X+TMd7alxiijEXcA/XqBGt/cuuqzETklrRRTKo1EZL f8bg== 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=s4BqBOlm51V63Okxnyl68V7E9rSV3PzPuyqflMaX16E=; b=rPDA4cYacUGobk+BeZ4eJ+oGw9W71TWTrVA4Us3ZQVIgMi40DEoYdrd7GWHOX/UznO 9PAep/FAEU06FoFnmA6uQZ2/3X7RBVyqo1/DCHD1xg6sOBrsCjoXQwyb+Cf+y+RDkJl5 GwD1vU/S+UDDagicz6qKaqDljK0wbt9a3ufSJbSgCOe9Zsi6AZQa0KDdKVOuxMWWtf5K R9gsnCj/lu5vH+Vg/CnVHSlR26mvz7eWPVLTiwUuWQA5np9gwrCcRtHNVUBx5xeaQPeq yda2trk69T2YAxtkXHZvtIBhJS3isBJnXi8zC6WoHV/4Y6Hya1WW6k8B/5wXxeVAq4MX Q/Hg== X-Gm-Message-State: AKGB3mL174gWD4wbcDG26y/sv1EUi/tQw1wsDuxze7Jf5W84IM09aBSe VrDaUPdJHJvvUXw2m4ie//UmE9LhoeIrJNj/MqedMmm/ X-Google-Smtp-Source: ACJfBotnOOS0v/VEsySUhOneStY7WHl13z5PjRF81zfvxuBZwVvie+c9WBI+nzo2vKT9+c9e0DwgtoBLZ3SswqRrOwA= X-Received: by 10.37.134.137 with SMTP id z9mr7292098ybk.497.1514482988023; Thu, 28 Dec 2017 09:43:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 28 Dec 2017 09:42:27 -0800 (PST) In-Reply-To: <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> From: Eric Rescorla Date: Thu, 28 Dec 2017 09:42:27 -0800 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e082608f08514a505616a0c91" Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 17:43:12 -0000 --089e082608f08514a505616a0c91 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell wrote: > > > On 28/12/17 12:28, Eric Rescorla wrote: > > I think it would be helpful > > to be more explicit in the text if that is the case, i.e. identify > the > > first point in the handshake and the last point in the handshake > where > > CCS is valid. There probably should also be some words about how > servers > > implementing older TLS versions should handle a CCS that comes first. > > > > > > I could add those. > > > > > > However, I'm concerned about the added complexity of interpreting > things > > that way. Suddenly a CCS arriving is no longer handled by just > dropping > > it and forgetting it - you now have to store state about that and > > remember it later on in the process in other TLS versions. The CCS > > workaround was supposed to be a simple no-op to implement and it no > > longer appears that way in this interpretation. > > > > > > Well, it seems like the issue here is you want the client to send CH1, > > CCS, CH2 > > so we need the server to accept that. Am I missing something? > > The point is a stateless server will not know about CH1 at the point > that it receives CCS. Well, sort of. Specifically, there are three valid things that a server (whether stateless or stateful) can receive: - CH1 [I.e. a CH without a cookie] - CH2 [i.e., a CH with a cookie] - CCS It should respond to any other message with an alert and abort the handshake. A stateful server should also tear down the transport connection, so that subsequent messages are considered an error. This obviously isn't an option for a stateless server, so, yes, a stateless server might in principle receive arbitrary amounts of junk before CH1 or between CH1 and CH2, and it would still survive, albeit by sending alerts. > Actually, as Ilari points out, there could be any > junk (including partial records) arriving between CH1 and CH2. So this > feels more like a special case for stateless servers. > > In other words I would prefer to say that a CCS that arrives first is > not allowed. That simplifies the general case and requires no special > coding for servers implementing older versions of TLS. This issue only seems to arise for people who are both doing TLS 1.3 and TLS 1.2 *and* doing stateless implementations, which is kind of an odd configuration because a number of the conditions in TLS 1.3 that involve HRR (and thus can be stateless). It doesn't arise for QUIC (because no TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of junk). Or am I wrong? However, we add > additional words around what stateless servers do with "junk" they > receive that doesn't look like a ClientHello (i.e. they ditch it). That > "junk" would include a CCS. That seems like a much cleaner solution. > I'm not enthusiastic about this, as it entails not alerting in cases of clear protocol error. -Ekr > Matt > > --089e082608f08514a505616a0c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <matt@openssl.org>= wrote:


On 28/12/17 12:28, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0I think it would be helpful
>=C2=A0 =C2=A0 =C2=A0to be more explicit in the text if that is the case= , i.e. identify the
>=C2=A0 =C2=A0 =C2=A0first point in the handshake and the last point in = the handshake where
>=C2=A0 =C2=A0 =C2=A0CCS is valid. There probably should also be some wo= rds about how servers
>=C2=A0 =C2=A0 =C2=A0implementing older TLS versions should handle a CCS= that comes first.
>
>
> I could add those.
>
>
>=C2=A0 =C2=A0 =C2=A0However, I'm concerned about the added complexi= ty of interpreting things
>=C2=A0 =C2=A0 =C2=A0that way. Suddenly a CCS arriving is no longer hand= led by just dropping
>=C2=A0 =C2=A0 =C2=A0it and forgetting it - you now have to store state = about that and
>=C2=A0 =C2=A0 =C2=A0remember it later on in the process in other TLS ve= rsions. The CCS
>=C2=A0 =C2=A0 =C2=A0workaround was supposed to be a simple no-op to imp= lement and it no
>=C2=A0 =C2=A0 =C2=A0longer appears that way in this interpretation.
>
>
> Well, it seems like the issue here is you want the client to send CH1,=
> CCS, CH2
> so we need the server to accept that. Am I missing something?

The point is a stateless server will not know about CH1 at the point=
that it receives CCS.

Well, sort of.
<= div>
Specifically, there are three valid things that a server= (whether stateless
or stateful) can receive:

- CH1 [I.e. a CH without a cookie]
- CH2 [i.e., a CH with a= cookie]
- CCS

It should respond to any = other message with an alert and abort the handshake.
A stateful s= erver should also tear down the transport connection, so that subsequent
messages are considered an error. This obviously isn't an o= ption for a stateless server,
so, yes, a stateless server might i= n principle receive arbitrary amounts of junk
before CH1 or betwe= en CH1 and CH2, and it would still survive, albeit by
sending ale= rts.

=C2=A0
Ho= wever, we add
additional words around what stateless servers do with "junk" the= y
receive that doesn't look like a ClientHello (i.e. they ditch it). That=
"junk" would include a CCS. That seems like a much cleaner soluti= on.

I'm not enthusiastic about this= , as it entails not alerting in cases of clear
protocol error.

-Ekr



Matt


--089e082608f08514a505616a0c91-- From nobody Thu Dec 28 09:51: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 EB7ED12D86E for ; Thu, 28 Dec 2017 09:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SBL_CSS=3.335, T_RP_MATCHES_RCVD=-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 UqK7tmeMdNrV for ; Thu, 28 Dec 2017 09:51:31 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB801243FE for ; Thu, 28 Dec 2017 09:51:31 -0800 (PST) Received: from [10.75.10.6] (unknown [104.238.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 5F1D3E6F8D; Thu, 28 Dec 2017 17:51:29 +0000 (UTC) To: Eric Rescorla Cc: "tls@ietf.org" References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> From: Matt Caswell Message-ID: Date: Thu, 28 Dec 2017 17:51:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 17:51:34 -0000 On 28/12/17 17:42, Eric Rescorla wrote: > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell > wrote: > > > > On 28/12/17 12:28, Eric Rescorla wrote: > >     I think it would be helpful > >     to be more explicit in the text if that is the case, i.e. identify the > >     first point in the handshake and the last point in the handshake where > >     CCS is valid. There probably should also be some words about how servers > >     implementing older TLS versions should handle a CCS that comes first. > > > > > > I could add those. > > > > > >     However, I'm concerned about the added complexity of interpreting things > >     that way. Suddenly a CCS arriving is no longer handled by just dropping > >     it and forgetting it - you now have to store state about that and > >     remember it later on in the process in other TLS versions. The CCS > >     workaround was supposed to be a simple no-op to implement and it no > >     longer appears that way in this interpretation. > > > > > > Well, it seems like the issue here is you want the client to send CH1, > > CCS, CH2 > > so we need the server to accept that. Am I missing something? > > The point is a stateless server will not know about CH1 at the point > that it receives CCS. > > > Well, sort of. > > Specifically, there are three valid things that a server (whether stateless > or stateful) can receive: > > - CH1 [I.e. a CH without a cookie] > - CH2 [i.e., a CH with a cookie] > - CCS > > It should respond to any other message with an alert and abort the > handshake. > A stateful server should also tear down the transport connection, so > that subsequent > messages are considered an error. This obviously isn't an option for a > stateless server, > so, yes, a stateless server might in principle receive arbitrary amounts > of junk > before CH1 or between CH1 and CH2, and it would still survive, albeit by > sending alerts. > >   > > Actually, as Ilari points out, there could be any > junk (including partial records) arriving between CH1 and CH2. So this > feels more like a special case for stateless servers. > > In other words I would prefer to say that a CCS that arrives first is > not allowed. That simplifies the general case and requires no special > coding for servers implementing older versions of TLS. > > > This issue only seems to arise for people who are both doing TLS 1.3 and > TLS 1.2 *and* doing stateless implementations, which is kind of an odd > configuration because a number of the conditions in TLS 1.3 that involve > HRR (and thus can be stateless). It doesn't arise for QUIC (because no > TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of > junk).  Or am I wrong? Correct, although technically the wording of draft-22 (in your interpretation) *requires* that a server receiving a CCS first MUST ignore it - even though that should never happen except in the weird scenario above. That is why I prefer to say that a CCS arriving first is always an error for the general case. Matt From nobody Thu Dec 28 09:56: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 5928D12D964 for ; Thu, 28 Dec 2017 09:56:02 -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 fXTzwdVCE0dG for ; Thu, 28 Dec 2017 09:56:00 -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 378A712D962 for ; Thu, 28 Dec 2017 09:56:00 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id n25so8727398ywh.10 for ; Thu, 28 Dec 2017 09:56:00 -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=HbLujKEJk4Sym7Zlmy2vKNi2fEk2qLN27RHfCLaWPos=; b=aX5zRWtPfH1ooVamqu1IS7KJt17jxmjNuL8AZW/LBoq6zezXIfUgwbMf7UyDPvRk4S inh0T/EmPTPXlnce/VKd6QCXLfbEFd5Lre1/LwtfHqdLLOOWfCEFzBokJwReocf1UEjH zhwWSNYQwAdMjM+PjAA4uLaEox8gM4HqN+rvUuw8TH11sCOXvR1X3OwVwaqXoJcZgT0U +FHSqcjAUHIJwjWVKM2FDmL5fx1FSGZaORGrDQEcy3f/L+6EW6EmZpNxsuSkbdt0ISOl imaOHVnulRlyJtBu8wPrsID8VadtbAEk3ONz6zyqx1lZw4q51dLceK6ataoNIv/1BNgW uxlw== 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=HbLujKEJk4Sym7Zlmy2vKNi2fEk2qLN27RHfCLaWPos=; b=CQUnC1RHGVQNTQ1t+TWK9v0FgIfEkRa79LxwGRYludePJgVK/nyCFZebisYdPyp+0V pTOP3vm269VKfYBq3/VkC8jG0RTbx3PADCVnKFI58AbqLF7ZhiQWiGTsIzHndLr5AIpG Y6BIFyDULz4bkqPYx9Bj5WVhB+GyImesClA+iX1lHD0E8Ix2m5i/kVBZ+oSAJct3rV1n LOzmZnkBpexyTUWlTFHVWtPiPyY7LCmCvY6MhQaX4+Kekxb6uvxsrwqlj2eJBWlSDMsn rQt1IDy0izqGNuoslHRtvF8YPtKYi5ODwH40NSg7vsNSV8M3B3CG9ueno2kOrrnP2VdE 4aCg== X-Gm-Message-State: AKGB3mL7CrL7+9qd4Ct4YS192bneC9tt76nKlQE93eYtYzaLhbsr4KSi dCg+E/m2dTwHD4pW0JVCl5ZGvYFtB26Up7RF/BjnPQ== X-Google-Smtp-Source: ACJfBosGfLNtE+UXJoAkmy5mW5racOfrV+2kDxzSMeb0ffqB0bjjS3Mb+Mi3HWYjNMKgP8QX3hxcs3xiWFJEX6GmBcQ= X-Received: by 10.129.85.198 with SMTP id j189mr21738710ywb.504.1514483759299; Thu, 28 Dec 2017 09:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 28 Dec 2017 09:55:18 -0800 (PST) In-Reply-To: References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> From: Eric Rescorla Date: Thu, 28 Dec 2017 09:55:18 -0800 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f169e7ddc4a05616a3a82" Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 17:56:02 -0000 --001a113f169e7ddc4a05616a3a82 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell wrote: > > > On 28/12/17 17:42, Eric Rescorla wrote: > > > > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell > > wrote: > > > > > > > > On 28/12/17 12:28, Eric Rescorla wrote: > > > I think it would be helpful > > > to be more explicit in the text if that is the case, i.e. > identify the > > > first point in the handshake and the last point in the > handshake where > > > CCS is valid. There probably should also be some words about > how servers > > > implementing older TLS versions should handle a CCS that comes > first. > > > > > > > > > I could add those. > > > > > > > > > However, I'm concerned about the added complexity of > interpreting things > > > that way. Suddenly a CCS arriving is no longer handled by just > dropping > > > it and forgetting it - you now have to store state about that > and > > > remember it later on in the process in other TLS versions. The > CCS > > > workaround was supposed to be a simple no-op to implement and > it no > > > longer appears that way in this interpretation. > > > > > > > > > Well, it seems like the issue here is you want the client to send > CH1, > > > CCS, CH2 > > > so we need the server to accept that. Am I missing something? > > > > The point is a stateless server will not know about CH1 at the point > > that it receives CCS. > > > > > > Well, sort of. > > > > Specifically, there are three valid things that a server (whether > stateless > > or stateful) can receive: > > > > - CH1 [I.e. a CH without a cookie] > > - CH2 [i.e., a CH with a cookie] > > - CCS > > > > It should respond to any other message with an alert and abort the > > handshake. > > A stateful server should also tear down the transport connection, so > > that subsequent > > messages are considered an error. This obviously isn't an option for a > > stateless server, > > so, yes, a stateless server might in principle receive arbitrary amounts > > of junk > > before CH1 or between CH1 and CH2, and it would still survive, albeit by > > sending alerts. > > > > > > > > Actually, as Ilari points out, there could be any > > junk (including partial records) arriving between CH1 and CH2. So > this > > feels more like a special case for stateless servers. > > > > In other words I would prefer to say that a CCS that arrives first is > > not allowed. That simplifies the general case and requires no special > > coding for servers implementing older versions of TLS. > > > > > > This issue only seems to arise for people who are both doing TLS 1.3 and > > TLS 1.2 *and* doing stateless implementations, which is kind of an odd > > configuration because a number of the conditions in TLS 1.3 that involve > > HRR (and thus can be stateless). It doesn't arise for QUIC (because no > > TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of > > junk). Or am I wrong? > > Correct, although technically the wording of draft-22 (in your > interpretation) *requires* that a server receiving a CCS first MUST > ignore it - even though that should never happen except in the weird > scenario above. That is why I prefer to say that a CCS arriving first is > always an error for the general case. > Well, you can receive a CCS first any time you're stateless. What's unusual is having to subsequently reject it if you are stateless and *then* negotiate 1.2. My point is that this doesn't seem like a very big hardship for the reasons above. -Ekr > Matt > > --001a113f169e7ddc4a05616a3a82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell <matt@openssl.org> wrote:


On 28/12/17 17:42, Eric Rescorla wrote:
>
>
> On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <matt@openssl.org
> <mailto:matt@openssl.org>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 28/12/17 12:28, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I think it would be helpful=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0to be more explicit in the = text if that is the case, i.e. identify the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0first point in the handshak= e and the last point in the handshake where
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0CCS is valid. There probabl= y should also be some words about how servers
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0implementing older TLS vers= ions should handle a CCS that comes first.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I could add those.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0However, I'm concerned = about the added complexity of interpreting things
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0that way. Suddenly a CCS ar= riving is no longer handled by just dropping
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0it and forgetting it - you = now have to store state about that and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0remember it later on in the= process in other TLS versions. The CCS
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0workaround was supposed to = be a simple no-op to implement and it no
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0longer appears that way in = this interpretation.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Well, it seems like the issue here is you want= the client to send CH1,
>=C2=A0 =C2=A0 =C2=A0> CCS, CH2
>=C2=A0 =C2=A0 =C2=A0> so we need the server to accept that. Am I mis= sing something?
>
>=C2=A0 =C2=A0 =C2=A0The point is a stateless server will not know about= CH1 at the point
>=C2=A0 =C2=A0 =C2=A0that it receives CCS.
>
>
> Well, sort of.
>
> Specifically, there are three valid things that a server (whether stat= eless
> or stateful) can receive:
>
> - CH1 [I.e. a CH without a cookie]
> - CH2 [i.e., a CH with a cookie]
> - CCS
>
> It should respond to any other message with an alert and abort the
> handshake.
> A stateful server should also tear down the transport connection, so > that subsequent
> messages are considered an error. This obviously isn't an option f= or a
> stateless server,
> so, yes, a stateless server might in principle receive arbitrary amoun= ts
> of junk
> before CH1 or between CH1 and CH2, and it would still survive, albeit = by
> sending alerts.
>
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0Actually, as Ilari points out, there could be any >=C2=A0 =C2=A0 =C2=A0junk (including partial records) arriving between C= H1 and CH2. So this
>=C2=A0 =C2=A0 =C2=A0feels more like a special case for stateless server= s.
>
>=C2=A0 =C2=A0 =C2=A0In other words I would prefer to say that a CCS tha= t arrives first is
>=C2=A0 =C2=A0 =C2=A0not allowed. That simplifies the general case and r= equires no special
>=C2=A0 =C2=A0 =C2=A0coding for servers implementing older versions of T= LS.
>
>
> This issue only seems to arise for people who are both doing TLS 1.3 a= nd
> TLS 1.2 *and* doing stateless implementations, which is kind of an odd=
> configuration because a number of the conditions in TLS 1.3 that invol= ve
> HRR (and thus can be stateless). It doesn't arise for QUIC (becaus= e no
> TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kind= s of
> junk).=C2=A0 Or am I wrong?

Correct, although technically the wording of draft-22 (in your<= br> interpretation) *requires* that a server receiving a CCS first MUST
ignore it - even though that should never happen except in the weird
scenario above. That is why I prefer to say that a CCS arriving first is always an error for the general case.

W= ell, you can receive a CCS first any time you're stateless. What's = unusual
is having to subsequently reject it if you are stateless = and *then* negotiate
1.2. My point is that this doesn't seem = like a very big hardship for the reasons
above.

-Ekr



Matt


--001a113f169e7ddc4a05616a3a82-- From nobody Thu Dec 28 10:02: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 9302D124D37 for ; Thu, 28 Dec 2017 10:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SBL_CSS=3.335, T_RP_MATCHES_RCVD=-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 MmxFBrz0K37y for ; Thu, 28 Dec 2017 10:02:46 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B756127136 for ; Thu, 28 Dec 2017 10:02:45 -0800 (PST) Received: from [10.75.10.6] (unknown [104.238.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 77287E0858; Thu, 28 Dec 2017 18:02:43 +0000 (UTC) To: Eric Rescorla Cc: "tls@ietf.org" References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> From: Matt Caswell Message-ID: <62bfa0e8-ae90-5291-e179-39743994c51a@openssl.org> Date: Thu, 28 Dec 2017 18:02:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 18:02:47 -0000 On 28/12/17 17:55, Eric Rescorla wrote: > > On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell > wrote: > > > > On 28/12/17 17:42, Eric Rescorla wrote: > > > > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell > > >> wrote: > > > > > > > >     On 28/12/17 12:28, Eric Rescorla wrote: > >     >     I think it would be helpful > >     >     to be more explicit in the text if that is the case, > i.e. identify the > >     >     first point in the handshake and the last point in the > handshake where > >     >     CCS is valid. There probably should also be some words > about how servers > >     >     implementing older TLS versions should handle a CCS that > comes first. > >     > > >     > > >     > I could add those. > >     > > >     > > >     >     However, I'm concerned about the added complexity of > interpreting things > >     >     that way. Suddenly a CCS arriving is no longer handled > by just dropping > >     >     it and forgetting it - you now have to store state about > that and > >     >     remember it later on in the process in other TLS > versions. The CCS > >     >     workaround was supposed to be a simple no-op to > implement and it no > >     >     longer appears that way in this interpretation. > >     > > >     > > >     > Well, it seems like the issue here is you want the client to > send CH1, > >     > CCS, CH2 > >     > so we need the server to accept that. Am I missing something? > > > >     The point is a stateless server will not know about CH1 at the > point > >     that it receives CCS. > > > > > > Well, sort of. > > > > Specifically, there are three valid things that a server (whether > stateless > > or stateful) can receive: > > > > - CH1 [I.e. a CH without a cookie] > > - CH2 [i.e., a CH with a cookie] > > - CCS > > > > It should respond to any other message with an alert and abort the > > handshake. > > A stateful server should also tear down the transport connection, so > > that subsequent > > messages are considered an error. This obviously isn't an option for a > > stateless server, > > so, yes, a stateless server might in principle receive arbitrary > amounts > > of junk > > before CH1 or between CH1 and CH2, and it would still survive, > albeit by > > sending alerts. > > > >   > > > >     Actually, as Ilari points out, there could be any > >     junk (including partial records) arriving between CH1 and CH2. > So this > >     feels more like a special case for stateless servers. > > > >     In other words I would prefer to say that a CCS that arrives > first is > >     not allowed. That simplifies the general case and requires no > special > >     coding for servers implementing older versions of TLS. > > > > > > This issue only seems to arise for people who are both doing TLS > 1.3 and > > TLS 1.2 *and* doing stateless implementations, which is kind of an odd > > configuration because a number of the conditions in TLS 1.3 that > involve > > HRR (and thus can be stateless). It doesn't arise for QUIC (because no > > TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of > > junk).  Or am I wrong? > > Correct, although technically the wording of draft-22 (in your > interpretation) *requires* that a server receiving a CCS first MUST > ignore it - even though that should never happen except in the weird > scenario above. That is why I prefer to say that a CCS arriving first is > always an error for the general case. > > > Well, you can receive a CCS first any time you're stateless. What's unusual > is having to subsequently reject it if you are stateless and *then* > negotiate > 1.2. My point is that this doesn't seem like a very big hardship for the > reasons > above. I must be missing your point. According to the spec as it stands even with a stateful server I MUST ignore a CCS that comes first. Since this is a stateful server it may end up negotiating TLSv1.2 - which requires us to abort the handshake if the CCS comes first. No sensible implementation will ever send a CCS first in this scenario, so why am I required by the spec to ignore it and implement the extra complexity in TLSv1.2 handling? In reality I wouldn't bother to implement this which would make me technically non-compliant. I would prefer it if the wording were fixed to not require this. Matt From nobody Thu Dec 28 10:07:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BCC12D96C for ; Thu, 28 Dec 2017 10:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y22AMrBGHYrg for ; Thu, 28 Dec 2017 10:07:28 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC1E12D969 for ; Thu, 28 Dec 2017 10:07:28 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id u107so3763824ybi.2 for ; Thu, 28 Dec 2017 10:07:28 -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=oOVjaON4XM+s8LBlLuKJcD+cbB/7tVBCegw4Bxx4+N8=; b=rM+xQgG410mD8qvrVoqFu3WVsKsQ/iHE4osYKRXW03dQJCilc92KSTc+QmYFlcfI3E T9ro8c9xTA0YO20h4r3TfMlTGV1ZF4vxvjC/TGlKwMvc2+fiL/Y4vNwbg6Fe7NcfEz3i mU0WeEoTPO3ImRzbkSjQmCICf85POpk5sZ6IQagYRfzHmzMUalbVgICcpZ7ZWB03TPOc vnqIv0d7qsnQpQWEE4iB4bOJecnIJMFiH3cG2Xhzv+R5h5Mq+28rHvaKVJe21v/sFVCS zgKuMq+Ia5jRVYqoOn1AYe3Z2fXk/aLLJulqZ4RUpf2UMAfXr2qS5Es34nbtdl5hb8vq wCYQ== 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=oOVjaON4XM+s8LBlLuKJcD+cbB/7tVBCegw4Bxx4+N8=; b=gi3HaZoWI7SWAOrmOGLbPpxCSUGjLSYm1C3jvcQSOpXU+eNom7AIVpKQKY7d03wtne wUghv34ZjfDQ5NXHxz1jTOsh9R+b4mblmWkFGlGq9f3m8Ds3I6HLqHZ6lgylSnHgJReW 5BTUoOKUPEdvKXy56uuzOEzqUSAo+1YivojwQfTBLAcmvhW5v7WOFvi76hYkwGAJPedc vPACFwASNAiuWc8Dkx9R/kZ385gSGsrTlflSgbdkIQ4UMFrsp00thflDac/WjQ3xay+V 4uhl+2LOsLyT6sOu0D/ZqlTuZNN3LE6NHDY9P47S+G8YQsW9y+kyNI8mo5IzX1ruc9VI 3Apw== X-Gm-Message-State: AKGB3mIUBgV4Ofj3oeG13lerl9pYWpNcwt+jdDs1VjZc0isaCFcHi5Ro Hk2l9MHZCU4PMHJkoiCTifnvpu6Z5L6VoeLdc2gPKA== X-Google-Smtp-Source: ACJfBosqWgKY0JYpPuyXHPXZgpOxoKdpg+ehz8EHyKDyexhTIuCiOvkhowJGI09H2ZKEZ4QiYkKSNlqvwyrgnXMNIvw= X-Received: by 10.37.239.17 with SMTP id g17mr23581005ybd.474.1514484447546; Thu, 28 Dec 2017 10:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 28 Dec 2017 10:06:46 -0800 (PST) In-Reply-To: <62bfa0e8-ae90-5291-e179-39743994c51a@openssl.org> References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> <62bfa0e8-ae90-5291-e179-39743994c51a@openssl.org> From: Eric Rescorla Date: Thu, 28 Dec 2017 10:06:46 -0800 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08289ed883a7f205616a6366" Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2017 18:07:30 -0000 --089e08289ed883a7f205616a6366 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 28, 2017 at 10:02 AM, Matt Caswell wrote: > > > On 28/12/17 17:55, Eric Rescorla wrote: > > > > On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell > > wrote: > > > > > > > > On 28/12/17 17:42, Eric Rescorla wrote: > > > > > > > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell > > > >> wrote: > > > > > > > > > > > > On 28/12/17 12:28, Eric Rescorla wrote: > > > > I think it would be helpful > > > > to be more explicit in the text if that is the case, > > i.e. identify the > > > > first point in the handshake and the last point in the > > handshake where > > > > CCS is valid. There probably should also be some words > > about how servers > > > > implementing older TLS versions should handle a CCS that > > comes first. > > > > > > > > > > > > I could add those. > > > > > > > > > > > > However, I'm concerned about the added complexity of > > interpreting things > > > > that way. Suddenly a CCS arriving is no longer handled > > by just dropping > > > > it and forgetting it - you now have to store state about > > that and > > > > remember it later on in the process in other TLS > > versions. The CCS > > > > workaround was supposed to be a simple no-op to > > implement and it no > > > > longer appears that way in this interpretation. > > > > > > > > > > > > Well, it seems like the issue here is you want the client to > > send CH1, > > > > CCS, CH2 > > > > so we need the server to accept that. Am I missing something? > > > > > > The point is a stateless server will not know about CH1 at the > > point > > > that it receives CCS. > > > > > > > > > Well, sort of. > > > > > > Specifically, there are three valid things that a server (whether > > stateless > > > or stateful) can receive: > > > > > > - CH1 [I.e. a CH without a cookie] > > > - CH2 [i.e., a CH with a cookie] > > > - CCS > > > > > > It should respond to any other message with an alert and abort the > > > handshake. > > > A stateful server should also tear down the transport connection, > so > > > that subsequent > > > messages are considered an error. This obviously isn't an option > for a > > > stateless server, > > > so, yes, a stateless server might in principle receive arbitrary > > amounts > > > of junk > > > before CH1 or between CH1 and CH2, and it would still survive, > > albeit by > > > sending alerts. > > > > > > > > > > > > Actually, as Ilari points out, there could be any > > > junk (including partial records) arriving between CH1 and CH2. > > So this > > > feels more like a special case for stateless servers. > > > > > > In other words I would prefer to say that a CCS that arrives > > first is > > > not allowed. That simplifies the general case and requires no > > special > > > coding for servers implementing older versions of TLS. > > > > > > > > > This issue only seems to arise for people who are both doing TLS > > 1.3 and > > > TLS 1.2 *and* doing stateless implementations, which is kind of an > odd > > > configuration because a number of the conditions in TLS 1.3 that > > involve > > > HRR (and thus can be stateless). It doesn't arise for QUIC > (because no > > > TLS 1.2) and mostly doesn't arise for DTLS (if you reject all > kinds of > > > junk). Or am I wrong? > > > > Correct, although technically the wording of draft-22 (in your > > interpretation) *requires* that a server receiving a CCS first MUST > > ignore it - even though that should never happen except in the weird > > scenario above. That is why I prefer to say that a CCS arriving > first is > > always an error for the general case. > > > > > > Well, you can receive a CCS first any time you're stateless. What's > unusual > > is having to subsequently reject it if you are stateless and *then* > > negotiate > > 1.2. My point is that this doesn't seem like a very big hardship for the > > reasons > > above. > > I must be missing your point. According to the spec as it stands even > with a stateful server I MUST ignore a CCS that comes first. Since this > is a stateful server it may end up negotiating TLSv1.2 - which requires > us to abort the handshake if the CCS comes first. No sensible > implementation will ever send a CCS first in this scenario, so why am I > required by the spec to ignore it and implement the extra complexity in > TLSv1.2 handling? > > In reality I wouldn't bother to implement this which would make me > technically non-compliant. I would prefer it if the wording were fixed > to not require this. > OK, I understand your point now, I think it's fine to reject this case as long as you properly handle things in the stateless case. If you want to submit a PR, I will take a look. -Ekr > Matt > > > --089e08289ed883a7f205616a6366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 28, 2017 at 10:02 AM, Matt Caswell <matt@openssl.org>= ; wrote:


On 28/12/17 17:55, Eric Rescorla wrote:
>
> On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell <matt@openssl.org
> <mailto:matt@openssl.org>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 28/12/17 17:42, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell = <matt@openssl.org <mailto:matt@openssl.org>
>=C2=A0 =C2=A0 =C2=A0> <mailto:matt@openssl.org <mailto:matt@openssl.org>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On 28/12/17 12:28, Eric Res= corla wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I t= hink it would be helpful
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0to = be more explicit in the text if that is the case,
>=C2=A0 =C2=A0 =C2=A0i.e. identify the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0fir= st point in the handshake and the last point in the
>=C2=A0 =C2=A0 =C2=A0handshake where
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0CCS= is valid. There probably should also be some words
>=C2=A0 =C2=A0 =C2=A0about how servers
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0imp= lementing older TLS versions should handle a CCS that
>=C2=A0 =C2=A0 =C2=A0comes first.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> I could add those.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0How= ever, I'm concerned about the added complexity of
>=C2=A0 =C2=A0 =C2=A0interpreting things
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0tha= t way. Suddenly a CCS arriving is no longer handled
>=C2=A0 =C2=A0 =C2=A0by just dropping
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0it = and forgetting it - you now have to store state about
>=C2=A0 =C2=A0 =C2=A0that and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0rem= ember it later on in the process in other TLS
>=C2=A0 =C2=A0 =C2=A0versions. The CCS
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0wor= karound was supposed to be a simple no-op to
>=C2=A0 =C2=A0 =C2=A0implement and it no
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0lon= ger appears that way in this interpretation.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Well, it seems like th= e issue here is you want the client to
>=C2=A0 =C2=A0 =C2=A0send CH1,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> CCS, CH2
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> so we need the server = to accept that. Am I missing something?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The point is a stateless se= rver will not know about CH1 at the
>=C2=A0 =C2=A0 =C2=A0point
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0that it receives CCS.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Well, sort of.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Specifically, there are three valid things tha= t a server (whether
>=C2=A0 =C2=A0 =C2=A0stateless
>=C2=A0 =C2=A0 =C2=A0> or stateful) can receive:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> - CH1 [I.e. a CH without a cookie]
>=C2=A0 =C2=A0 =C2=A0> - CH2 [i.e., a CH with a cookie]
>=C2=A0 =C2=A0 =C2=A0> - CCS
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> It should respond to any other message with an= alert and abort the
>=C2=A0 =C2=A0 =C2=A0> handshake.
>=C2=A0 =C2=A0 =C2=A0> A stateful server should also tear down the tr= ansport connection, so
>=C2=A0 =C2=A0 =C2=A0> that subsequent
>=C2=A0 =C2=A0 =C2=A0> messages are considered an error. This obvious= ly isn't an option for a
>=C2=A0 =C2=A0 =C2=A0> stateless server,
>=C2=A0 =C2=A0 =C2=A0> so, yes, a stateless server might in principle= receive arbitrary
>=C2=A0 =C2=A0 =C2=A0amounts
>=C2=A0 =C2=A0 =C2=A0> of junk
>=C2=A0 =C2=A0 =C2=A0> before CH1 or between CH1 and CH2, and it woul= d still survive,
>=C2=A0 =C2=A0 =C2=A0albeit by
>=C2=A0 =C2=A0 =C2=A0> sending alerts.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Actually, as Ilari points o= ut, there could be any
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0junk (including partial rec= ords) arriving between CH1 and CH2.
>=C2=A0 =C2=A0 =C2=A0So this
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0feels more like a special c= ase for stateless servers.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0In other words I would pref= er to say that a CCS that arrives
>=C2=A0 =C2=A0 =C2=A0first is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0not allowed. That simplifie= s the general case and requires no
>=C2=A0 =C2=A0 =C2=A0special
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0coding for servers implemen= ting older versions of TLS.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This issue only seems to arise for people who = are both doing TLS
>=C2=A0 =C2=A0 =C2=A01.3 and
>=C2=A0 =C2=A0 =C2=A0> TLS 1.2 *and* doing stateless implementations,= which is kind of an odd
>=C2=A0 =C2=A0 =C2=A0> configuration because a number of the conditio= ns in TLS 1.3 that
>=C2=A0 =C2=A0 =C2=A0involve
>=C2=A0 =C2=A0 =C2=A0> HRR (and thus can be stateless). It doesn'= t arise for QUIC (because no
>=C2=A0 =C2=A0 =C2=A0> TLS 1.2) and mostly doesn't arise for DTLS= (if you reject all kinds of
>=C2=A0 =C2=A0 =C2=A0> junk).=C2=A0 Or am I wrong?
>
>=C2=A0 =C2=A0 =C2=A0Correct, although technically the wording of draft-= 22 (in your
>=C2=A0 =C2=A0 =C2=A0interpretation) *requires* that a server receiving = a CCS first MUST
>=C2=A0 =C2=A0 =C2=A0ignore it - even though that should never happen ex= cept in the weird
>=C2=A0 =C2=A0 =C2=A0scenario above. That is why I prefer to say that a = CCS arriving first is
>=C2=A0 =C2=A0 =C2=A0always an error for the general case.
>
>
> Well, you can receive a CCS first any time you're stateless. What&= #39;s unusual
> is having to subsequently reject it if you are stateless and *then* > negotiate
> 1.2. My point is that this doesn't seem like a very big hardship f= or the
> reasons
> above.

I must be missing your point. According to the spec as it stand= s even
with a stateful server I MUST ignore a CCS that comes first. Since this
is a stateful server it may end up negotiating TLSv1.2 - which requires
us to abort the handshake if the CCS comes first. No sensible
implementation will ever send a CCS first in this scenario, so why am I
required by the spec to ignore it and implement the extra complexity in
TLSv1.2 handling?

In reality I wouldn't bother to implement this which would make me
technically non-compliant. I would prefer it if the wording were fixed
to not require this.

OK, I understand y= our point now, I think it's fine to reject this case as long as
you properly handle things in the stateless case. If you want to submit = a PR,
I will take a look.

-Ekr


Matt



--089e08289ed883a7f205616a6366-- From nobody Fri Dec 29 02:54: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 2677D12D832 for ; Fri, 29 Dec 2017 02:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 2njRQTttKaBP for ; Fri, 29 Dec 2017 02:54:45 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7B012D7F6 for ; Fri, 29 Dec 2017 02:54:45 -0800 (PST) Received: from [10.40.10.6] (unknown [104.238.169.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 98161E701E; Fri, 29 Dec 2017 10:54:42 +0000 (UTC) To: Eric Rescorla Cc: "tls@ietf.org" References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> <62bfa0e8-ae90-5291-e179-39743994c51a@openssl.org> From: Matt Caswell Message-ID: Date: Fri, 29 Dec 2017 10:54:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2017 10:54:48 -0000 On 28/12/17 18:06, Eric Rescorla wrote: > I must be missing your point. According to the spec as it stands even > with a stateful server I MUST ignore a CCS that comes first. Since this > is a stateful server it may end up negotiating TLSv1.2 - which requires > us to abort the handshake if the CCS comes first. No sensible > implementation will ever send a CCS first in this scenario, so why am I > required by the spec to ignore it and implement the extra complexity in > TLSv1.2 handling? > > In reality I wouldn't bother to implement this which would make me > technically non-compliant. I would prefer it if the wording were fixed > to not require this. > > > OK, I understand your point now, I think it's fine to reject this case > as long as > you properly handle things in the stateless case. If you want to submit > a PR, > I will take a look. https://github.com/tlswg/tls13-spec/pull/1129 Matt From nobody Fri Dec 29 13:51: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 18F571271DF for ; Fri, 29 Dec 2017 13:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.98 X-Spam-Level: X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpVKKEGIgz9m for ; Fri, 29 Dec 2017 13:51:21 -0800 (PST) Received: from sonic317-27.consmr.mail.bf2.yahoo.com (sonic317-27.consmr.mail.bf2.yahoo.com [74.6.129.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B083B127136 for ; Fri, 29 Dec 2017 13:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1514584280; bh=Rv5GCXK5dvCno4rimGPpa5WNDU6fL6CYBPvtX5abmQU=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=Z3KGiHvHp/Awlk0KfzMqfUeMSIQrnyj/HOTMGsmnXbc7CllhO7aUO99p4zzHgHI/fkhIlCdxYmbgVluSPGznwqe6yhnGI8YTEMDD2Kt+zLDHq9kLWw9kgjKXOYzgVC/ZD/bY7mMUpadWWoi5CQQMNmei1v9kdL4GE63KqSU/FJp/1JbjBda7EEWsJJv9etnHn1SZQtndOfMqSCuXszsFgU4PKh+A71Of4Kr6hzO3MyKWdUpzL33CR4oIkNQeUhf8H8MMVzSN+iNsE2iri4AjECZKwmetbXIBNRw8I1PLQmvZfozdN8EMJ/L1FelvHpCi2neK8Y2QFd3XEcXHZeWg8Q== X-YMail-OSG: nfX2LgAVM1kBwVLH1OcirKSUe96upWTtc7pjf5G691zD5.C5dclqePT5EN1v92w Xg6nFYGDnxMUfcgKinLD1aOEj1XexQkMNxWjykR4GHHLPlMG2m0Y0AKyHs1YY2STd9a.F5KRSZ5J IeJEbAwnC21oKTTJzsPm9JvW2BKZYakSC7rQ1MnPKhQ7fR27HUmC94X0y.cPf_kBzSiEVeCqyE85 H05diu4p126DWAqe6aJpPWPJ1XAbqdZgKB4k3xMy__c8FVptwKAB_eXnnqGztJ8sHZBb7UpDqFAA PqYgAQu28NeBAnBnKnmWpdRbJtwn.axqj95m672sPcXGOVuyMAUz3bvQPRmoiLsJ7IiXksP6NdOd VQuYwxGoFZntGmAlEjC3GrcE2pRNaypxzUkrq8.9xcppRjFgc344lKNCtBf06V9rvtu5Bg4b.p0X 6NlJWnAhNID_R4lTaxINkx_6B3jQ.xofsd1GFTsI_l_GvXaxdEgbuBIXh0JwXlIw5el1Ys34n8HR b57RruA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 29 Dec 2017 21:51:20 +0000 Date: Fri, 29 Dec 2017 21:51:17 +0000 (UTC) From: Jitendra Lulla Reply-To: Jitendra Lulla To: Message-ID: <1890717233.6710973.1514584277146@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1890717233.6710973.1514584277146.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11051 YahooMailBasic Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Archived-At: Subject: [TLS] TLS 1.3 : small fragments attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2017 21:51:23 -0000 Hi, Is it possible for the standards/RFCs to dictate de-prioritization of certain troublesome TLS processing patterns? The RFCs -- may suggest identification of such patterns, -- may suggest implementation of certain low priority processing queues/threads/executions. Following is an example troublesome pattern which may or may not be coming from attackers: Please consider a scenario wherein a server is allowing the clients to upload big files. The client is mostly doing the transmission in this case. The client can have a rogue TLS implementation with the following intentional changes: 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing power requirements) and non paralleliz'able cipher suite. 1. After the handshake, always send all the TLS records (Application Data) plain text fragment size which is no greater than 1 Byte. 2. Always send a padding of max possible or big size (eg 256 Bytes) So the TLS record will look like: (1.2 version) 5 B Hdr + 16 B IV + 1B Cipher Text + 32 B HMAC + 255 B Padding.= 309 Bytes including the tls header. Additionally the client's network stack can have some changes which may possibly cause the following too: A. TCP segmentation B. IP Fragmentation Now the server will have to i. do ip reassmebly/ TCP reassembly to recover every single TLS record ii. The TLS record thus recovered will undergo decryption/HMAC verification only to obtain 1 Byte of plaintext application payload. If many such rogue clients sending huge files to the server, the server will end up denying services to the genuine clients. Now A and B above are not related to TLS, but the other points do have something to do with the implementations. If the server's TLS implantation can recognize this pattern [possibly from an attacker], it can give low priority to such requests so that other genuine requests may get served without being affected. If such preventive measures are a part of the RFCs, the implementations will be less vulnerable. Thanks Jitendra From nobody Fri Dec 29 21:03: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 9387F124BE8 for ; Fri, 29 Dec 2017 21:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 bSpXiPCBWaL0 for ; Fri, 29 Dec 2017 21:03:50 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 0DD4E12422F for ; Fri, 29 Dec 2017 21:03:49 -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=1514610230; x=1546146230; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DrA9rVbbuVJo0t2oduDJgdiByqFLMbwrDLWFxrnRgrI=; b=s0gOjX13EejRdjkNke1OEVMu7ZvdZ/DLOhhJmFRUL8lOURNdZ6QI6uHP 03vS1hGs7h7y7dq9suV3ShgOy19QYrOk136moCukzIIQgGacm8YjlTK6E B2aTO/UJl6x/9NEb3J4Cwdq3L4ayZdUm+zscGyOA2Z4oKMUY8yBo7OCUO zSzxeIpPmXsGAFHJ741zRaAvV1ZMvrkJCSEQorv/3Q+UE53Tm261GS5ij YP9dFT7h9+tiXuWbwOutOBmZ2mtmXvKxfZJBx1t9XfgYvhrLG+9dd7AZG hMN4X14rH/1kQjrVJgQtcd9CFV7wESW5kR9ucui6dI1U+32bfworgI114 Q==; X-IronPort-AV: E=Sophos;i="5.45,478,1508756400"; d="scan'208";a="206582700" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Dec 2017 18:03:42 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Dec 2017 18:03:42 +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.1263.000; Sat, 30 Dec 2017 18:03:42 +1300 From: Peter Gutmann To: "tls@ietf.org" , Jitendra Lulla Thread-Topic: [TLS] TLS 1.3 : small fragments attack Thread-Index: AQHTgO80gASsapOtDUK7GtKcpROFZ6NbVTHw Date: Sat, 30 Dec 2017 05:03:41 +0000 Message-ID: <1514610214269.6873@cs.auckland.ac.nz> References: <1890717233.6710973.1514584277146.ref@mail.yahoo.com>, <1890717233.6710973.1514584277146@mail.yahoo.com> In-Reply-To: <1890717233.6710973.1514584277146@mail.yahoo.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: Subject: Re: [TLS] TLS 1.3 : small fragments attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2017 05:03:52 -0000 Jitendra Lulla writes:=0A= =0A= >The client can have a rogue TLS implementation with the following intentio= nal=0A= >changes:=0A= >=0A= >0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processi= ng=0A= >power requirements) and non paralleliz'able cipher suite.=0A= >=0A= >1. After the handshake, always send all the TLS records (Application Data)= =0A= >plain text fragment size which is no greater than 1 Byte.=0A= >=0A= >2. Always send a padding of max possible or big size (eg 256 Bytes)=0A= =0A= Apart from (2), that looks like interactive terminal traffic over TLS. The= =0A= large padding may also be natually sent by an implementation that's trying = a=0A= bit too hard to hide typing/traffic patterns.=0A= =0A= Peter.=0A= From nobody Fri Dec 29 21:33: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 8F073126C19 for ; Fri, 29 Dec 2017 21:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLrFUIW8TlP3 for ; Fri, 29 Dec 2017 21:33:15 -0800 (PST) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB4C1200C5 for ; Fri, 29 Dec 2017 21:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1514611994; bh=Wz2wtE8aYCysfAN2CJMkhoVKrCZ/xRdLpRWK1oGqKjc=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=VW6eqSNpUXF4CTLD8sdhCOVTtvp+8lM00pEt0touBuD2hFRQUCCtsUzctOsmhr99TaMvdIbMV3cEiHtvoUiQ2Is57C6exw+BkfbVDTaURfmkr9nFvd/vSIWnDcVNdo17T6Kcay0ekhgMNaLcd9w2KGWa/AWZj2Dgh54rI8k9WZxHwdYD7z25w0+yObUSAMoiBFX5R+pKlhsBcgCh5IPKVl/3BL9n2fs6FCYXnfqao2tNPuHnRQvGvvQDitoABt9opguCqE0UER1rLPxpQ4cHjCpmzrY34rHx95uzjlgJu/onSeidwwvrISgYLt08snZNqNKUeJ9eirrl+neNJIw7HQ== X-YMail-OSG: pVmRGBsVM1mXQ0kqUZ8iaPMO5XkRXd5wqFr95qWZHYcl4thzzjA2C5nC6TIuKXi L2GkDwGRnk0gcX4FDn83cowYVxvbJE5OBt1bDqHcbGKx5CX71cR5NLJR26Pv8MSjWQ_QTU0u3ipw 5agDgZ9uGzibVrZ1FK_LU6MQc6blnjG_DWh49eGnc6HKjwUbk.22r0EEQmgvIt6sj6GQjLzHu9Iy YyrJHU214iCdPB2dw_81LmDiX7ESr4.A5b72ZSa5UpaaRKDCFL2i9OMHq.istw3WeLVF9qHQhduO raaeaLPPKpo85Yr57jDjsx5PjJ6S_U6dveCMVtBYIbzMoVyuowJMA9UXn0DI.1dqm8XWm5QGCwoG ZoCVsJsFuQEJ3QUpdAGA2foLr9qxQ8TssKRbvBg9ftl537lmGJhy4CW59utPG5I_AgdH.yxkl1u. 5F9.r3xDMkHPM5s2mF0ucMqjU04T74gYNKWW7HGiu5NLo7T_rYiWdG616nK00yTc3e.64ld6te2I 26MkQT_HTfEhXjRgN_Av166Veety9z0FmUw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 30 Dec 2017 05:33:14 +0000 Date: Sat, 30 Dec 2017 05:33:13 +0000 (UTC) From: Jitendra Lulla Reply-To: Jitendra Lulla To: "tls@ietf.org" , Jitendra Lulla , Peter Gutmann Message-ID: <779315278.6839488.1514611993150@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <779315278.6839488.1514611993150.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11051 YahooMailBasic Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Archived-At: Subject: Re: [TLS] TLS 1.3 : small fragments attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2017 05:33:16 -0000 The pattern is perfectly normal and might be assumed to be coming from an = interactive terminal. But what if such records, from the same session, come in a quantity of 1000= 0 or more per second which could be generated by uploading a 500 MB file by= the client? And how about 100s of such clients targeting a server which is allowing fil= e uploads? The server can be very easily kept busy decrypting and HMAC verifying such = records just to obtain 1 real application data byte per record while the re= maining 308 bytes are just overhead of securing the said byte! -------------------------------------------- On Sat, 12/30/17, Peter Gutmann wrote: Subject: Re: [TLS] TLS 1.3 : small fragments attack To: "tls@ietf.org" , "Jitendra Lulla" Date: Saturday, December 30, 2017, 5:03 AM =20 Jitendra Lulla writes: =20 >The client can have a rogue TLS implementation with the following intentional >changes: > >0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing >power requirements) and non paralleliz'able=C2=A0 cipher suite. > >1. After the handshake, always send all the TLS records (Application Data) >plain text fragment size which is no greater than 1 Byte. > >2. Always send a padding of max possible or big size (eg 256 Bytes) =20 Apart from (2), that looks like interactive terminal traffic over TLS.=C2=A0 The large padding may also be natually sent by an implementation that's trying a bit too hard to hide typing/traffic patterns. =20 Peter. =20 From nobody Fri Dec 29 21:39: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 DE5AF126D74 for ; Fri, 29 Dec 2017 21:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Tg0zhc02_Ffo for ; Fri, 29 Dec 2017 21:39:08 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 187D2126C19 for ; Fri, 29 Dec 2017 21:39:07 -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=1514612348; x=1546148348; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KgKjUuOeY1hNMw4Qd8V4dTN2eElWXudIA7sgZqafUTM=; b=Y8GnClBSQJaSZCIuzTGWhuIrKEtBHd4mcjy4F2JgdgIjFUatAH2l+FY3 P1V23HoyV+wWgCjH38tY50JlcuA0lWYPZtgmdCqbF3nBaM/UJXC2BRA1d ollyLUAPgsHGzVCYjZ41WH1DWJphWNNc5WphFZUIdblXlKUfN6WZteXUm ZUnxkDDsOVF0pfxsSNFEF7Un0kFeASvIVFnR1GsTKeD2HeNIu1HsNDKWI /Wn0guQW2dJX98v23ltWVWEZnFYZWyR/6wGRsVnmvyv2BygqtkwPkYzvO qRXDV2+jMSan4n+QQrTDPLqzBAHSP2nQGaxO0mGz5dVWHksbrJqVaN3hT w==; X-IronPort-AV: E=Sophos;i="5.45,478,1508756400"; d="scan'208";a="206586516" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Dec 2017 18:38:53 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 30 Dec 2017 18:38:52 +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.1263.000; Sat, 30 Dec 2017 18:38:52 +1300 From: Peter Gutmann To: "tls@ietf.org" , Jitendra Lulla Thread-Topic: [TLS] TLS 1.3 : small fragments attack Thread-Index: AQHTgS+vgASsapOtDUK7GtKcpROFZ6NbXeIZ Date: Sat, 30 Dec 2017 05:38:52 +0000 Message-ID: <1514612325538.73881@cs.auckland.ac.nz> References: <779315278.6839488.1514611993150.ref@mail.yahoo.com>, <779315278.6839488.1514611993150@mail.yahoo.com> In-Reply-To: <779315278.6839488.1514611993150@mail.yahoo.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: Subject: Re: [TLS] TLS 1.3 : small fragments attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2017 05:39:10 -0000 Jitendra Lulla writes:=0A= =0A= >But what if such records, from the same session, come in a quantity of 100= 00=0A= >or more per second which could be generated by uploading a 500 MB file by = the=0A= >client?=0A= =0A= My comment was meant as a general observation on how hard anomaly-detection= =0A= is. At what point do you decide something is an attack? What if they send = 2-=0A= byte messages? Or 1-byte messages with only 64 bytes of padding? Or 1 byt= e=0A= every $server_timeout_value-1 seconds?=0A= =0A= I think your idea in general is a good one, standards should include sanity= =0A= limits on what you should and shouldn't accept (I've managed to cause crash= es=0A= and reboots and whatnot on different servers by sending valid but unexpecte= d=0A= data during development, SSH makes this particularly easy), but in cases li= ke=0A= this it's hard to determine at which point you should and shouldn't accept = the=0A= traffic.=0A= =0A= Peter.=0A= From nobody Fri Dec 29 21:43: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 5C30A126CD6 for ; Fri, 29 Dec 2017 21:43:06 -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, 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 Rd32VwwqUYUw for ; Fri, 29 Dec 2017 21:43: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 EA66D1200C5 for ; Fri, 29 Dec 2017 21:43:04 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 32B767A3309 for ; Sat, 30 Dec 2017 05:43:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <1514612325538.73881@cs.auckland.ac.nz> Date: Sat, 30 Dec 2017 00:42:23 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: tls@ietf.org Message-Id: <8218AB44-6E0D-440C-9D22-87043FC8D2B6@dukhovni.org> References: <779315278.6839488.1514611993150.ref@mail.yahoo.com> <779315278.6839488.1514611993150@mail.yahoo.com> <1514612325538.73881@cs.auckland.ac.nz> To: tls@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] TLS 1.3 : small fragments attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2017 05:43:06 -0000 > On Dec 30, 2017, at 12:38 AM, Peter Gutmann = wrote: >=20 > I think your idea in general is a good one, standards should include = sanity > limits on what you should and shouldn't accept (I've managed to cause = crashes > and reboots and whatnot on different servers by sending valid but = unexpected > data during development, SSH makes this particularly easy), but in = cases like > this it's hard to determine at which point you should and shouldn't = accept the > traffic. Excessive padding aside, the traffic described could be largely normal, for example an SSL-encrypted channel carrying user keystrokes... --=20 Viktor. From nobody Sat Dec 30 01:04: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 5A378126C25 for ; Sat, 30 Dec 2017 01:04:27 -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 avhOzvwwAEuB for ; Sat, 30 Dec 2017 01:04:23 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 0E361127077 for ; Sat, 30 Dec 2017 01:04:23 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id w68so30807698wrc.10 for ; Sat, 30 Dec 2017 01:04:22 -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=P5ao44HwfB4SltFE6ikf0bcmR6HjrrZbzfwiqA6Ab7A=; b=EqY0M7miLuagCV9I4y5SX6/Wzw3bAjQNJer1b56kcPa8MDPXsNFpsF4QYGwVBrT24G uJ9ufCbVNBNNBNorZflHapw4KUeJUtEEOzzjtO5vljbdUd0vp+33ehPFZwWtpTjIXu7c Cq1zCttJadcaGkAaPw2lCy1mHLrKWHOElH4177IrCY8Jbl26mRfaj1fdJrIJvLlXB4Qe fvAPZ6nphlYQOAnLBH7qXZ6rdiUYo77p5aOl/w7Mcq2WyPsLvSHs+rZ79LH3pSphJZMG LUOpalW/vGdkTqjgVXiYW/gQH8xMBSKiSK0+RAnak0TMQY+3eHBKqOD5B0bC36lx/iRy ZLUA== 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=P5ao44HwfB4SltFE6ikf0bcmR6HjrrZbzfwiqA6Ab7A=; b=ihkXbql97TaVunqWi4URqiqjVfKZrqiIfXcwd0m5e8hTa9L28/QlkfLuNdMzJnUces LulCJtEio8it1QKQbKOgbRP1CgtBpuY14QF+YbPRn6XYWiIQo3//1m68RfjSngi7M69q jhRRAKJN4Vl7oSpfjLWzbJ6pFNvDRBpXmTs4eAmqcK3N3CgLGsaUcJGMIoGL7NB3mt/J JVuTEmxoK/b8wEOQAEUfgZOjDM8rJ7tS3xg7BFxZEY5fhTLAr4Qhixp2Ov2idLeveuEm dVaYTqrJa7aDJLG6DAQU9fGJB+fgyWTcZ97jw+u9AVvKiq9RIPy6lOgabVNGeB+gdfet dc5Q== X-Gm-Message-State: AKGB3mI8UY2vN8/2czQGbOGNkMqaRzJ/PXBUjm/d5fOvGEiBkdtuKmlk 6tWqRq9Jt/mCQferFBG9Mh/z5n4r X-Google-Smtp-Source: ACJfBov+dpZmydLt4Uk/3tIx/CRw2kRHg/LH8A+hQ8GlrcdygmTD0jZ3a2RrKBtDOAjPd7pXFDfpfQ== X-Received: by 10.223.147.195 with SMTP id 61mr39030714wrp.176.1514624661561; Sat, 30 Dec 2017 01:04:21 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z20sm16819911wrz.66.2017.12.30.01.04.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Dec 2017 01:04:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Yoav Nir In-Reply-To: <1514610214269.6873@cs.auckland.ac.nz> Date: Sat, 30 Dec 2017 11:04:18 +0200 Cc: "tls@ietf.org" , Jitendra Lulla Content-Transfer-Encoding: quoted-printable Message-Id: <09732263-8C87-49F8-A496-104F615ED67B@gmail.com> References: <1890717233.6710973.1514584277146.ref@mail.yahoo.com> <1890717233.6710973.1514584277146@mail.yahoo.com> <1514610214269.6873@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] TLS 1.3 : small fragments attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2017 09:04:27 -0000 > On 30 Dec 2017, at 7:03, Peter Gutmann = wrote: >=20 > Jitendra Lulla writes: >=20 >> The client can have a rogue TLS implementation with the following = intentional >> changes: >>=20 >> 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of = processing >> power requirements) and non paralleliz'able cipher suite. >>=20 >> 1. After the handshake, always send all the TLS records (Application = Data) >> plain text fragment size which is no greater than 1 Byte. >>=20 >> 2. Always send a padding of max possible or big size (eg 256 Bytes) >=20 > Apart from (2), that looks like interactive terminal traffic over TLS. = The > large padding may also be natually sent by an implementation that's = trying a > bit too hard to hide typing/traffic patterns. Right. If you really want to hide typing patterns, you should send a big = record every tenth of a second. Most of those would be zero-length = fragments, but that=E2=80=99s OK. In fact, the rogue client can do even better by just sending a bunch of = zero-length records. Yoav From nobody Sat Dec 30 03: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 6DC111241F5 for ; Sat, 30 Dec 2017 03:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 DJqTisIC7vZO for ; Sat, 30 Dec 2017 03:07:59 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EA4120713 for ; Sat, 30 Dec 2017 03:07:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C438B53742; Sat, 30 Dec 2017 13:07:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id U4mcEfZ6H21n; Sat, 30 Dec 2017 13:07:57 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5DADE2316; Sat, 30 Dec 2017 13:07:54 +0200 (EET) Date: Sat, 30 Dec 2017 13:07:54 +0200 From: Ilari Liusvaara To: Matt Caswell Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20171230110754.GA14541@LK-Perkele-VII> References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Interaction between cookies and middlebox compat mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2017 11:08:01 -0000 On Thu, Dec 28, 2017 at 04:12:52PM +0000, Matt Caswell wrote: > > > The point is a stateless server will not know about CH1 at the point > that it receives CCS. Actually, as Ilari points out, there could be any > junk (including partial records) arriving between CH1 and CH2. So this > feels more like a special case for stateless servers. Stateless servers also have the problem of dealing with nasty things like fragmented ClientHello messages (yuck) or other initial fragmented messages (which should not happen outside attacks). And unlike DTLS where one can detect subsequent fragments of message, this is not possible in TLS. And since one can not commit state for each connection, the mitigations are much more limited. I suppose one way of handing things is to send a fatal-level unexpected_message alert (of course without tearing connection down, since there is nothing to tear down) in response to any handshake record that does not start with 0x01 byte unless there is pending reassembly state or connection state. The reassembly states would be limited in number (possibly to 0) and and size to avoid DoS. What alert to use if the message is too large to reassemble (if there are 0 reassembly states, any message is too big to reassemble)? Lower-layer reassembly might be possibility. That doesn't allow ClientHello messages larger than 16kB, but that would be give considerably more freedom with Post-Quantum key exchanges than <1232 bytes one gets with single packets[1]. I think QUIC does not support any kind of reassembly of Client Hello. [1] NIST PQC Round1 has only 3 candidates (LAKE, Round2 and SIKE) that have triple digits public key sizes at "level 3 security" below 800 bytes (in fact, all three are somewhere between 500 and 600 bytes). Those are pretty aggressive (or slow in case of SIKE), and the sizes might grow quite a bit as new attacks are discovered. With 3kB space for public keys, there would be considerably more candidates (and space for parameter adjustments). These include even ~20 year old schemes like NTRU (which is one of the candidates). -Ilari